Jakob Nielsen's Alertbox, September 30, 2001:

Deferred Hypertext: The Virtues of Delayed Gratification

Summary:
Navigating a full browsing session to find information can be unpleasant and slow, particularly on mobile devices. Instead, issue a deferred request and have the information arrive later, as done by some SMS systems.

Although users typically click a link and expect an immediate response, this scenario is not always convenient. Several systems now use hypertext links that do not generate an immediate page view, but instead defer the results.

Users might prefer deferred hypertext when they have:

Bad user interfaces that prevent efficient user interactions. With deferred hypertext, users submit simple requests for a single, well-defined unit of information rather than interacting with complicated screens and forms.
Bad displays that make in-depth reading unpleasant. By deferring hypertext in this scenario, users can read the full text at a later time on a better display.

Currently, most deferred hypertext systems work through e-mail to compensate for the bad browsing interfaces on existing mobile devices. However, I also expect an increase in services to support bad displays and lack of reading time.

For example, readers browsing on mobile devices might find it especially valuable to mark certain articles or websites and have them show up later on full-screen displays at the office or at home. Another application might let users issue a deferred request for an article and have it automatically print out on the office computer so that it's waiting for them when they arrive. These are just a few ideas that indicate the need for tighter integration between low-end, mobile computing and stationary computing devices.

The SMS Solution

Deferred hypertext is currently very popular among mobile phone users in Europe. Given that it is so painful to navigate through WAP screens to find information interactively, most users prefer instead to send an SMS message and have the answer returned in a subsequent message. (SMS is short emails sent to and from cell phones.)

Say, for example, that you are in Zurich and need departure times for trains to Geneva. Using SMS, you can send a train information service a message consisting of the word "Geneva." The service then sends you a reply listing the next several trains departing for that city. The system assumes several things to reduce your typing burden: that you want only a few departure times, that you want them for the next few trains, and that you want only trains departing from Zurich (although I've only used this service in Zurich, I assume other big cities provide it as well).

Blackberry offers similar services, many of which let users interact with complex corporate databases and sales automation systems.

Usability Issues

SMS information retrieval has no user interface in the modern sense, since all the user can do is type out a command and send it off. Of course, a command language is a user interface in its own right; SMS interactions are very similar to batch processing computers that used punch card commands in the 1950s.

There are four basic usability guidelines for dealing with SMS and other email-style commands.

Offer great flexibility in command recognition. There is nothing more annoying than getting a "command not recognized" response in a batch processing system, where turn taking between human and computer is very slow. To achieve this flexibility:
- recognize both noun-verb syntax and verb-noun syntax for all commands,
- allow for as many synonyms as possible, and
- correct typos using a spelling checker.
Support abbreviations, but also support full commands. One of the stupidities of Unix was that you had to type ls; you couldn't type list (which is easier to remember).
Guess where appropriate. If there is no downside to misinterpreting the user's command, err on the side of wild guessing for correcting typos or interpreting abbreviations. For example, if the user asks for the "Chigaco" weather forecast, just send off the Chicago weather. On the other hand, if the user asks to buy 10,000 shares of a stock symbol that's not in the database, simply buying the closest match is not a good idea.
Return multiple responses when necessary. If multiple interpretations are possible, it is sometimes better to return responses corresponding to all possibilities rather than asking the user for clarification. If such a response would be too big for easy transmission or reading, send both the best guess and a menu of secondary guesses that the user can choose from.

Supporting all the possible ways a user might type a command on a crummy phone keypad sounds like a tall order, but it is eminently possible to support at least 98% of the variations. You can predict many of the alternatives by simply thinking about the problem; you can discover many more in a basic user test. For example, simply ask 10 people to write down how they would query the service in question. Finally, continually review your log files for real-world user inputs. In my experience, you quickly achieve an asymptote of high-recognition performance as you add the ability to handle empirically observed variations.

Deferred or Half Dead?

In my 1995 book on the theory behind the Web, I used the term "half-dead hypertext" to differentiate deferred links from both live links and completely dead links (inactive references). A half-dead link indicated that manual user labor was required. For example, if I wrote the title of my book above, but provided no link, the user would have to go to a bookstore site or the local library to find it. Although offering the title is better than offering no reference at all, the half-dead link offers no possibility for live and immediate computer interaction, and thus I called it "half-dead."

The live vs. dead metaphor does have some value, even if the terminology never caught on. However, I now prefer the term "deferred hypertext" over "half-dead hypertext." The new term does raise an important question, however: Deferred for how long?

Even though deferred hypertext is not a live interaction, the length of delay in delivery impacts the service's usefulness. Given too long a delay, users might forget the request altogether, requiring that the response either reestablish context or render itself meaningless. At that point, the information is likely to be more dead than deferred.

Complete list of other Alertbox columns