Contents: Reasons for brevity Advantages of verbosity Some illustrative examples Ambiguity and the quantity of information Conclusion Resources About the author Rate this article Related content: Writing for a Web audience Usability according to Tog Subscriptions: dW newsletters dW Subscription (CDs and downloads)

Howard Tamler (htamler@acm.org)
Principal, HT Consulting
1 June 2001

The user interface is the primary channel of communication between software and users, and is basically textual in nature, so clear language is critical to usability. Unfortunately, this clarity is often sacrificed in an effort make messages unnecessarily brief. If you use language a bit more generously, often just by adding a well-chosen word or two, confusing or ambiguous messages can easily be made understandable.

Reasons for brevity
Most of the content in graphical user interfaces is conveyed through text, not graphics, so the effective use of language is basic to the way that user interfaces communicate with users. In particular, it seems to be a pervasive tradition in software design that text in user interfaces tends to be as brief as possible. One likely reason for this is that in previous decades, when applications could fit onto a diskette, the memory needed for displaying text had to be conserved, and low-resolution monitors with small screens had a serious shortage of screen real estate for displaying text or anything else. Another likely reason is the traditional promotion of brevity in the usability guidelines literature.

For example, Jakob Nielsen's first heuristic guideline, "Simple and natural dialog" (see Resources), states that "Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility." Of course, the key words here are "needed" and "relevant." Likewise, a cursory search of Deborah Mayhew's Principles and Guidelines in Software User Interface Design (see Resources) turns up at least four prescriptions for brevity: "Menu choice labels should be brief..." (p. 151); "Captions should be brief..." (p. 193); "Prompts should be brief..." (p. 204); "Provide brief prompts and instructions." (p. 225). However, the examples for each of these prescriptions differ only in the presence of extraneous, not essential, words.

In keeping with this, Microsoft's (1995) guidelines for menu item labels say to "...keep the wording brief and succinct," because verbose labels make it harder to scan; and similar statements appear in several places in these guidelines. In all fairness, this guidelines document is sensitive to the tradeoffs -- that is, it generally pairs these directives with prescriptions for avoiding truncation or for making the message clear, descriptive, and complete. To compensate, it also suggests using "tooltips," as well as small information boxes invoked by the "What's this?" command on right-click contextual pop-up menus.

Advantages of verbosity
On the other hand, there are equally good arguments that brevity guidelines have been overly influential, and that some corrective swing of the pendulum is needed in order to restore an optimal balance on this issue. For example, in their book The Media Equation (see Resources), Byron Reeves and Clifford Nass point out that most menu systems describe each option with only one or two words at most, regardless of the complexity of the function; consequently, users are frustrated by not getting the whole story. They argue that the "use of plain English (full sentences or at least multiple words in logical phrases) would make an enormous difference in understanding and satisfaction." Elsewhere, describing Microsoft Bob, the first commercial attempt to implement a social user interface (SUI), Nass argues that users appreciate complete sentences and prefer them to sentence fragments, because this is how people talk in real life. Consequently, all the Microsoft Bob characters speak in full sentences, which is more polite and sociable than the one-word utterances so common to UIs.

As another example, User Interface Engineering (see Resources) has reported evidence of the need for increased verbosity. Specifically, the authors compared the "tooltips" of Microsoft Access 2.0 with the analogous "hover bubbles" of Lotus Approach 3.0. The Microsoft tooltips are very brief -- for example, the icon that is redundant with the "Form" command on the "View" menu has a tooltip that says "Form View." In contrast, the hover bubble for one of the Lotus Approach icons says, "Go to browse to review or modify data." Clearly, in this example, the added verbosity seems to provide a level of description that goes significantly beyond what's offered by the Microsoft tooltip. Most importantly, the additional words seem to have helped -- users found Approach easier to use than Access in terms of finding functions quickly, and understanding the icons and menus.

Likewise, User Interface Engineering's 1997 comparative study of various Web sites found that longer links work better, and that better Web sites (e.g., the Edmunds automobile shopping site -- see Resources) have longer, more articulate links. As the authors put it, "The Edmunds site finished first in our study ... We believe this is due in part to its long, descriptive links" and "The Hewlett-Packard site finished third ... Part of its success may lie in how different its links are from each other." Their common-sense explanation is that something about the additional words seems to have helped users pick the links that led to the desired information. More specifically, the effectiveness of a link is a function of how easily the user can predict where the link will lead, and how easy it is to discriminate a given link from other associated links, both of these tasks being enhanced by the addition of information. In addition, articulate messages may be more important on the Web, where textual content is the main feature, as opposed to productivity software in which functionality is the main feature.

Some illustrative examples
In my own usability work, I have come across many instances of confusing UI text (menu items, command buttons, field labels, and especially error messages) whose meaning could have easily been made clear by adding a few words or otherwise spelling things out more completely. In addition, while in some cases ambiguities can be resolved by the context, this context may not be readily understood by a novice user. It is hard to come up with good examples because any given illustration seems rather trivial by itself. However, while none of the following cases are earth-shaking in and of themselves, the cumulative effect of many such instances could have a significant impact on the clarity and credibility of an entire system.

Field and command button labels
In a usability test of an optical spectrum measuring instrument, about half of the users (all of whom were instrument-using engineers) had some difficulty identifying words or numbers that were abbreviated unnecessarily, and therefore hard or impossible to identify; in general, they wanted all these words to be spelled out.

For example, many users had difficulty identifying "Sens" (the abbreviation for "Sensitivity"); rather, they expected to see the word "Sensitivity" spelled out, because the abbreviation was ambiguous -- one of the users routinely does "sensing" in his work. Another user at first concluded that "Sensitivity" was not on the "Amplitude" dialog at all, because of the label "dBm Sens," which he didn't recognize as equivalent to "Sensitivity."

In another part of this UI, the "Amp Setup" dialog had checkboxes labeled "Amp Meter" and "Amp Corr," where "Amp" was the abbreviation for "amplitude." Two users pointed out that this abbreviation could easily be confused with the terms "amperes" and "amplifier" (which are also routinely abbreviated "Amp"), and suggested completely spelling out the "Amplitude Control" feature labels. Likewise, another user was annoyed that "Wavelength" was abbreviated as "Wavelgth" in a drop-down list. Consequently, I recommended that all words be spelled out completely where possible, except in cases where space is not available, or where abbreviations are expected as part of the established technical jargon of users.

Also in this test, several users misunderstood the "Other Traces OFF" command button in the "Traces" dialog. They didn't know if it meant that the traces were already off, or that this button would turn them off; several thought that it meant that traces were off, and that if they clicked it, it would toggle to "Other traces ON." I recommended that this ambiguity be removed by relabeling it "Turn off other traces," which requires adding only one key word.

In his book GUI Bloopers (see Resources), Jeff Johnson provides an example of an application development tool for C++ programmers, with a command labeled "Build window." This command invokes the window used for "building" (compiling and linking) an application. However, in the context of an application development tool, this phrase is ambiguous and easily interpreted as a verb phrase, "build a window." In fact, because commands tend to start with verbs, this latter interpretation probably makes more sense than the correct interpretation; consistent with this, users repeatedly interpreted it wrongly. This ambiguity and the resulting error could be eliminated by expanding the command label to something like "Window for building."

A similar example of ambiguity is cited by Johnson regarding a wizard that could be used for creating various kinds of objects. This wizard was invoked by the "Create Object Wizard" command, in which the phrase "Create Object" refers to the name of the wizard. However, assuming the typical command syntax, users tended to interpret "Create" as a verb, and "Object Wizard" as the object of that verb; consequently, they wondered what this "Object Wizard" was and why they'd ever need to create it. This error could be eliminated by changing the command to something like "Object Creation Wizard."

Status messages
A multimedia home theater system that I recently evaluated has a control for muting the sound. When this control is activated, a screen continuously displays the word "Mute" to show the user that the sound is muted (rather than the volume being too low, etc.). In addition, the presence or absence of this visual feedback can be configured in a setup dialog box, which gives users two options:

1. Getting this feedback on the state of the mute control
2. Not getting this feedback on the state of the mute control

This option is set via a checkbox with the label "Mute feedback." However, in the context of this setup dialog in this product, "Mute" could easily be misinterpreted as a verb, with the phrase meaning "suppress all feedback." In order to remove this ambiguity, I recommended expanding the checkbox label to "Display status of mute control."

In another dialog in this same product, the message "OK to delete" is displayed when a selection is made, meaning that deletion can be executed by pressing the OK button on the remote control. Given the context, this could be misinterpreted as "It's OK to delete the thing that you selected." Consequently, I recommended changing the message to "Press OK to delete," an addition of only one word.

Error messages
In a usability test of a customer profile application, one task required users to search for customers within a specified geographical area. When users were looking for all customers in Paris, France, some were repeatedly confused by the error message "Search criterion missing." On the face of it, this message was wrong, because "Paris" was a perfectly valid search criterion. What these users didn't know yet was that the system would not search on a city alone, but required that users also enter a customer name or alias as well as a city. Hence, what the message really meant was that at least one, but not all, of the required search criteria were missing. I recommended that the message articulate the problem with something specific, such as, "You must enter a customer name or alias in addition to a city."

Another example I encountered was an error message for a query that said, "The data for the view could not be loaded. Type mismatch." This latter phrase "type mismatch" is notoriously ambiguous -- according to the "Interface Hall of Shame" (see Resources), a secretary who got this message phoned the CompuServe Customer Support hotline to complain that she had typed the word "mismatch" several times, but it didn't solve the problem! Again, turning this phrase into a brief descriptive sentence could easily remove the ambiguity, while making the message more useful as well.

Dialog instructions
I evaluated a financial application where the following text appeared in a dialog related to income taxes:

This tax tracking type is usually associated with deductions. Report elective deferrals up to the annual limit of $10,000. [Product] reduces amounts on Form W-2, Box 1 and Form 941, Line 2. Checks "Pension Plan" and "deferred Comp" checkboxes on Form W-2, Box 15. [Product] reports on Form W-2, Box 13, Code D.

While this explanation was potentially helpful, the sentences are somewhat clipped and compressed, and as a result, unclear in the following ways:

• Who is supposed to "report elective deferrals," [Product] or the user? Who "checks 'Pension Plan' and 'deferred comp' checkboxes," [Product] or the user? The lack of a subject in these sentences makes them ambiguous as to whether they are imperative or descriptive, and as to who or what is doing the reporting and checking.
• The last sentence is ambiguous, in that it could mean that [Product] enters some value on Form W-2, Box 13, Code D, or that the [Product] reports include the value which can be found on Form W-2, Box 13, Code D.

All this would be clearer if it were spelled out in fully grammatical, complete sentences. Based on a few guesses about what is actually meant, it could be rewritten as follows:

This tax tracking type is usually associated with deductions from employee paychecks. To implement this deduction, you should enter elective deferrals up to the annual limit of $10,000. Based on your entries, [Product] will do the following:
1. Reduce the amounts on Form W-2, Box 1, and on Form 941, Line 2, by the amount of the deduction.
2. Check the "Pension Plan" and the "deferred Comp" checkboxes on Form W-2, Box 15.
3. Enter Code D on Form W-2, Box 13.

Ambiguity and the quantity of information
So, what makes longer UI labels and links easier to understand? Foremost in any explanation is the psycholinguistic fact that many -- probably most -- utterances are ambiguous; but we routinely interpret them only one way because the context, especially the unique combination of the words in the utterance, makes a particular interpretation more plausible. More importantly for UI design, which traffics in short phrases and single words, Sam Glucksberg and Joseph Danks (see Resources) argue that single words like "pen" are typical in having a multiplicity of meanings, because linguists agree that word ambiguity is the rule rather than the exception. While some linguists think that at least 50% of the English lexicon is ambiguous, others think that practically every word is ambiguous in principle, especially if we include metaphorical usage.

The other part of this equation is that ambiguity is inversely proportional to the length of the utterance, all things being equal -- that is, each additional word in an utterance, analogous to a criterion in a Boolean search, further constrains the space of possible meanings. Hence, a word is easier to interpret in a sentence or phrase than in isolation; and longer phrases tend to have a more specific meaning than shorter ones. For example, the famously misinterpreted phrase "Press any key" would be clearer if it said "Press any one of the letter keys." Likewise, the label "display mode" can mean "the current mode of display" or "display the current mode"; but all it takes is one additional word to disambiguate: either "display the mode" or "mode of display." As another example, the word "take" has so many meanings, both verb and noun, that it occupies 3/4 of a page in Webster's dictionary; "take my wife -- please" plays on this ambiguity, but "please take out the garbage" is unambiguous.

Coming at this from a similar angle, Bruce Tognazzini's book Tog on Interface (see Resources) makes an analogous claim about the clarity of meaning as a positive function of the amount of textual information. Not only do the rules of English grammar (including word probability, spelling, etc.) describe a language in which over 75% of the information is redundant, but this is more or less true for every language that's been studied. Why should this be the case? Because human communication always has a rich potential for error or misinterpretation arising from a variety of sources -- the message content, the transmission medium, the signal/noise ratio, the context, the receiver's assumptions, etc. Hence, it's only thanks to the significant redundancy of language that receivers are able to get the message right. (A familiar application illustrating this principle is the standard postal address, where the ZIP code is entirely redundant, but nevertheless useful.) The upshot is that some level of redundancy is good for user interfaces in particular, as well as for human communication in general, and additional information in a UI should not be ruled out merely because it might be redundant.

In this regard, acronyms are a case in point. They are clearly useful and even critical for certain professional in-groups (the military, astronauts, medical doctors, etc.), and should definitely be used for software targeted at those groups, where knowledge of their meaning can be taken for granted. However, because acronyms are so potentially ambiguous, I am adamantly opposed to their use in commercial software aimed at the general public. Unless there is some overriding reason to abbreviate, it costs little or nothing to spell out the words; and lack of sufficient space on the screen is a poor excuse, given what GUI technology can do with the press of a mouse button.

Conclusion
I'm not advocating any universal principle that verbose is better; rather, the optimal message length varies with the particular situation, and is typically somewhere in the middle rather than at either extreme. I am merely pointing out that, contrary to many UIs and the pitch of some UI design guidelines, the shortest message isn't necessarily the most usable; and that in many cases usability can be easily enhanced by lengthier, more explanatory textual messages. Moreover, while brief messages are appropriate for experienced users of a system, relatively detailed messages with more redundancy may be necessary for novice or infrequent users. And with dynamic GUI devices such as tooltips, balloons, and pop-up panels, it need not cost us anything in terms of valuable screen real estate to provide more clear, complete, and articulate messages.

Resources

• Experimental Psycholinguistics by Sam Glucksberg and Joseph Danks is an undergraduate textbook with some good linguistic material on ambiguity.
  
  
• Jeff Johnson's GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers is by far the best source for more information on this topic, with a whole chapter devoted to language in user interfaces. Also enjoyable and highly readable.
  
  
• Principles and Guidelines in Software User Interface Design by Deborah Mayhew, is a good source of psychological research to back up user interface design principles, but is somewhat outdated in its examples.
  
  
• Microsoft's The Windows Interface Guidelines for Software Design: An Application Design Guide was written for Windows 95, but is still applicable to later versions.
  
  
• Jakob Nielsen's Usability Engineering is the best overall introduction to software usability, and includes material on user interface language.
  
  
• The Media Equation: How People Treat Computers, Television, and New Media Like Real People and Places , by Byron Reeves and Clifford Nass, describes the social nature of computer use and its implications for how software should communicate with users.
  
  
• Bruce Tognazzini's book, Tog on Interface , has very little material on the subject, but is very enjoyable reading -- a user interface classic.
  
  
• User Interface Engineering, "Effective Tool Tips" Eye for Design, 3 (1), 1996: 1-7. This issue is probably not available anymore, but the newsletter is very good and readable.
  
  
• User Interface Engineering's 1997 study "Web Site Usability: A Designer's Guide," is a very readable guide, with some material on the language of links. This study praised sites with longer, more articulate links, such as the Edmunds automobile shopping site.
  
  
• Poor interface design is all around us, some of it so bad it deserves recognition at The Interface Hall of Shame.
  
  
• IBM's Ease of Use site offers new innovations, user-centered design, guidelines, stories, technologies, and other resources to help improve the total user experience for your products and services.
  
  
• Find out how IBM's Global Services Usability Engineering team can help you improve your products and make them easier to use.
  
  

What do you think of this document? Killer! (5) Good stuff (4) So-so; not bad (3) Needs work (2) Lame! (1) Comments?

developerWorks > Web architecture