In this post, I have typeset many more sentences in bold than I usually do, so readers can quickly skim through it.

I applaud the efforts of U. Colorado’s EPIC Group in assisting the victims of the Haiti earthquake in calling for help using Twitter, and to make their tweets discoverable and actionable. I just performed a Twitter search for the terms #haiti -RT -http (includes all Tweets tagged #Haiti, except retweets or links) to inspect some of the tweets that are directly related to happenings on the ground, and they are (as expected) only a minuscule percentage of the total number of tweets about #Haiti. Syntax is thus sorely needed to achieve a decent signal-to-noise ratio to assist relief efforts.

Though, in my opinion, the current version of the tweet syntax seems too formal, too rigid and a tad too complicated for victims or rescuers on the ground. I am a programmer, and even I had trouble mentally parsing a few of the examples provided. We must keep in mind that Haiti is a bi-/tri-lingual country (and neither of them is English), so any syntactic terms used should preferably be semi-obvious to non-native speakers of the language as well as rescuers.

Roles of Microsyntax

1. Make tweets discoverable: Microsyntax can assist local search-and-rescue efforts and unaffected Twitter users in determining if a tweet is actionable. This task is partly a Signal Detection Task and partly a Data Mining problem. In both situations, microsyntax can prove helpful: all that’s needed is a single tag that emphasizes that a particular tweet is actionable (versus not), e.g. #haiti #rescue (or #haitirescue, to avoid having to type a second # (hash) sign). This will greatly increase the sensitivity parameter d’ of the signal detection task.
2. Make data mining easier: Once a tweet has been detected to be actionable, its contents must be parsed into a form that local efforts can take action upon. While it’s true that all the other proposed microsyntactic tags make it easier for applications to parse the data, this is at the cost of requiring users to learn new syntax. This seems to me a little too much to expect from victims of a recent calamity of this scale as well as from rescue workers with other higher priorities. Instead, as long as our tools can identify relevant tweets, computers should be able to perform the second task of parsing locations, names, and verbs from tags quite easily.

Also, microsyntactic terms need not always be prefixed with # (hash) signs; they are often difficult to type using cell phone keyboards, and on some handsets, may hamper input methods such as T9. Because of the intervening # signs, Tweets containing the proposed microsyntax decrease typographic readability for someone browsing through tweets.

To summarize, this imposes a heavy cognitive load on victims and search-and-rescue efforts while making parsing easier for machines. However, the task of parsing details from tweets can also easily be performed by large numbers of humans a.k.a. crowdsourcing via volunteer efforts or via tools such as Amazon’s Mechanical Turk.

Simpler, Lighter Microsyntax

The following are examples of microsyntax that are more readable, yet also parseable by machines. All situations are based on the ones in the original proposed microsyntax. Most are directly based on the EPIC microsyntax, with a few simplifications.

• Rule 1: Always write in the third-person. This takes care of part of the name problem.
• Rule 2: Instead of using #loc for locations, use “at”. It’s much more natural and not much more difficult to parse.
• Rule 3: Verbs are actionable. Not syntactic verbs, but English (or French or Haitian Creole) verbs. It’s a trivial task to populate a tool with a dictionary to detect all word forms correctly.
• Rule 4: Anything that cannot be parsed ends up as the equivalent of the #info tag (see EPIC syntax).
• Rule 5: The entire text of the tweet should always be available to a human, so whatever information was incompletely parsed can be understood manually, and optionally added to the parsed version by a human.

The general aim is to require as little syntax knowledge as possible, and to keep as close as possible to the natural way people write tweets.

Examples

TWEET-BEFORE: Sherline Birotte aka Memen. Last seen at 19 Ruelle Riviere College University of Porter a 3 story schol building
TWEET-AFTER: #haiti #ruok #name Sherline Birotte aka Memen. Last seen #loc 19 Ruelle Riviere College University of Porter #info a 3 story schol building
Simplified Microsyntax: #haiti #rescue Looking for Sherline Birotte aka Memen. Last seen at 19 Ruelle Riviere College University of Porter, a 3 story school building

This tells the computer us:
What = Looking for someone.
Who = Sherline Birotte aka Memen (identified fuzzily based on initial capital letters)
Where = 19 Ruelle Riviere College University of Porter (automatically parsed based on “at”)
What else = “a 3 story schol building” (i.e. everything else in the tweet)

TWEET-BEFORE: Mirna Nazaire lives in P-A-P at Bizoton 6#12. Entire neighborhood without food. People are dying.
TWEET-AFTER: #haiti #need #food #name Mirna Nazaire lives in #loc PAP at Bizoton 6 #12 #info neighborhood w/o food. People dying
Simplified Microsyntax: #haiti #rescue Mirna Nazaire at PAP at Bizoton 6#12 needs food. Entire neighborhood without food. People dying.

This tells us:
What = needs food. (automatically detected from the verb in the sentence.)
What do they need = food (automatically detected from the object in the sentence.)
Who = Mirna Nazaire (heuristically determined from initial capital letters.)
Where = PAP at Bizoton 6 #12 (detected from microsyntax “at”)
What else = “neighborhood w/o food. People dying.” (Rest of the tweet, unfiltered.)

TWEET-BEFORE: French hospital is now open and ready to receive the wounded at the french lycee in rue marcadieux bourdon
TWEET-AFTER: #haiti #offering #med #loc french lycee in rue marcadieux bourdon #num 30+ #info French hospital is open and ready 2 receive wounded
Simplified Microsyntax: #haiti #rescue French hospital ready to offer help to 30+ wounded at the french lycee in rue marcadieux bourdon

This tells us:
What: Hospital. Also, something to do with medical efforts. (no need to tag explicitly, we can infer that from ‘hospital’.)
Where: The french lycee in rue marcadieux bourdon. (Automatically parsed from microsyntax “at”.)
How many people: 30+. (It’s already a number, no need to state “#num” explicitly.)

These are just a few suggestions. I will be contacting the PIs (principal investigators) of the EPIC project directly with some of my recommendations, but please continue to follow their syntax until they recommend anything different. The current syntax proposal isn’t perfect, but it is more important to avoid fragmenting the tagspace.

Update: I implemented this idea at http://queryprotocol.appspot.com. Comments, questions, and suggestions are welcome!

When trying to explain a concept to others over email, I often find myself linking to a search engine’s result pages for a specific query, instead of a single destination URL. These are non-navigational queries, and there is no single result that I expect to be the most important one. Instead, my intention is to provide the reader a variety of links on the topic such that s/he may draw her own conclusions, or solve their own problem — all they need is a nudge towards the right query term to use. If, over time, better search results are available for the same query, then future readers get the benefit of automatically updated results.

E.g. Q: Where can I find the latest numbers related to the spread of the Swine Flu?
A: Try [H1N1 update].

To do this today, I simply link to my favorite search engine, Google. But that does not seem fair to fans of other search engines: Bing, Yahoo!, Altavista, and others. I would prefer to use a notation that allows the reader to use their choice of search engine to obtain the results. Just as we specify our default browser and default email client, we should be able to pick our default search engine.

We have already solved the first two problems (picking default browsers and email clients) using protocol handlers in the operating system. When I pass around a link to a web page, starting with http://, I do not specify the browser it should open in. Your operating system determines that it’s a link to a hyper-text transfer protocol (HTTP) document, and invokes your default browser. Similarly, for emails, the mailto: protocol provides for an application-agnostic way to invoke the user’s default email client to send an email.

It is easy to see how a query: protocol could be implemented similarly. To point you to the search results for a particular term, I would send you the following link: (don’t click on it, it won’t work — at least as of this writing.)

[h1n1 update]

The URL that the above links to is query:h1n1+update. Note there’s no HTTP protocol marker specified. If the OS wanted, it could provide local results as well. This means that the protocol extends seamlessly to Desktop Search as well.

Syntactically, this validates as a URI. Just as the mailto: protocol handler defines standard parameter names, subject, cc, and bcc, similar parameters can be standardized for the query: protocol. These may include corpus restricts (corpus={web, images, desktop, ...}), pagination controls (start=0, num=10), or domain restricts (site=manas.tungare.name).

Implementation is simple: all operating systems and major browsers support external custom protocol handlers. They can be configured as follows:

Protocol Prefix: query
Application Name: /Path/to/Application

The application does not need to be very complicated. It’s a mere stub, which, depending upon the user’s preferred search engine, converts a URI of the form query:h1n1+update to http://google.com/search?q=h1n1+update or http://bing.com/search?q=h1n1+update and opens that link in the user’s default browser.

Eventually, if browsers understand the query: protocol, there is no need for the stub application, and users may be able to share and exchange queries and yet seek results using their favorite search engines.

(The opinions expressed in this blog post are solely my own, and may not reflect the opinions of my employer, Google.)

The entire idea behind this blog post has been summed up in the title, so all I need to do now is to explain why I think email should have expiration dates, and how that would make personal information management better.

Email, as we all know, started off as a way of sending short messages to colleagues within a department. It has since evolved into a monster of a tool that does everything it was never designed to do. The paradox is that it is exactly the kinds of messages that email was designed to handle that cause me the most trouble these days.

1. I often receive email from my friends about meeting up for lunch. This is important, but only for that particular day (and that too, if I receive it before lunch time).
2. My research collaborators send me email when a paper submission deadline is near, with the draft attached to it. Those emails are not nearly as important after the deadline.
3. My friends and I exchange travel plans over email, but is it as useful after the trip is done?

These are the kinds of messages I’m talking about: important but time-sensitive. Then there are others which are not really important, but simply one-time notifications that I can take action on and then forget (“bill is due in 2 days”, “X added you as a friend”, “your order was received”, “your package has shipped”, “free donuts in break room”, “we are not meeting today”, etc.)

Why do they linger on in my mailbox for years? They become indistinguishable from the really important email that I need to save for years, such as some very interesting and intelligent discussions I have had with others. Note that I’m not including spam in this discussion, because in my opinion, there are adequate spam-filtering tools circa 2008 that perform well enough for most users for the most part with an acceptable false positive rate. Not perfect, but acceptable.

The Keeping Problem

Email is no longer ephemeral — people hold on to their email for years. This is what results in the Keeping Problem in Personal Information Management: there is so much of information coming at us that we don’t want to spend the time to decide what to keep and what to trash, so we end up keeping all of it. We hope we never have to do spring cleaning, and instead rely on search to find what we want.

Filing is not the answer

Many people file and tag their email, but the question is, is the cost of doing so (time as well as attention) worth the payoff at the end? Consider the two alternatives: spending 10 minutes each day filing your email, versus spending an hour a month looking for that one email. Pretty soon, the second alternative starts looking better while swimming in a sea of email with no signs of abating.

Same needle, bigger haystack

The bigger the haystack grows, the harder it is to find the needle. The solution is to reduce the size of the haystack. Automatically. Most other solutions empower the user to filter, sort, file, tag and do other sorts of things to their email that do not scale very well. That’s where Email Expiration Dates come into play. For it to work, they need to be (1) defined and (2) honored.

Defining an Email Expiration Tag

Email expiration tags can be defined in several ways by several entities that handle the email message at some point of time in transit.

1. By the sender of that email who cares about the recipients;
2. By the email client (MUA) used by the sender, automatically inferring from certain common-sense words; e.g. subject contains lunch and body is less than 100 bytes;
3. By the email server software that intelligently tags email based on common patterns seen across multiple users;
4. By the recipient’s email client, based on heuristics;
5. By the recipient’s email client, based on a user-defined rule set;
6. Or explicitly by the recipient in a spring cleaning session.

Honoring an Email Expiration Tag : Fully standards-compliant

RFC 822 allows custom tags (Sec. 4.7.5). These are commonly referred to as X- headers, since the specification requires that all such tags be prefixed with “X-”. Many applications built on email make use of such tags: mailing lists use the X-List-* headers to specify the list name, subscribe URL and unsubscribe URL in a mail message. Spam filtering software such as SpamAssassin assigns a score to each email, saved as an X- header. Mail clients are free to interpret these tags as they see fit.

An expired email will not be automatically deleted if the user does not want it to be. This is important for archival purposes and to satisfy the stringent reporting requirements of the Sarbanes-Oxley Act. But now the user can make a one-button choice about whether or not expired emails be deleted, archived, moved away or kept around.

With help from legitimate bulk email senders (not spammers)

Bulk mail such as Facebook notifications could have expiration dates set to “one week after receipt”. Bill reminders could set the expiration date to be “2 days past deadline” (and then send another notification if payment is not received by then.) Donut announcements could expire at the end of the day. Talk announcements could expire at the end of the talk.

Fixing the post-vacation blues

Returning from a vacation is no longer refreshing, as we are thinking about the sheer volume of email we need to process once we get home. If I was on vacation when the donuts were on the table, I should not be bothered about it when I return. Go away! If it’s an invitation to a talk that happened while I was away, I don’t need to hear about it now.

What will it take for adoption?

Defining a standard is no use if it isn’t used. The best way for such a solution to be adopted is for a major email provider implement it themselves, perhaps in a limited beta? On the interface side, this requires two additions: one for sending, one for processing received messages. The widget at the sender’s end is simply a calendar picker, or a drop-down with relative dates (“tomorrow”, “next week”, etc.) At the receiving end, it’s a three-way radio button that lets users “Delete”, “Archive” or “Leave alone” expired messages.

Till then, it’s back to manual spring cleaning. Oh well.

Acknowledgments: I have had several stimulating discussions with my advisor, Manuel Pérez-Quiñones, and my colleague, Pardha Pyla, about our respective email filing strategies, (that mostly began as venting sessions). This idea no doubt borrows from my analysis and conclusions based on some of those conversations.

I ask you, the blogosphere, to enlighten me on the best way to eat Pringles that does not involve a bowl. The Pringles can is one of the iconic designs of modern times — uniformly-shaped potato chips in a tube — that seems to value form over function.

Let’s admit: eating chips is a secondary task for most Americans. These are snacks people munch on when they’re doing other things. Thus, these chips should be easy to grab with one hand and have the other hand free for the television remote, steering wheel or keyboard/mouse. At the same time, it is important that chips don’t spill, or worse yet, crumble in your hand. So what’s the best way to eat them without needing a bowl? (because using a bowl would just be weaseling out of this problem into one already solved in The Textbook.)

The first few chips are easy. (Isn’t that the case with everything? ) They’re within the grasp of your fingers, so it’s no different than plucking a few chips from a bag. It’s after the top few disappear that the problem starts. Should I force my hand into the can? Should I invert the can so the chips fall out into my hand? Should I tilt the can ever so slightly and tap on the side to have the chips exit one by one instead of stampeding all over themselves?

I’ve tried to dig in with my hand to get to the next few, but my hand is too big to fit inside the can, and it’s probably not a good idea anyway. I shudder to think of the day I’m in an Emergency Room with a Pringles can wrapped around my wrist, with $200/hour doctors cutting off an embarrassing roll of cardboard from the one organ that distinguishes men from apes. No, excavating anything but the top few is a job for professional archaeologists.

I’ve tried inverting the can with the lid on, so (I hoped) the chips would all accumulate on the lid, and then I could simply open it up and eat a few. The problem is, the quantum stable state for potato chips is a pile of crumbs. Inverting the can gets all the crumbs to the bottom of the can, and when the lid is opened, that’s what comes out first.

I’ve tried tilting the can at a precise angle and knocking on the side until the top few chips make their way slowly out the door. This sometimes works, but takes a long time, and very skillful knocking/tapping/flicking to get the right number of chips out of the can. Often, you’ll spend five minutes tapping unsuccessfully, then, out of a burst of frustration, you’d tap just a little bit harder, and have Pringles rain upon you. No go.

Dear Mommy taught me to search the Web before posting random questions to total strangers, so I did my homework. Here’s an innovative method of eating Pringles, but I’m no chopsticks ninja. And eating chips with chopsticks vaguely reminds me of the Seinfeld episode with George eating Snickers with a knife. You get the point, sort of.

So my question to you is, what’s the best way you’ve found to eat Pringles out of a can without spilling any crumbs, using a minimum number of hands to do it? A second, deeper, question, from my obvious position as a design and HCI person is, why has such a design resisted change over so many years despite being so hard to eat from?

I often find myself talking to people who I should know (in theory), but for some reason, in practice, my neurons refuse to make the right connections to remember these connections. Wouldn’t it be great if someone designed a heads-up display based on your social network?

This is how it would work: when I activate it, and it notices I’m talking to someone, it would do a quick scan and tell me his/her name. That would be a life-saver, and would avoid the first five minutes of the 20-Questions game I have to play every time this happens (while making sure that the other guy (or girl!) doesn’t notice I’m playing the game in my mind.)

It could also tell me how I know that person, because sometimes I remember the name, but nothing else. Wouldn’t it be helpful to know that I’m talking to John Doe, who went to the same high school as I did, and who is now President and CEO of a Fortune 100 company (note to self: graduate soon.)

Not just names, it could even tell me more about the person I didn’t already know (or, in the more likely case, I’ve forgotten.) I’d love to know that my friend John Doe is no longer with his (now ex-) girlfriend Jane, so that would cut out a lot of awkward conversation. Knowing that he just went on a cruise to Alaska would instantly give us a topic to chat about. Knowing that the lady on his arm is not his wife would probably also help. I could ask him about our common friends and if he were in touch with any of them. And then he could use his heads-up display to pull their details up and tell me what I’d already looked up, but that’s another story.

So why isn’t something like this on the market yet? I’m sure there would be throngs of people lined up outside the offices of the company that makes the first such thing. And if they try to patent it, you can cite my blog post as prior art. You’re welcome.

Update: A picture is worth a thousand words. A movie, perhaps a million?

Public transit seems to share many of the characteristics of the third place, as Ray Oldenburg calls them in The Great, Good Place. They’re full of people from all walks of life, having random conversations, and brings several of the same people together with amazing regularity.

Sitting at a café as I write this, and having used public transit for the three months of my internship at Google, I’ve wanted to pen these thoughts down for a long time. Every morning and every evening, I used to hang out with the same set of people. Sometimes a few fresh faces would make their way onto the bus; sometimes one of the regulars would sleep in late and miss their bus.

Whenever I happened to take a later bus than usual, some time around noon, the commuter crowd would have shrunk down to a trickle, and most passengers would be headed to finish off errands, or simply out and about the Bay Area. These passengers had an even greater rapport with the bus driver: I’ve been part of thoroughly engaging conversations with these people, who I do not know the names of, and probably never will. For them, it was a natural group that had formed because of their respective travel habits.

Public transit is markedly absent in America, but it is alive and kicking in most other countries: I’ve seen it in Dublin, I’ve seen it in Montréal, I’ve seen it in Bombay. The local trains of Bombay are the lifeline of the working population. The frequency and timeliness of the trains is something to be proud of (regrettably, the same cannot be said of the rest of the population.) Thus, groups of commuters who travel by the same trains day in and day out form their own cliques. There’s even a name in the local lingo for it: “train friends.” Just as you have family friends and work colleagues, this is a part of your social life that stays with you for a significant part of your life. You don’t visit the homes of your train friends; you hardly talk shop with them; and you hardly meet them outside of the commuter context. But the place is a third place, after all.

As in all the other instances of the third place having a strong existence in Europe and all over the world, but lacking in America, the “place” of public transit exhibits similar properties. In USA, commuters are holed up in their oil-fueled cars and vans and SUVs, all the while blaming the other guy for causing all the traffic jams on the 8-lane highways. It is obvious that this causes at least a small amount of increase in stress levels of the driver (though I can’t be bothered to look up a citation for that right now.) Compare that to urban populations elsewhere that share conversations on a bus or a train.

Ray Oldenburg could probably add “keeping stress levels low” to the ways in which third places affect the daily lives of those who inhabit them.

It’s not often that one gets to be in a meeting with Vinton Cerf — who’s credited as the “Father of the Internet”, and holds the official job title of “Chief Internet Evangelist” at Google. (No, I’m not kidding.)

So when I was invited to a research meeting with him, my mentor Bill Schilit, and others at Google, I was totally in awe. Of course I can’t discuss what we talked, but the little kid in me was awe-struck enough to want to write a blog post simply mentioning it!

I remember having seen him first about 9 years ago. I was a sophomore at Bombay, and I heard from the ACM community that Vint Cerf was to give a talk at SNDT, Churchgate. It was examination time, and as hard as I tried, I couldn’t get anyone else enthused enough to make the hour-long journey to listen to Vint Cerf’s talk. In an engineering school with over 800 students, I had expected to find at least a few takers. None. Nada. Zilch. Everyone was too concerned about their examinations to find time to listen to the Father of the Internet. I gave up, took the train, and went to the talk, all alone. It was totally worth it, I recollect his ambitious Interplanetary Internet project back when he was at MCI.

I had never imagined that 9 years later, I would be attending a meeting with him. It’s not a dream come true, because I had never even dreamt it would be possible to share a table with Vinton Cerf.

Why do I have to search for the search box on any site I visit, before I can type my query into it? Given that almost every well-designed site has a search field, and it has been recommended as a good usability practice since 2001, why is it sometimes hidden deep inside the layout? Here is a suggestion for a change in the browser UI that will enable users to find the search box faster. Even faster than other suggestions so far. It only involves a little semantic markup on part of page authors and some redesign on part of browser makers.

The search box within the browser is underused.

The search box is one of the few basic design patterns omnipresent on the Web. It is also a de facto usability practice to place this search box towards the top right corner of the page. Yet, every site has it at a slightly different location (and some, even towards the bottom.) The user needs to search visually for the search box, or at least glance around until she finds it.

During this entire time, the search box within the browser chrome typically lies unused. It has a default search engine defined where it directs all queries typed into it. Why can’t the currently loaded website take advantage of this in-built search field for its own site-restricted search?

How it would work:

When a user is browsing a site that supports this feature, any searches conducted using the browser search box will send the queries to the site in question, and be able to display search results directly. When no site is loaded, the queries are directed to the user’s default search engine, just as it is now.

This proposal does not require any significant changes to any markup language — all that is needed is to enhance the markup with semantic knowledge, and microformats are just the answer! Simply marking up a <form> element with the CSS class "search" should be enough to tell the browser that this is a search form that should be promoted to the browser’s search box chrome.

Prior work on similar problems

HTML 3.2 (yes, 3.2) defines a link relationship type for search pages. Adding <a href="/search" rel="search"> indicates that the outgoing link is to a search page. Browsers currently don’t do much with this information (please correct me if you are aware of a browser that does something intelligent with this information). OpenSearch is (in their words) a simple format for the sharing of search results. Useful as it is, OpenSearch is more geared towards large-scale general search engines, and browser makers are adopting it as a standard for letting their users pick and install search plugins in browsers.

However, being able to customize the search field on a per-site basis with zero configuration on part of the user is not addressed by any of these proposals.

Addressing Potential Criticism

A few critics might argue that such usage dilutes the purpose of the search field (“It’s meant for searching via a search engine, not on a per-site basis”) or be concerned about possible user confusion (“Is my query being sent to a search engine or to the site I’m now visiting?”).

Considering an intentionality-driven approach to design, this UI is perfectly aligned with the user’s intentions. If a page has been rendered in a browser window, the user’s intention is likely to search within that site. If the user wanted to perform a search using a search engine, there is always the possibility of loading a new tab and then searching via the same field.

Issues of Mode

This also brings up the question of whether such a UI is inherently mode-based. (Modes in a User Interface are said to exist when a single input can result in two or more possible outcomes, depending upon the state of the UI at that point. It is generally considered bad design to employ modes in a UI because it invariably leads to user confusion.) In this case, it is arguable whether or not this UI employs modes.

The user task is “to search”, and the current site can be considered a specialized search engine (the specialization is that they only search within their own site). Given that a lot of sites employ site-limited versions of generalized search engines (e.g. Google’s Custom Search Engines), this notion is not very hard to think of. Hence, I argue that these are not two different modes, but two different search providers for the same box, just as current implementations offer users a choice among Google, Yahoo, Altavista and others.

It is also easy to indicate the destination of the search queries in a visually accessible format. Safari (for example) displays the word “Google” in the search field. When a site-search box is displayed in its place, it is trivial to display the name of the site instead of the word “Google”. It is also trivial to reuse the favicon for the same purpose.

Why not?

What do you think about this idea? Comments, suggestions, enhancements appreciated!

Google just announced a new feature in Google Maps: Click to Call. When you find a business on Google Maps, you can ask to be connected directly. Google then calls you on the number you provide, and places a call to the business at the other end.

This is yet another example of seamless task migration. The user’s ultimate goal in locating a business is to get in touch with them. The most common way to do this today is to call using a phone (at least as long as Voice-over-IP is not as ubiquitous as cellphones and land-lines). Lo, Google bridged the gap. End-to-end support for a user’s tasks using multiple devices is a challenge that’s getting its due attention only recently.

Hopefully, we will soon be able to do the same with phone numbers all over the Web. Imagine a button on my website that says, “click to call me”. Or, a button on my photo albums page that says, “view as a slideshow on the living room TV”. Or being able to press a button on your car radio to “read more about the currently-advertised product once I’m back home”.

Synergy, a mouse and keyboard sharing utility, has proven insanely useful to us users of multiple machines on a single desk. Think of it as a software KVM switch, but minus the “V” (for video.) You can arrange multiple machines side-by-side and Synergy seamlessly moves the mouse pointer and keyboard input from one machine to another at desktop boundaries. It’s a great idea and a great tool.

I use QuickSynergy on my PowerBook and Mac Mini, but later happened to look at the official GUI client on my friend’s Windows laptop. It’s not often that a user interface provokes a blog post on a Monday morning, but this was it.

Here are the screenshots:

You will notice that QuickSynergy has exactly one dialog box (with two tabs, one to use when running as a server, and another when running as a client) plus one About dialog. Synergy has a total of 9 dialog boxes (plus one About dialog.) The question, I wish, the developers had asked themselves, was whether throwing in a dialog box for every single configurable parameter was the right thing to do. It seems like the UI Designer(s) simply gave up on trying to understand the users’ needs, and instead just threw everything out to the user: “here, now there’s a dialog box for every single line in the configuration file, go figure it all out.” In my opinion, that’s the designer shirking his or her responsibility of actually designing.

I wonder how many regular users would ever want to change some of the arcane options. And if there was a savvy user that wanted to, she could just edit the config file! Even as a Computer Science Ph.D. student, I have no idea what the “Relative Mouse Moves” option means, or why I should care about it. (If you say RTFM, that’s already the sign of a bad interface.)

QuickSynergy On Mac OS X	Synergy On Windows

Notice how, in the configuration screen, QuickSynergy simply shows you one screen with four text fields on the four sides, whereas Synergy expects you to enter the positions as “Machine X is to Direction Y of Machine Z.” The first way is so much more natural, but guess why the Synergy implements the second way? Because the configuration file is written that way.

These are clearly two very different styles of GUI design (though I would strongly argue that a text field for editing a configuration file does not count as a “GUI”, it’s simply a command-line interface (CLI) inside a text field.) Quick Synergy puts the user first, and is designed to let the user work naturally with his/her mental model of a keyboard/mouse layout. Synergy starts from the configuration file and slaps on a UI on top of it. Thus, Quick Synergy comes closer to the user, while Synergy stays closer to the machine.

UI Design is not about letting users edit configuration files, it’s about letting them do what they started out to do. That a config file needs to be edited to make that happen is a side story.