Haystack Blog

To improve the CHI conference, would you share which talks you attended?

Filed under: CHI, Collective Intelligence, Publication, Social Computing, Thought Piece by David Karger on Thursday, 10 May 2012 | No Comments
Tags: CSAIL

I’m having a great time at CHI (including my first time two-stepping today) but I strongly believe, as Jonathan Grudin asserted today, that we can make use of data to improve the conference. I’ve already analyzed historical data that demonstrates that we can substantially reduce reviewer workload. We’ve also created a way you can use current data to meet new people at CHI. And if you’d be willing to share some of your own data, I’d like to try to use it to improve future conferences.

For the current conference, there’s a nice tool, created by Alireza Sahami, for meeting interesting new people at CHI this year. If you visit the mobile version of the CHI program (which also works fine in a regular laptop browser) you can mark some papers you’ve attended or noted to read (just as you can with the CHI program apps—unfortunately, the data is not shared between them, so you’ll need to repeat). Then, clicking the recommendations link and enabling recommendation will give you a list of users who are most similar to you in terms of the papers they’ve chosen to attend. If you don’t know them, send an email and meet them to discuss your shared interests!

For future conferences, I’d really like to investigate the talk attendance data to see if we can do a better job of scheduling the conference to avoid conflicts. In a past life I did a lot of work in combinatorial optimization, and I have my eye on some algorithms that I believe would do an excellent job of automated low-conflict scheduling. But to test this hypothesis (and convince the CHI chairs to give it a try for real) I need actual talk preference data from the attendees. Right now, if you’re marking those interesting talks using the android or iphone apps , that data is locked inside the app. Would you be willing to share it with me so I can experiment with it?

I still need to get IRB approval to use this (personally identifying) data. So I don’t want it yet. Instead, please fill out this form that will let me contact you once I have set up a repository and a procedure for collecting the data? In the meantime, don’t delete your app! It’s the only place where your talk selections are stored.

For CHI 2012: Discussion Forums in the Document Margins

Filed under: CHI, Collective Intelligence, News, Publication, Social Computing by David Karger on Monday, 7 May 2012 | No Comments
Tags: CSAIL

Would you like some feedback on your CHI paper? We’ve set up a site to let people read and comment on it.

On Wednesday at CHI, we’ll be presenting our paper on nb, a discussion forum situated in the margins of documents being discussed. Its original intended usage was for discussion of classroom lecture notes, but we have discovered through our reading group that it is also quite useful for reading, commenting on and discussing research papers. With this in mind, we’re making nb available to the CHI 21012 conference community.

We’ve created a folder on nb for CHI papers; there, you can read and annotate/discuss papers that have been uploaded by their authors. There are currently 4 CHI papers there. The first, of course, is our own paper on nb. We’d love your comments, especially if they arrive before we present on Wednesday morning! If you want to read and discuss, you just register on the site. If you want to make your paper available for comments, please email your paper to sacha@mit.edu and he’ll upload it (yes, this is clunky—the system is currently designed for a faculty member who is uploading their course content, without means for “mere participants” to do the same). I’d like to suggest, since you are seeking comments on your paper, that you “pay it forward”—read and comment on one of the papers already there to balance the hope that someone will then do the same for you.

The paper itself is focused on classroom deployment. Nb has been used in about 60 classes at 5 universites, with several faculty choosing to use it repeatedly. We study a particular successful use of the tool, in a class at MIT where it acquired over 14,000 comments from 100 students. Using both quantitative and interview data, we explain why situating discussions in the margins can work better than the typical separate-forum approach.

If you’re teaching a class, we’d love to help you use nb for it. Contact us!

Allocating CHI reviewers, a sequel

Filed under: CHI, Publication, Thought Piece by David Karger on Saturday, 5 May 2012 | 4 Comments
Tags: CSAIL

Last year I used an analysis of CHI review data to argue that we could save a lot of reviewers’ time on low quality papers by modiyfing our review process. With all the current talk of the value of replication, I figured it was worth testing the same procedure with this year’s review data, which Dan Olsen was kind enough to provide.

CHI currently collects three external reviews on every paper before engaging the program committee to make an accept/reject decision. Last year I did an analysis that suggested rejecting papers with two bad reviews (scores below 3) without requiring a third, and showed that this would have saved 469 reviews (of papers that should have been rejected) while accidentally rejecting just 6 of about 300 papers. I argued that 6 papers was probably dwarfed by other mistakes the PC makes, so this would be a worthwhile tradeoff.

Because I’m replicating, I don’t need to detail the analysis again; you can find that in last year’s post. I explored the following procedure: send each paper to two reviewers and, if the scores are too low, reject it without further consideration. Otherwise, send it to a third reviewer and then on the the program committee for decision. Varying the definition of “too low” provides a tradeoff between false positives (extra reviews for papers that ultimately get rejected) and false negatives (accidental early rejection of papers that would have been accepted). Looking at last year’s data, a pretty appealing threshold was to reject any paper whose two scores were both lower than 3. This is a natural rule because 3 is the “neutral” score in CHI reviews; both reviews below signifies that both reviewers recommend rejection. It was also a good threshold because it saved 469 reviews while creating only 6 accidental rejections.

So, did the results replicate this year? Applying exactly the same procedure, we get a remarkable level of agreement. Of the roughly 1567 papers submitted, there were 369 acceptances and 1198 rejections. Using the “two below 3″ rule, we skip 491 reviews of low-rated papers, while accidentally rejecting 4.7 papers (see last year’s post, or the discussion below, to understand why we get a fraction). An almost identical outcome, just slightly better.

Some caveats: the data I got was slightly messy, with a few papers showing no reviews or less than three. I presume these were withdrawn submissions, but haven’t had time to find out. There were less than ten of these, not enough to influence the results significantly.

For those who want to explore the data themselves, I’ve prepared a table of the relevant numbers. Score 1 and Score 2 are the reviewer scores; Accepts counts the number of pairs (remember, three pairs to a paper) from accepted papers that got those two scores, Rejects the number of pairs from rejected papers that got those two scores. All other columns are functions of these two. Ratio measures the ratio of accepts to rejects for a given pair of scores. I’ve order the rows by this ratio, which is useful for visualizing the optimum false positive/false negative tradeoff. Cum acc and Cum rej total the accept and reject pairs in the lines above, then divides by three so we can count papers (averaged over outcomes) instead of counting pairs. These cumulative totals count the number of accepts and rejects above the current line, thus telling you the number of papers from each category that would be given a third review if you used the given line as the threshold for deciding on that third review. False rejects then shows how many papers that were ultimately accepted would have been rejected in the first round using the given threshold, while saved reviews counts the number of ultimately rejected papers for which the threshold would have led to skipping the third review.

Note that the accepts and rejects columns are counting “review pairs”. Each paper in the data set got three reviews. If we imagine the chair selecting three reviewers but then requesting a review from only 2 of them (keeping the third in reserve for when the first reviews are good), then there are three possible outcomes. Counting over all three outcomes of all three papers yields the average outcome—the expectation should the chair select their two reviewers at random from the pool of three. It is this averaging that produces fractions in the other columns.

Score 1	Score 2	Accepts	Rejects	Ratio	Cum acc	Cum rej	false rejects	saved reviews
5	5	14	0	NaN	14	0	364.3	1197.3
4.5	4.5	37	3	12.33	51	3	352.0	1196.3
5	4	63	8	7.87	114	11	331.0	1193.7
5	4.5	41	6	6.83	155	17	317.3	1191.7
4.5	4	113	21	5.38	268	38	279.7	1184.7
4	4	125	31	4.03	393	69	238.0	1174.3
4.5	3.5	65	20	3.25	458	89	216.3	1167.7
5	3	22	8	2.75	480	97	209.0	1165.0
5	3.5	19	8	2.37	499	105	202.7	1162.3
4	3.5	129	68	1.90	628	173	159.7	1139.7
4.5	3	32	23	1.39	660	196	149.0	1132.0
4	3	70	81	0.86	730	277	125.7	1105.0
3.5	3.5	52	62	0.84	782	339	108.3	1084.3
4.5	2.5	20	29	0.69	802	368	101.7	1074.7
5	1	2	3	0.67	804	371	101.0	1073.7
5	2.5	9	17	0.53	813	388	98.0	1068.0
4	2.5	43	95	0.45	856	483	83.7	1036.3
4.5	1.5	8	18	0.44	864	501	81.0	1030.3
4.5	2	11	25	0.44	875	526	77.3	1022.0
4	2	39	95	0.41	914	621	64.3	990.3
3.5	3	48	117	0.41	962	738	48.3	951.3
5	2	6	20	0.30	968	758	46.3	944.7
5	1.5	2	8	0.25	970	766	45.7	942.0
3	3	14	66	0.21	984	832	41.0	920.0
4	1	5	28	0.18	989	860	39.3	910.7
3.5	2.5	30	172	0.17	1019	1032	29.3	853.3
4	1.5	6	36	0.17	1025	1068	27.3	841.3
4.5	1	2	13	0.15	1027	1081	26.7	837.0
3.5	2	24	199	0.12	1051	1280	18.7	770.7
3.5	1.5	6	68	0.09	1057	1348	16.7	748.0
3	2.5	15	188	0.08	1072	1536	11.7	685.3
3	1	3	52	0.06	1075	1588	10.7	668.0
3.5	1	3	55	0.05	1078	1643	9.7	649.7
3	2	10	214	0.05	1088	1857	6.3	578.3
3	1.5	2	107	0.02	1090	1964	5.7	542.7
2.5	2.5	3	155	0.02	1093	2119	4.7	491.0
2	2	4	223	0.02	1097	2342	3.3	416.7
2	1.5	3	227	0.01	1100	2569	2.3	341.0
2.5	2	4	331	0.01	1104	2900	1.0	230.7
2.5	1	1	83	0.01	1105	2983	0.7	203.0
1.5	1	1	144	0.01	1106	3127	0.3	155.0
2	1	1	157	0.01	1107	3284	0.0	102.7
1	1	0	94	0.00	1107	3378	0.0	71.3
1.5	1.5	0	76	0.00	1107	3454	0.0	46.0
2.5	1.5	0	138	0.00	1107	3592	0.0	0.0

Forums in the Document Margins for Classes and Reading Groups

Filed under: CHI, Collective Intelligence, Publication by David Karger on Friday, 4 May 2012 | No Comments
Tags: CSAIL

This year at CHI we’ll be presenting a paper on nb, a tool that lets students have forum-style threaded discussions in the margins of pdf documents. We’ve posted it in advance at the link above in hopes of getting some comments on it that can help us prepare our presentation. We’re also making nb available to you, if you have a paper at CHI and want some feedback on it.

We originally designed nb for class materials—lecture notes and such—under the hypothesis that attaching the forum to the content provides useful context that helps students see and participate in relevant discussions at the right moment in their reading. Our paper shows support for this hypothesis.

But we’ve discovered that nb is also quite useful for our research reading group. If we post the paper in advance and everyone annotates it, we get great material for reading group discussion, nicely organized for us as we traverse the paper. Recently, when we asked Parmit Chilana for a pdf of their CHI Lemonaid paper so we could mark it up this way, she mentioned that she’d like to see those comments to help her prepare her CHI talk. We thought this was a great idea, so we’re making it more generally available.

We’ve created a CHI channel on the nb site. You can sign on by clicking this link. There, you’ll be able to read and annotate/discuss any paper whose authors have provided it. If you’re an author and want to get some reader feedback, either before or after your talk, send the paper to sacha@mit.edu and we’ll add it to the site (a bit old-fashioned, but the system isn’t currently designed to let “student readers” upload papers to their classes).

Of course, to get some annotations you need some readers, and our system can’t help you with that! You’ll need to use some old fashioned techniques, like mentioning it on your blog and encouraging people to read and annotate it. For example, consider this blog post, whose first line encourages you to read and annotate our (paper on nb) on nb. I look forward to your comments!

Making change in Zimbabwe without coins

Filed under: Thought Piece by David Karger on Friday, 27 April 2012 | No Comments

This is a message in a bottle. I’ve got an idea for addressing a problem in Zimbabwe and no idea how to reach the people I’d like to share it with, so I’m going to see if perhaps it can propagate to them.

A couple days ago, the New York Times had an article on an unusual problem in Zimbabwe: lack of coinage. The country has adopted the US dollar to deal with hyperinflation, and dollars are in common circulation. But coins, which are a lot heavier and harder to ship, are in short supply, which poses a problem any time people make a non-whole-dollar purchase.

One blog post suggested a switch to electronic currency using mobile phones. I’ve no idea how well such technology has penetrated Zimbabwe. So I wanted to suggest a lower-tech solution.

There’s a pretty simple trick, related to a lottery, for “rounding off” purchase prices that could eliminate the need for change. I’ve seen it in print several times, though I can’t find a reference at the moment. Suppose you want to make a purchase of 33 cents. You pick a random number between 0 and 99. If the number is less than 33, you pay a dollar; otherwise you pay nothing. On average, you pay 33 cents. But in fact, you pay either 0 or 1 dollars—no coins are needed. More generally, if you owe k cents, you pay a dollar if your random number is below k; otherwise you pay nothing.

Of course, on a single purchase, you might be concerned about the possibility that you’ll be overpaying by a factor of 3. Indeed, it could happen that you pay a dollar when you only owe a penny (a 1 in 100 chance). And conversely, the store owner might worry about being paid nothing. However, over a large number of purchases, these outcomes will average out—each customer will spend about as much as they were supposed to, and each store will receive about as much as it was supposed to.

To implement this, all you need is an acceptable way to generate a random number. It needs to be low tech. And it needs to be acceptable to both customer and merchant—each should be confident that the other cannot cheat them.

So here’s one low-tech approach that could work. Each participant keeps a small deck of 100 cards (or other random scraps of paper) in their pocket, numbered from 0 to 99. To work out a payment, each participant reaches into their pocket, grabs a random card, and lays it facedown on the table. Together, the participants then flip their cards. Compute the sum of the two numbers shown, subtract 100 if it’s larger than 100, and use the resulting number (which will be between 0 and 99) as the random choice for the change protocol.

This is a good protocol because it works even if one party cheats. To see this, suppose that the customer is playing fair, and truly choosing a random 0-99 card from their pocket. Then it doesn’t matter what the merchant does. For suppose the merchant chooses card k (possibly in some biased, cheating way). Then, since the customer is choosing randomly, the resulting sum is equally likely to be any on of the numbers between k and k+99. Once we subtract 100 from the larger outcomes, we find all numbers between 0 and 99 equally likely, as desired.

As a simplification, note that the customer can make their choice at home, putting just a few random cards (or, just as effective, a few scraps of paper with random numbers written on them) in their pocket in the morning and using them for the days purchases. So long as they don’t purchase from the same merchant twice, the merchant has no information they can use to cheat the customer (conversely, if a customer returns and uses the same card, a cheating merchant can take advantage of that knowledge to ensure they get paid). As another variant, the merchant could keep two decks, one to be used by the customer and one by the merchant. The customer will want to inspect their deck, but this would be pretty easy if the cards were kept sorted.

Is this practical? I’m not sure. But the “only” thing it needs is some paper. Plus some basic mathematical skill, but, importantly, the same mathematical skill needed to compute the cost of two items—a skill I think we can safely assume of anyone who is making purchases.

I’d love to float this idea past someone closer to Zimbabwe, who might be able to comment on its feasibility. If you know someone, please pass it on!

NICAR, from a programmer’s eyes

Filed under: eGovernment, News, Thought Piece by Edward Benson on Monday, 5 March 2012 | 1 Comment

Last week I attended NICAR 2012, a conference for computer assisted investigative reporting. I was there to help David teach reporters how to use tools such as Datapress and Exhibit and to learn about the needs and state-of-the-art of computers in reporting. It is always a privilege to get to visit and observe someone’s world as an outsider; and even more so to see how they are using tools from your world to do their work. So here are some parting thoughts I took away from the conference: NICAR from the eyes of a computer scientist.

Visualization is just the “last mile” of data in reporting. And an optional one at that. We spend a lot of time talking about data publication and visualization tools in Haystack, but this is just one small slice of the needs of computer-assisted reporting. A story might take months of investigative work- gathering data, cleaning data, interviewing people, assembling scraps of paper — and a presentation of that data is only prepared in the final run-up to publication. That presentation isn’t always a wiz-bang interactive graphic, either. Many times a data-intensive story might be presented entirely as narrative, if the medium fits better.

Scraping tools seriously needed. Web scraping wins the award for highest ratio of need over capability. Scraping the web is absolutely essential to do good investigative work when it comes to municipalities, many of which publish web pages with daily administrative information (such as arrests) while removing the previous days’. Without a scraper, reporters would have to spend a large portion of each day copying and pasting this information down into a spreadsheet by hand.

Big Opportunities for Automation. Ben Welsh of the LA Times gave a great talk about how he automates his reporting through a combination of web and email scrapers, databases, and automated copy generators. The goal being to auto-generate 100% of reactive stories (deaths, arrests, etc) and then go back and rewrite the most important ones by hand. Reminiscent of AtomsMasher for the newsroom.

And machine learning, too. Tools that enable reporters to perform topic modeling and hierarchical clustering are making a big splash. They can go a long way toward helping a reporter understand a big data dump so they know what documents to focus on. I think the coming years are going to big for the dissemination of machine learning components into a lot of consumer software. Tools that enable reporters to say “give me more documents like these ones” will be a bit hit.

The CMS is Broken. One refrain I heard over and over is how much the reporters have to fight with their CMS. For reasons both technical and administrative. A common solution seems to be for custom news apps to be hosted out of a subdomain on third party sites (AWS, Heroku, etc) with window dressing to provide the illusion of being a part of the main news site. However as a totally separate entity, these news apps don’t get integrated into the standard RSS feed, advertising system, top stories feature, and other critical elements of the CMS-managed web of data, casing traffic and revenue challenges for their authors.

What happens when your paper is the business of causing protests? I went one session where the creators of curbwise.com, two employees from The Omaha World-Herald, discussed the hopeful (revenue-wise) but new territory of transforming the news into apps. Here’s the gist: print ad revenues are falling, but online ad revenues are a pittance in comparison. To make up for lost revenue, newspapers can exploit their intimate knowledge of a locale by creating community-specific information sites and charging for them somehow. But what happens when that site is, like Curbwise, a way to protest your home’s valuation? Now the newspaper has a financial interest in causing people to protest their home valuations. Is that territory we should be comfortable with newspapers occupying? Do they occupy it already (to the extent that extreme news is news that sells well, so there’s always an incentive to fan a fire)? Food for thought.

Appification of news, in general. Continuing on the previous thought, there was enormous interest in the idea of transforming news into for-fee “apps” that deliver a targeted news experience. Such as paying a small fee to get your kid’s high school football scores in a format that looks like ESPN.com.

The need for computer science as a liberal arts requirement. If ever I haveeen a good argument for computer science as a liberal arts requirement, going to NICAR was it. It was amazing and energizing to see the extent to which computers are enabling better reporting and storytelling. In some cases, surprising to see how programming has become an essential tool for some areas of reporting. In today’s world, knowing how to program better equips you to make sense of the information around you and communicate your findings to others.

The need for computer scientists to grok liberal arts. On the other hand, we as computer scientists need to be delivering tools — serious data crunching tools, visualization tools, curation tools, scraping tools — that are built for use by people who spend their days thinking about things other than computers. Because I want my local reporters to spend their days fact checking the good stories, not brushing up on Python.

Personal (Information Management) is not (Personal Information) Management

Filed under: CSCW, PIM, Thought Piece, Workflows by David Karger on Friday, 17 February 2012 | 2 Comments
Tags: CSAIL

I spent last weekend at the 2012 PIM workshop, located at CSCW 2012. This was the 5th such workshop. Appropriately for its setting, this one focused on “PIM in a socially networked world”—i.e., the aspects of PIM emerging in the interactions between multiple individuals. The focus clearly highlighted the distance between two different notions of PIM.

Information About Me

Historically, PIM has studied the tools and techniques people use to work with their own personal information. But with the emergence of social networks, many people discover that their personal information is being managed by other people. Our tweets and Facebook status updates are clearly personal information, but we are publishing them for general consumption. More thought provoking, one PIM attendee described her grandmother’s surprise and displeasure on discovering that she (the grandmother) had been tagged in several Facebook photos. She wasn’t even on Facebook, yet this quite personal information was uploaded and being seen by others. (Ironically, had she wanted to untag those photos, she would have had to join Facebook, and in doing so reveal other personal information.)

These examples highlight the aspect of PIM dealing with disclosure of personal information. Many people would like to manage who sees what information about them and when they see it. There is need for interfaces that help people understand and manage what they are disclosing and what others disclose about them. This is not only a technical problem; clearly there are ethical, social, and legal questions that must be addressed: what rights do individuals have to limit the information disclosed about them, and how can those right be enforced? Do we simply rely on social norms to prevent the inappropriate disclosure of personal information? Should it be a requirement to notify people when their personal information is disclosed? Should there be laws forbidding such disclosures in certain circumstances?

Information For Me

I generally focus on the other kind of PIM: tools that help people manage arbitrary information for their own purposes. Rather than being about the person, this can be impersonal information that has been brought into the user’s “orbit” by some task they have to do—data from or for work, news or entertainment they consume, or information they are managing on behalf of some other individual. This is an incredibly broad class of information—just about every type of information can become part of your personal space.

For that reason, and because of the possible conflation with the previous “disclosure”-focused version, I find myself considering a different name than PIM: End User Information Management. This phrase captures the crux of the problem—not the information being managed, but the person doing the managing. It covers nearly every imaginable form of information, but unlike, for example, databases, transaction processing or scientific visualization, it focuses on problems encountered by end users without specialized training, and the tools and techniques that these non-specialized users can understand and use effectively.

I wish I could claim inventorship, but there is already some limited use of this term. Gary Marchionini wrote a 1992 paper on “End User Information Seeking.” Mark Gregory has a survey on End User Information Management tools.

This label connects nicely to End User Programming, a closely related field. End users often have workflow tasks that could “easily” be accomplished by programming. But most end users are unfamiliar with programming languages, approaches and tools. End User Programming aims to develop more broadly usable tools that put at least some of the benefits of programming in the hands of regular users. The UID group at MIT has contributed to this area with tools like Chickenfoot and Sikuli. Given the role of computation in effective information management, End-User Programming clearly has an important role to play in End User Information Management.

Perhaps the first serious end-user programming was Visicalc, the original spreadsheet. The spreadsheet cells could hold multiple pieces of inter-dependent state, enabling the user to describe complex multi-stage computational processes without authoring a program. Debugging was also simplified: instead of having to trace an execution, users could see all stages of the computation simultaneously displayed in the many spreadsheet cells.

Interestingly, the spreadsheet has also turned out to be the dominant end user information management tool, allowing users to store databases with arbitrary schemas as spreadsheet tables. A colleague once told me of an extensive study he performed (but was never permitted to release) showing that most spreadsheets did not contain numbers: they were being used as databases, not as calculation engines. Despite the availability of more sophisticated database tools, even those with UIs such as Access, end users seem wedded to simpler spreadsheet relatives. Spreadsheets’ use as databases has driven some evolution, as we now see spreadsheets offering sorting and filtering functionality not particularly relevant to their original accounting applications.

Untangling the Two

The two types of PIM are often considered together. This is understandable; at first glance a lot of the information managed by end users is in fact personal information—contacts, calendars, messages, personal photos and other media. But I believe that this is a deceptive connection. The information challenges I face trying to organize my personal photo collection (clearly a PIM activity) share a lot with the challenges faced by a professional photographer organizing his portfolio, which in turn are similar to those faced by a biologist organizing his specimens or a salesman organizing his samples. When I organize my music for pleasure, it’s obviously PIM; the very similar work I do organizing music to DJ at my Israeli Folk Dance session must also be considered PIM.

Both kinds of PIM benefit from separate consideration. For (Personal Information) Management, it’s important to realize that this problem reaches far beyond the subject of the information. My personal information appears in many places and is managed by many people, and beyond the basic technical problems there are broad issues of ethics and policy. Conversely, as we consider End-User Information Management, it’s important to recognize, that it’s a problem much broader than dealing with our calendars, email, and social media. End User Information Management aspires to give users the ability to work with a tremendous variety of information types, often requiring significant domain expertise. But it aims to provide these abilities to individuals who have no specialized skills as programmers or information designers.

So far, the common approach to this problem has been to completely dis-empower users, packing the entire information management process into rigid applications that do everything the way their developer thinks it should be done. I think we can do better, leveraging more of users innate understanding of their information to manage it more effectively, without requiring them to become database engineers. But how to do so is a subject for a different post.

NetBeans Platform IAP Workshop

Filed under: News by Eirik Bakke on Monday, 6 February 2012 | No Comments

Last weekend, Geertjan Wielenga came to Boston to hold, for the first time, the official NetBeans Platform Training Course as an IAP workshop here at MIT. It was a great three days, and as for myself, just about every single thing we were taught during the course will go straight into the software I am building for my Ph.D. project.

[Last Day Group Photo]

The NetBeans Platform, if you haven’t heard of it, is a large collection of Java APIs that work together to help you create production-grade, IDE-style desktop applications without spending years of development time re-inventing standard features such as dockable window panes, tree-views with nodes that can be opened into tabbed documents, graph views with draggable and selectable nodes, property sheets, automatic software updates, web launchers, installation packages, user-configurable menus, toolbars, and keyboard-shortcuts (or even a Ribbon!), context-sensitive actions, and much more. A major feature of the NetBeans Platform is also the module and service lookup system, which helps you plug all of these features together in a decoupled way, so that individual domain-specific features can be developed independently of each other. In fact, many companies are porting their applications to the NetBeans Platform exactly to take advantage of the module system and to disentangle their existing spaghetti code. Take a look at these screenshots to see some of the many hundreds of large-scale applications that have already been built on or ported to the NetBeans Platform.

To see what a completely bare-bones NetBeans Platform application looks like, click here and ignore all those pesky security warnings Eventually I’m going to port my existing research code into this kind of an empty shell of an application, and it should get some actual features. But for now, notice how we already have all the basic menus set up, a toolbar, a full-screen mode, and extendable options dialog with programmable keyboard shortcuts, a property sheet interface, and dockable subwindows. With a little bit of work, we can get a very professional-looking application up and running in a short amount of development time.

Read Geertjan’s blog post about last weekend’s IAP workshop here.

Programming well in Javascript

Filed under: Thought Piece, Tinkering, User Interfaces, Web Architectures by David Karger on Monday, 12 September 2011 | 9 Comments
Tags: CSAIL

With my background as a theoretical computer scientist, I’m a terrible programmer (Back in college taking operating systems, my team got special mention for having the most elegantly designed operating system, all built around a single semaphor API. Of course it only executed for 30 seconds before crashing). But sometimes, when I can’t convince any of my graduate students that it’s important enough, I have to step in and try to fix up some of our tools myself. My Haystack group does a lot of HCI research on the web, which means a lot of our tools are in Javascript. As I’ve been working to tweak those tools, two really obvious flaws in the environment, that pretty much force bad programming practice, have been jumping up repeatedly. I’m curious why these flaws haven’t been fixed, and whether any of you readers have advice for overcoming them.

Both flaws stand out in some work I’m doing on our Dido system (a client-side WYSIWYG tool for managing data and its visualizations using Exhibit). I’m trying to add a “Wizard”—a wrapper that will walk people through a sequence of interactions. Each of which is already accessible using a toolbar, and pops up a dialog for the user to perform some operation, but the Wizard will save the user figuring out the toolbar by programatically opening each of the dialogs in sequence.

I’m using jquery-ui for the dialogs. The dialogs themselves are written in html, then buttons are defined with Javascript behaviors attached to them. And this raises the first problem—fragmentation of modules. Any dialog consists of an html part and a Javascript part, which pretty much forces them to go into separate files. Which means you can’t get a unified picture of the “component”—its Javascript and html. The html needs to be part of the main page (unless I want to go off and fetch auxiliary html content) while the Javascript should be in a separate js file. In theory, I could write js code to dynamically generate the html I need, but this is really contrary to the notion that the dialog is in fact static html, and I should be able to look at it that way. Given Javascript’s allergy to newlines in strings, it’s hard for me even to include the static html as a blob in the js. Obviously I’m not the first person to be in this situation. Are there any nice ways to package a “library” of Javascript plus html as a single, editable file that can then be included via a link from the main document?

The second problem emerges from the asynchronous interaction model of javascrit. Like any browser-javscript library for this user interaction, jquery-ui is asynchronous. My javascript can make a call to open a dialog, but then that thread of computation ends and interaction with the dialog is handled through callbacks that are invoked when dialog buttons are clicked. These callbacks have no automatic connection to the thread that opened the dialog. My Wizard doesn’t want to do things this way: I want to invoke the dialog, then have the wizard pick up when the dialog is closed.

Of course there’s a way to do this in javascript—continuation passing. I pass in a function that should be invoked when the dialog is closed, that picks up Wizarding where the dialog open left off. This works just fine. But I don’t like it. The unrestricted passing of continuations lets people deal with them arbitrarily—which permits cool hacks but also gives the programmer autonomy to do hard-to-understand things. It’s like bringing back goto—it can be used properly, but generally isn’t. The last time I had to explicitly pass in a “return address” was when I was working on the assembly-language-based recalculation engine for Excel version 2. High level programming languages are supposed to insulate me from managing the call stack!

And with the right language elements, this should be possible even in an asynchronous environment. The semantics of a subroutine call are that computation should pick up on the next line when the subroutine completes. So what if the completion of that subroutine is driven by an asynchronous event? i.e., the dialog subroutine is one that starts by opening the dialog box, then yields until a button in the dialog is clicked, then picks up processing to figure out what to do about the clicked button. And if it can remember that it is “picking up” from a previous thread, then that thread can return to the function that originally called the dialog. I’d love to see javascript introducing language elements to support this, and I’m puzzled about why they haven’t already done so. If any of you know any ways to cope with this, I’d love to hear.