Section 7.3. THE PATTERNS

Figure 7-4. For date input, LiveJournal uses Structured Format in combination with a dropdown to choose a month. It defaults to the current day and time. See http://livejournal.com.

70. fill-in-the-blanks

Figure 7-5. From http://amazon.com

7.3.3.1. what

Arrange one or more fields in the form of a prose sentence or phrase, with the fields as "blanks" to be filled in by the user.

7.3.3.2. use when

You need to ask the user for input, usually one-line text, a number, or a choice from a dropdown list. You tried to write it out as a set of label/control pairs, but the labels' typical declarative style (such as " Name :" and "Address:") isn't clear enough for users to understand what's going on. You can, however, verbally describe the action to be taken once everything's filled out, in an active-voice sentence or phrase.

7.3.3.3. why

Fill-in-the-Blanks helps make the interface self-explanatory. After all, we all know how to finish a sentence. (A verb phrase or noun phrase will do the trick, too.) Seeing the input, or "blanks," in the context of a verbal description helps the user understand what's going on and what's asked of him.

7.3.3.4. how

Write the sentence or phrase using all your word- crafting skills. Use controls in place of words.

If you're going to embed the controls in the middle of the phrase, instead of at the end, this pattern works best with text fields, dropdown lists, and combo boxesin other words, controls with the same form factor (width and height) as words in the sentence. Also, make sure the baseline of the sentence text lines up with the text baselines in the controls, or it'll look sloppy . Size the controls so that they are just long enough to contain the user's choices, and maintain proper word spacing between them and the surrounding words.

This is particularly useful for defining conditions, as one might do when searching for items or filtering them out of a display. The Excel and Photoshop examples below illustrate the point. Robert Reimann and Alan Cooper describe this pattern as an ideal way to handle queries; their term for it is "natural language output." ^[1]

^[1] See their book About Face 2.0: The Essentials of Interaction Design (Wiley), Section 6.2.14.5.

There's a big "gotcha" in this pattern, however: it becomes very hard to properly localize the interface (convert it to a different language), since comprehension now depends upon word order in a natural language. For some international products or web sites, that's a non-starter. You may have to rearrange the UI to make it work in a different language; at the very least, work with a competent translator to make sure the UI can be localized.

7.3.3.5. examples

Figure 7-6. The Mac OS X System Preferences has several places that use a simple Fill-in-the-Blanks approach. Here's one.

Figure 7-7. This Excel cell -formatting dialog box lets you choose the phrases in this "sentence" from dropdown boxes. As the phrases change, the subsequent text fieldsshowing 0 and 10 in this examplemight be replaced by other controls, such as a single text field for "greater than."

Figure 7-8. Photoshop's image search dialog box uses a very similar approach to the Excel dialog, but this one uses multiple conditions.

71. input hints

Figure 7-9. Mac OS X System Preferences

7.3.4.1. what

Beside an empty text field, place a sentence or example that explains what is required.

7.3.4.2. use when

The interface presents a text field, but the kind of input it requires isn't obvious to all users. You don't want to put more than a few words into the text field's label.

7.3.4.3. why

A text field that explains what goes into it frees users from having to guess. If you visually separate the hint from the main label, users who know what to do can more or less ignore the hint, and stay focused on the label and control.

7.3.4.4. how

Write a short example or explanatory sentence, and put it below or beside the text field. Two examples conjoined by "or" works fine too. Keep the text small and inconspicuous, though readable; consider using a font two points smaller than the label font. (A one-point difference will look more like a mistake than an intended font-size change.)

Also, keep the hint short. Beyond a sentence of two, many users' eyes will glaze over, and they'll ignore the text altogether.

This pattern is often used in conjunction with Forgiving Format , as illustrated by the Word example below, or Structured Format . Alternative patterns are Input Prompt (in which a short hint goes into the control itself), and Good Defaults (which puts an actual valid value into the control). Input Hints permit longer, more permanent help texts than Input Prompts , but because no default value is present in the text field, the user is forced to consider the question and give an answer.

7.3.4.5. example

Figure 7-10. The printing dialog boxes used by several Microsoft Office applications supply an Input Hint below a Forgiving Format text fieldit takes page numbers, page ranges, or both. The hint is very useful to anyone who's never had to use the "Pages" option, but users who already understand it don't need to focus on the written text; they can just go straight for the input field.

72. input prompt

Figure 7-11. From http://orbitz.com

7.3.5.1. what

Prefill a text field or dropdown with a prompt that tells the user what to do or type.

7.3.5.2. use when

The UI presents a text field, dropdown, or combo box for required input. Normally you would use a good default value, but you can't in this caseperhaps there is no reasonable default, as in the Orbitz form above. The user needs only a short reminder of what is required.

7.3.5.3. why

It helps make the UI self-explanatory. Like Input Hints, an Input Prompt is a sneaky way of supplying help information for controls whose purpose or format may not be immediately clear.

With an Input Hint , someone quickly scanning the UI can easily ignore the hint (or miss it entirely). Sometimes this is your desired outcome. But an Input Prompt sits right where the user will type, so it can't be ignored. The advantage here is that the user doesn't have to guess whether she has to deal with this control or notthe control itself tells her she does. (Remember that users don't fill out forms for funthey'll do as little as needed to finish up and get out of there.) A question or an imperative "Fill me in!" is likely to be noticed.

An interesting side effect of this pattern is that users may not even bother to read the label that prefixes the text field. Look again at Figure 7-11. The labels "from" and "to" are completely superfluous, in terms of the form's meaning. Because the user's eye will be drawn first to the white text fields, those prompts probably will be read before the labels anyway! That said, don't remove the labelsthat prompt is gone forever once the user types over it, and on subsequent readings of this form, she may not remember what the control asks for.

7.3.5.4. how

Choose an appropriate prompt string, perhaps beginning with one of these words:

• For a dropdown list, use Select, Choose , or Pick .

• For a text field, use Type or Enter .

End it with a noun describing what the input is, such as "Choose a state," "Type your message here," or "Enter the patient's name." Put this phrase into the control where the value would normally be. (The prompt itself shouldn't be a selectable value in a dropdown; if the user selects it, it's not clear what the software should do with it.)

Since the point of the exercise was to tell the users what they were required to do before proceeding, don't let the operation proceed until they've done it! As long as the prompt is still sitting untouched in the control, disable the button (or other device) that lets the user finish this part of the operation. That way, you won't have to throw an error message at the user.

7.3.5.5. example

Figure 7-12. Input Prompt has historically been unusual in desktop applications, but it's as good an idea in this context as it is on the Web. Note its use on a WYSIWYG editor's canvas hereit doesn't indicate a "required field" as such, but the application clearly communicates its intent to the user, who doesn't have to puzzle out what he should do next.

73. autocompletion

Figure 7-13. Firefox's autocompletion for typed URLs

7.3.6.1. what

As the user types into a text field, anticipate the possible answers and automatically complete the entry when appropriate.

7.3.6.2. use when

The user types something predictable, such as a URL, the user's own name or address, today's date, or a filename. You can make a reasonable guess as to what they're attempting to typeperhaps there's a saved history of things this user has previously typed, for instance, or perhaps the user is picking from a set of preexisting values, like a list of filenames in a directory.

When the typed entries are long and hard to type (or remember), like URLs or email addresses, Autocompletion is particularly valuable .

Autocompletion is also common in text editors and command-line UIs. As users type commands or phrases, the application or shell might offer suggestions for completion. Code editors and OS shells are well-suited for this, because the language used is small and predictable (as opposed to a human language, like English); it's therefore easier to predict what the user tries to type.

7.3.6.3. why

Save the user the trouble of typing the whole string, and do it for him. You thus save countless seconds of work, and contribute to the good health of thousands of wrists. An additional benefit can be error prevention: the longer or stranger the string that must be typed, the greater the odds of the user making a typographical error. Autocompleted entries can avoid that problem.

7.3.6.4. how

With each additional character that the user types, the software quietly forms a list of the possible completions to that partially entered string. If the user enters one of a limited number of possible valid values, use that set of valid values. If the possible values are wide open, then one of these might supply completions:

• Previous entries typed by this user, stored in a preferences or history mechanism

• Common phrases that many users have used in the past, supplied as a built-in "dictionary" for the application

• Artifacts appropriate to the context, such as company-wide contact lists for internal email

From here, you can approach the interaction design of Autocompletion in two ways. One is to show the user a list of possible completions on demand, such as by hitting the Tab key, and let him choose one explicitly by picking from that list. Many code editors do this (see Figure 7-17). It's probably better used when the user would recognize what he wants when he sees it, but may not remember how to type it without help. "Knowledge in the world is better than knowledge in the head."

The other way is to wait until there's only one reasonable completion, and then put it in front of the user, unprompted. Word does this with a tooltip; many forms do it by filling in the remainder of the entry, but with selection turned on, so another keystroke would wipe out the autocompleted part. Either way, the user gets a choice about whether to retain the autocompletion or notand the default is to not keep it.

You can use both approaches together, as in Figure 7-17.

Make sure that Autocompletion doesn't irritate users. If you guess wrong, the user won't like ithe then has to go erase the autocompletion, and retype what he meant in the first place, avoiding having autocomplete pick the wrong completion yet again. These interaction details can help prevent irritation:

• Always give the user a choice to take the completion or not take it; default to "no."

• Don't interfere with ordinary typing. If the user intends to type a certain string and just keeps typing in spite of the attempts at autocompletion, make sure that the result is what the user intended to type.

• If the user keeps rejecting a certain autocompletion in one place, don't keep offering it. Let it go at some point.

• Guess correctly.

Here's one possible way to implement Autocompletion cheaply. You can turn a text field into a combo box (which is a combination of a typable text field and a dropdown). Each time the user enters a unique value into the text field, make a new drop-down item for it. Now, if your GUI toolkit allows type-ahead in combo boxes (as many do), the drop-down items are automatically used to complete whatever the user types. See Figure 7-13 above for a typical example; most web browsers now keep the most recently visited sites in a combo box where the user types URLs.

7.3.6.5. examples

Figure 7-14. Many email clients , of course, use autocompletion to help users fill in To: and CC: fields. They generally draw on an address book, contacts list, or a list of addresses you've exchanged email with. This example from Mac Mail shows a single completion suggested upon typing the letter 'c'; the completed text is automatically highlighted, so a single keystroke can get rid of it. You can thus type straight "through" the completion if it's wrong.

Figure 7-15. Word has a built-in dictionary of words and phrases that it uses to suggest completions. In this picture, typing the word "Your" at the beginning of a line has caused Word to suggest "Yours truly," which is appropriate only for signatures of letters . Had Word been smarter , it might have noticed that the text in question was in the middle of a 10,000-word book chapter that bore no resemblance whatsoever to a letter. But again, you can type straight through the autocompletion, ignoring it.

Figure 7-16. In contrast to Mail and Word, Google Suggest makes autocompletion its defining feature. As you type, it shows you the most popular searches that match what you've typed thus far. Rather than being a mere typing aid, it actually turns into a way to navigate a small corner of the public mental landscape.

Figure 7-17. Finally, code editors such as Visual Studio invest in very complex autocompletion mechanisms. Visual Studio's IntelliSense" completes the built-in keywords of a programming language, of course, but it also draws on the functions, classes, and variable names defined by the user. It even can show the arguments to functions that you invoke (in the righthand screenshot). Furthermore, both "select from a list" and "take the one completion that matches" approaches are supported, and you can call up autocompletion on demand by typing Control-Space.
Autocompletion in Visual Studio thus serves as a typing aid, a memory aid, and a browser of context-appropriate functions and classes. It's very useful.

74. dropdown chooser

Figure 7-18. Word's color chooser

7.3.7.1. what

Extend the concept of a menu by using a dropdown or pop-up panel to contain a more complex value-selection UI.

7.3.7.2. use when

The user needs to supply input that is a choice from a set (such as in the color example above), a date or time, a number, or anything other than free text typed at a keyboard. You want to provide a UI that supports that choicea nice visual rendering of the choices, for instance, or interactive toolsbut you don't want to use space on the main page for that; a tiny space showing the current value is all you want.

7.3.7.3. why

Most users are very familiar with the dropdown list control (called a "combo box" when used with a free-typing text field). Many applications successfully extend this concept to dropdowns that aren't simple lists, such as trees, 2D grids, and arbitrary layouts. Users seem to understand them with no problem, as long as the controls have down-arrow buttons to indicate that they open when clicked.

Dropdown choosers encapsulate complex UIs in a small space, so they are a fine solution for many situations. Toolbars , forms, dialog boxes, and web pages of all sorts use them now. The page the user sees remains simple and elegant, and the chooser UI only shows itself when the user requests itan appropriate way to hide complexity until it is needed.

(In general, I wouldn't recommend using it on UIs that are used primarily by computer novices. But Microsoft Office has trained its legions of users in Dropdown Chooserscolor selectors and font selectors, for example, all take advantage of themso just make sure your audience is comfortable with them.)

7.3.7.4. how

For the Dropdown Chooser control's "closed" state, show the current value of the control in either a button or a text field. To its right, put a down arrow. This may be in its own button, or not, as you see fit; experiment and see what looks good and makes sense to your users. A click on the arrow (or the whole control) brings up the chooser panel, and a second click closes it again.

Tailor the chooser panel for the choice the user needs to make. Make it relatively small and compact; its visual organization should be a familiar information-graphics format, such as a list, a table, an outline-type tree, or a specialized format like a calendar or calculator (see the following examples).

Scrolling the panel is OK if the user understands that it's a choice from a large set, such as a file from a filesystem, but keep in mind that scrolling one of these pop-up panels is not easy for people without perfect dexterity!

Links or buttons on the panel can in turn bring up secondary UIsfor example, color-chooser dialog boxes, file-finder dialog boxes, or help pagesthat help the user choose a value. These usually are modal dialog boxes. In fact, if you intend to use one of these modal dialogs as the primary way the user picks a value (say, by launching it from a button), you could use a Dropdown Chooser instead of going straight to the modal dialog. The pop-up panel could contain the most common or recently chosen items. By making frequently chosen items so easy to pick, you reduce the total time (or number of clicks) it takes for an average user to pick values.

7.3.7.5. examples

Figure 7-19. One of the first non-list uses of a dropdown chooser was the directory selector in Windows Explorer. It is indented to look like a tree view. You cannot open or close its nodes, so it really behaves more like a dropdown list with indented items than an actual tree, but it was visually different from a dropdown list.

Figure 7-20. Photoshop's compact, interaction-rich toolbars use dropdown choosers heavily. The Brush control is shown here; Opacity is shown in the next example. The Brush chooser is a selectable list with a twistit has extra controls such as a slider, a text field, and a pullright button (the circular one) for yet more choices.

Figure 7-21. The Opacity chooser is a simple slider, and the text field above it echoes its value. (Note the mysterious use of a right arrow instead of a down arrow.)

Figure 7-22. A text field from Money. Normally a user would just type a number into this text field. But in the context of a financial application, having a calculator attached to a text field is very useful. A user might type in a number and then multiply it by 12, for instance.

Figure 7-23. Even web sites can get into the swing of things. Orbitz's calendar dropdown is slightly buggy (it appears far away from the dropdown button itself), but it's an effective presentation for a date chooser.

75. illustrated choices

Figure 7-24. Mac OS X System Properties

7.3.8.1. what

Use pictures instead of words (or in addition to them) to show available choices.

7.3.8.2. use when

The interface presents a set of choices that differ visually, such as images, colors, font families, or object alignment.

7.3.8.3. why

Why translate a visual concept into words, when showing it visually is so much more direct? You reduce the cognitive load on the userthey don't have to think about what "goldenrod" or "Garamond" might look likewhile simultaneously making the interface more attractive.

7.3.8.4. how

First, each thumbnail (or color swatch) should be accurate. The user should get what he sees on the illustrated choice. Beyond that, show the differences that matter, and little else; there's no need for perfect miniature reproductions of the choices' effects. Show a simplified, streamlined, and exaggerated picture.

You can use illustrated choices in many controls: dropdown lists, radio boxes, scrolled lists, tables, trees, and specialized dialog boxes like color choosers. Ideally, you can show the user a set of illustrated choices all at once, in one single dropdown, list, or toolbar. A user then can compare them to one another immediately and easily. If you show them one at a timewhich sometimes must be the case, as with the Preview pattern (see Chapter 5)the user sees them sequentially over time, which isn't as good for comparing one to another.

Sometimes it's appropriate to show both the picture and the item's name. If the user would benefit from seeing both of them, do itthey'll learn to associate the name with the picture, and thus the concept. Interfaces can teach.

If you need custom icons or thumbnail pictures, consider getting a good graphic designer to do the artistic work. Make sure she is sensitive to the visual vocabulary of the whole application, and that she understands what the choices mean.

7.3.8.5. examples

Figure 7-25. When you create a chart in Excel, you see a Chart Wizard that first asks you to choose a chart type. This is a perfect use of Illustrated Choices: not everyone knows what a bubble chart or a radar chart should look like, but some people recognize the pictures of them. (Also note the use of a help text at the lower right, and the fact that the three-page elements together behave like a Cascaded List .)

Figure 7-26. A font chooser is a classic place to use Illustrated Choices. In this dropdown box from Word, the font names are written in their own fonts, thus sparing the user the need to look it up in a separate font dialog box or toolfew Word users would know the difference between Book Antiqua and Palatino without seeing examples of them.

76. list builder

Figure 7-27. A dialog box from MS Outlook

7.3.9.1. what

Show both the "source" and the "destination" lists on the same page; let the user move items between them.

7.3.9.2. use when

You ask the user to create a list of items by choosing them from another list. The source list may be longtoo long to easily show as a set of checkboxes, for instance.

7.3.9.3. why

The key to this pattern is showing both lists on the same page. The user can see what's whatshe doesn't have to jump to and from a modal dialog box, for instance (see the "Examples" section for an example of that).

A simpler alternative to List Builder might be a single list of checkbox items. Both solve the "select a subset" problem. But if you have a very large source list (such as an entire filesystem), a list of checkboxes doesn't scalethe user can't easily see what's been checked off, and thus may not get a clear picture of what she selected. She has to keep scrolling up and down to see it all.

7.3.9.4. how

Put the source list on the left and the destination list on the right. The items thus will move from left to right, which is a more natural flow than right to left. Between the two lists, put Add and Remove buttons; you could label them with words, arrows, or both.

This pattern provides room for other buttons, too. If the destination list is ordered, use Move Up and Move Down buttons, as shown in the example above. (They could have arrow icons, too, instead of or in addition to the words.)

Depending on what kind of items you deal with, you could either move the items literally from the source to the destinationso the source list "loses" the itemor maintain a source list that doesn't change. A listing of files in a filesystem shouldn't change; users would find it bizarre if it did, since they see such a list as a model of the underlying filesystem, and the files aren't actually deleted. But the list of "Available fields" in the Outlook example above does lose the items. That's a judgment call.

Implement drag-and-drop between the lists, if possible, and give the lists multiple-selection semantics instead of single-selection, so users can move large numbers of items from list to list.

7.3.9.5. examples

Figure 7-28. IntelliJ IDEA is a complex Java development environment. It has an unfortunate dialog box, for which a List Builder might have been better suited. This example shows a fragment of that dialog box. The user's task is to select some number of .jar files from the filesystem; it may be a few, it may be many. Each time the user wants to add files to the "Module Libraries" list on the left, she has to launch a modal dialog box, shown on the right, where she can select the jar files in question. This can lead to many launches of that dialog box. (The dialog box permits multiple selection, fortunately, but if the user builds up that list slowly, it still will be launched too many times.)

77. good defaults

Figure 7-29. Visual Studio profile screen

7.3.10.1. what

Wherever appropriate, prefill form fields with your best guesses at the values the user wants.

7.3.10.2. use when

Your UI asks the user any questions requiring form-like input (such as text fields or radio buttons), and you want to reduce the amount of work that users have to do. Perhaps most users will answer in a certain way, or the user has already provided enough contextual information for the UI to make an accurate guess. For technical or semi-relevant questions, maybe he can't be expected to know or care about the answer, and "whatever the system decides" is okay.

But supplying defaults is not always wise when answers might be sensitive or politically charged, such as passwords, gender, or citizenship. Making assumptions like that, or pre-filling fields with data you should be careful with, can make users uncomfortable or angry . (And for the love of all that is good in the world, don't leave "Please send me advertising email" checkboxes checked by default!)

7.3.10.3. why

By providing reasonable default answers to questions, you save the users work. It's really that simple. You spare the user the effort of thinking about, or typing, the answer. Filling in forms is never fun, but if this pattern halves the time it takes him to work through it, he'll be grateful.

Even if the default isn't what the user wants, at least you offered an example of what kind of answer is asked for. That alone can save him a few seconds of thoughtor, worse , an error message.

Sometimes you may run into an unintended consequence of Good Defaults. If a user can skip over a field, that question may not "register" mentally with him. He may forget that it was asked; he may not understand the implications of the question, or of the default value. The act of typing an answer, selecting a value, or clicking a button forces the user to address the issue consciously, and that can be important if you want the user to learn the application effectively.

7.3.10.4. how

Prefill the text fields, combo boxes, and other controls with a reasonable default value. You could do this when you show the page to the user for the first time, or you could use the information the user supplies early in the application to dynamically set later default values. (For instance, if someone supplies a United States ZIP Code, you can infer the state, country, and sometimes the city or town from just that number.)

Don't choose a default value just because you think you shouldn't leave any blank controls. Do so only when you're reasonably sure that most users, most of the time, won't change itotherwise, you will create extra work for everybody. Know your users!

Occasional-use interfaces like software installers deserve a special note. You should ask users for some technical information, like the location of the install, in case they want to customize it. But 90 percent of users probably won't. And they won't care where you install it, eitherit's just not important to them. So it's perfectly reasonable to supply a default location.

Jeff Johnson discusses this issue at length in Web Bloopers: 60 Common Web Design Mistakes and How To Avoid Them (Morgan Kaufmann). He provides some hilarious examples of poor default values

7.3.10.5. examples

Figure 7-30. When an image canvas is resized in Photoshop, this dialog box appears. The original image was 519 x 364, as shown. These dimensions become the default Width and Height, which is very convenient for several use cases. If I wanted to put a thin frame around the image, I can start with the existing dimensions and increase them by just two pixels each; if I want to make the image canvas wider but not taller, I only need to change the Width field; or I could just click OK now and nothing changes.

78. same-page error messages

Figure 7-31. Netflix's registration page

7.3.11.1. what

Place form error messages directly on the page with the form itself; mark the top of the page with an error message, and if possible, put indicators next to the originating controls.

7.3.11.2. use when

Users might enter form information that somehow isn't acceptable. They may skip required fields, enter unparseable numbers, or type invalid email addresses, for instance. You want to encourage them to try again. You want to point out typos before they become a problem, and help puzzled users understand what is asked for.

7.3.11.3. why

Traditionally, GUI applications report error messages to users via modal dialog boxes. Those messages can be very helpful, pointing out what the problem was and how you can fix it. The problem is that you have to click away the modal dialog box to fix the error. And with the dialog box gone, you can't read the error message anymore! (Maybe you're supposed to memorize the message.)

Then, when web forms came along, error messages often were reported on a separately loaded page, shown after you clicked "Submit." Again, you can read the message, but you have to click the "Back" button to fix the problem; once you do that, the message is gone. Then you need to scan the form to find the field with the error, which takes effort and itself is error-prone .

Many web forms now place the error message on the form itself. By keeping both messages and controls together on the same page, the user can read the message and make the form corrections easily, with no jumping around or error-prone memorization.

Even better, some web forms put error messages physically next to the controls where the errors were made. Now the user can see at a glance where the problems wereno need to hunt down the offending field based just on its nameand the instructions for fixing it are right there, easily visible.

7.3.11.4. how

First, design the form to prevent certain kinds of errors. Use dropdowns instead of open text fields, if you can; offer Input Hints, Input Prompts, Forgiving Format , and other techniques to support text entry. Clearly mark all the required fields as required, and don't ask for too many required fields in the first place.

When errors do happen, you should show some kind of error message on top of the form, even if you put the detailed messages next to the controls. The top is the first thing people see. (It's also good for visually impaired usersthe top of the form is read to them first, so they know immediately that the form has an error.) Put an attention-getting graphic there, and use text that's stronger than the body text: make it red and bold, for instance.

Now mark the form fields that caused the errors. Put specific messages next to them, if you canthis will require extra space beside, above, or below the fieldsbut at the least, use color and/or a small graphic to mark the field, as shown above.

Users commonly associate red with errors in this context. Use it freely , but since so many people are colorblind with respect to red, use other cues, too: language, bold text (not huge), and graphics.

If you're designing for the Web or some other client/server system, try to do as much validation as you can on the client side. It's much quicker. Put the error messages on the page that's already loaded, if possible, to avoid a page-load wait.

A tutorial on error-message writing is beyond the scope of this pattern, but here are some quick guidelines:

• Make them short, but detailed enough to explain both which field it is and what went wrong: "You haven't given us your address" versus "Not enough information."

• Use ordinary language, not computerese: "Is that a letter in your ZIP code?" versus "Numeric validation error."

• Be polite: "Sorry, but something went wrong! Please click 'Go' again" versus "Javascript Error 693" or "This form contains no data."

7.3.11.5. examples

Figure 7-32. The user registration page at eBay offers an excellent example of this pattern. The error summary at the top of the form catches the eye and lays out exactly what needs to be fixed before registration can proceed. (It even provides links to the fields in question.) Each of the problematic fields has its own error message, too. It's redundant, but that's okay in this casesome people will zero in on the two red-labeled fields before they finish reading the messages at the top.