What

Permit users to enter inputs in a variety of choices, formats, and syntax, and make the application interpret it intelligently. Weather.com (Figure 10-1) shows an example of this.

Figure 10-1. Weather.com

Use when

Your UI asks for data that users might type with an unpredictable mix of vocabulary or styling (whitespace, hyphens, abbreviations, or capitalizations). More generally, the UI can accept input of various kinds from the user—different meanings, formats, or syntax. But you want to keep the interface visually simple.

How

The catch: it turns a UI design problem into a programming problem. You need to think about what kinds of text a user is likely to type in. Maybe you ask for a date or time, and only the format varies—that’s an easy case. Or maybe you ask for search terms, and the variation is what the software does with the data. That’s more difficult. Can the software disambiguate one case from another? How?

Each application uses this pattern differently. Just make sure the software’s response to various input formats matches what users expect it to do. Test, test, and test again with real users.

Examples

The New York Times uses Forgiving Format in several features that need information from users. Figure 10-2 shows examples from its real estate search and from its financial quotes feature.

Figure 10-2. Two search fields in the New York Times website hint at the variety of possible formats they will accept

Google Finance (Figure 10-3) helps users find the correct stock symbol by mapping what they type to the most likely matching stock symbols. It’s not necessary to know or enter the exact stock symbol.

Figure 10-3. Adding a stock to a personal watchlist in Google Finance

Consider forms that request credit card numbers from the user. As long as 16 digits are typed, why should the form care whether the user separates them by spaces, or by hyphens, or by nothing at all? PayPal, for example, allows customers to enter their credit card number however they want. The credit card number field accepts spaces as separators, hyphens, or no spaces. Paypal standardizes the format immediately afterward. (Figure 10-4).

Figure 10-4. PayPal

Figure 10-5 comes from Google Calendar’s tool for setting up a meeting. Look at the “from” and “to” fields in the screenshot—you don’t need to give it a fully defined date, like what’s in the text fields now. If today is July 13 and you want to set up a meeting for July 20, you can type any of the following terms:

• Saturday 7/20

• Saturday 20/7

• 20/7/2019

• 7/20/2019

• 20/7

• 7/20

The specified date then is “echoed back” to the user in the appropriate format for the user’s language and location.

Figure 10-5. Google Calendar

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.  San Francisco Public Library (Figure 10-9) uses this approach for its search.

Figure 10-9. San Francisco Public Library

Use when

You need to ask the user for input, usually one-line text, a number, or a choice from a drop-down 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.

Why

Fill-in-the-Blanks helps to make the interface self-explanatory. It makes it easier to construct rules or conditions. 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 required.

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, drop-down list , and combo boxes—in 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 will 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 eBay examples in Figures 10-10, 10-11, and 10-12 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.²

There’s a big “gotcha” in this pattern, however: it becomes very difficult to properly localize the interface (convert it to a different language) because comprehension now depends upon word order in a natural language. For some international products or websites, that’s a nonstarter. You might need 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.

Examples

Microsoft Excel makes extensive use of Fill-in-the-Blanks for its conditional formatting rules. These allow users to set up automatic cell highlighting based on logical rules so that it’s easy to see important status or results. Using the sentence-style format of Fill-in-the-Blanks makes it easy to specify the desired logic.

In Figures 10-10 and 10-11, we see two different ways Excel enables this. In the “Classic” example, a sequence of drop-down menus with phrases allows the user to set up a fairly complicated If-then instruction. The user selects a series of statements and conditions in a sentence-like sequence to specify the desired logic. In Figure 10-10, reading the fill-in-the-blank structure sounds very close to natural language instructions: “Format only cells that contain a cell value between 33 and 66. Format them with a yellow fill and bold yellow text.”

In Figure 10-11, we’re creating instructions for when to display green, yellow, and red icons. There’s more to configure here, but Excel lays out a stack of three fill-in-the-blank statement builders. These are more compact, using logical symbols like “>=” instead of writing out “greater than or equal to.” Still, it’s easy to construct the display logic by stepping through the fill-in-the-blanks structure. It’s a little more work, but for the green icon, reading left to right, we can get “Display the green icon when the value is greater than or equal to 67 percent.” Excel takes the numerical value that the user enters here and automatically prefills the fill-in-the-blank logic for the second, yellow icon so that it doesn’t conflict with the first.

Figure 10-10. Classic conditional fomatting in Microsoft Excel

Figure 10-11. Icon Set conditional formatting in Microsoft Excel

When users search for items on eBay, they can use the Advanced Search form to specify various criteria. The form shown in Figure 10-12 has several examples of Fill-in-the-Blanks.

Figure 10-12. eBay search filter form

What

Prefill a text field with an example input or instructional text that helps the user with what to do or type. This is also called placeholder text.

Use when

The UI presents a text field, drop-down list, or combo box for input. Normally you would use a good default value, but you can’t in this case—perhaps there is no reasonable default. The examples from the Blueprintjs UI Toolkit (Figure 10-19) show how prompts can help explain the function of the input field.

Figure 10-19. Blueprintjs UI Toolkit; four example inputs with prompts

Why

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

With Input Hints, 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 they have to deal with this control or not—the control itself tells them to. (Remember that users don’t fill out forms for fun—they’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.

How

Choose an appropriate prompt string:

• For a drop-down list, use Select, Choose, or Pick

• For a text field, use Type or Enter

• A short verb phrase

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 drop down; if the user selects it, it’s not clear what the software should do with it.)

Because 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 need to throw an error message at the user.

For text fields, put the prompt back into the field as soon as the user erases the typed response.

Use Good Defaults and Smart Prefills instead of an Input Prompt when you can make a very accurate guess about what value the user will put in. The user’s email address might already have been typed somewhere else, for instance, and the originating country can often be detected by websites.

What

As the user types into a text field, anticipate the possible answers, show a selectable list of them, and automatically complete the entry when appropriate.

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 the user is attempting to type—perhaps there’s a saved history of things this user has previously typed, for instance, or perhaps they are picking from a set of preexisting values, such as a list of filenames in a directory.

Search boxes, browser URL fields, email fields, common web forms (such as site registration or purchase), text editors, and command lines all seem to be much easier to use when supported by Autocompletion.

Predictive and social algorithms now drive autocomplete, as well. Popular, trending or most commonly entered search terms populate search engine autocompletes.

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, 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

• Possible matches drawn from the content being searched or perused, as for a site-wide search box

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

• Most popular or frequently submitted request strings

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—for example, by pressing the Tab key—and let the user choose one explicitly by picking from that list. Many code editors do this. It’s probably better used when the user would recognize what they want when they see it but might 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 tool tip; 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 not—and the default is to not keep it.

Make sure that Autocompletion doesn’t irritate users. If you guess wrong, the user won’t like it—they then must erase the Autocompletion and retype what they meant in the first place, avoiding having Autocompletion 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 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.

What

Expand the concept of a menu by using a drop-down list or pop-up panel that contains a more complex or hierarchical selection UI.

Use when

The user needs to supply input that is a choice from a set (such as in the color example in Figure 10-37), 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 choice—a nice visual rendering of the choices, for instance, or interactive tools—but you don’t want to use space on the main page for that; a tiny space showing the current value is all you want.

Why

Most users are very familiar with the drop-down list control (called a combo box when used with a free-typing text field). Many applications successfully extend this concept to drop-down lists 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.

Drop-down 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 shows itself only when the user requests it—an appropriate way to hide complexity until it is needed.

How

For the Drop-down 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 can 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.

Design a chooser panel for the choice the user needs to make. Make it relatively small and compact; its visual organization should be a familiar format, such as a list, a table, an outline-type tree, or a specialized format like a calendar or calculator (see the examples in the next section). See Chapter 7 for a discussion of list presentation.

Scrolling the panel is fine 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 UIs—for example, color-chooser dialog boxes, file-finder dialog boxes, or help pages—that help the user choose a value. These devices usually are modal dialog boxes. In fact, if you intend to use one of these modal dialog boxes as the primary way the user picks a value (say, by launching it from a button), you could use a Drop-down Chooser instead of going straight to the modal dialog box. 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.

What

A pattern for creating a complicated selection set from a larger source set of objects. A list builder has the “source” and the “destination” lists visible in the same widget. This lets the user move items between them, via buttons or drag-and-drop. This pattern is also called a two column multiselector.

Use when

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

How

Put the source list and the destination list next to each other, either left to right or top to bottom. Between the two lists, put Add and Remove buttons (unless your users find drag-and-drop to be obvious, not requiring explanation). You could label the buttons with words, arrows, or both. Clicking list elements can also cause them to jump to the opposite list.

This pattern provides room for additional functionality, too. Both the source list and the destination list may be searchable. The source list could be a multilevel directory with an open/close file folder structure. The destination list could be ordered, with tools to move or drag and drop the items into the desired order from top to bottom.

Depending on what kind of items you deal with, you could either move the items literally from the source to the destination—so the source list “loses” the item—or 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 because they see such a list as a model of the underlying filesystem, and the files aren’t actually deleted. That’s a judgment call.

Give the lists multiple-selection semantics instead of single-selection, so users can move large numbers of items from list to list.

Examples

Most modern implementations of this pattern depend upon drag-and-drop or simple clicking to move items between areas; it’s important that the user receive visual confirmation that selected items are moved to the destination list. The web application multiselector, multiselect.js, shows a fast and simple UI for creating lists (Figure 10-42). This open source developer project has developed a typical two-column multiselect widget for use in web applications.

Figure 10-42. Loudev.com multiselect.js

Drupal offers a similar component, a multiselect list builder widget, as part of its enterprise content management system (Figure 10-43).

Figure 10-43. Drupal content management system

Graphical list building works, too. Lightroom (Figure 10-44) demonstrates a more contemporary approach to a List Builder: you can drag items from a potentially long list of source images into a “batch” group in order to perform operations on all batched images at once. Large text informs the user what to do at critical moments in the interaction, such as starting a new batch or removing an image from the batch.

Figure 10-44. Adobe Lightroom

What

Use default values for form elements that are intended to save the user time and effort in completing the form. Good defaults draw from a number of sources of data for prefills: previously entered data from the session, information from the user’s account, current location, current data and time, and other values that the designer can identify as having a high probability of making it easier and quicker for the user to complete a form.

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 need 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 semirelevant questions, maybe the user can’t be expected to know or care about the answer, and “whatever the system decides” is OK.

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 prefilling 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 selected by default!)

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 having default answers provided halves the time it takes the user to work through the form, they’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 the user a few seconds of thought—or, worse, an error message.

Sometimes, you might run into an unintended consequence of Good Defaults. If a user can skip over a field, that question might not “register” mentally with the user. They might forget that it was asked; they might 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.

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 US Zip Code, you can infer the state, country, and municipality 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 it—otherwise, you will create extra work for everybody. Know your users!

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

Examples

Kayak (Figure 10-45) supplies default values when a user begins a search for flights. Kayak kindly suggests a week-long vacation: it prefills the flight search with duration of one week, starting a month from now. The other defaults are quite reasonable: a round-trip economy flight with one traveler is common, and the “From” city can be derived from either the user’s geographic location or the user’s previous searches. Kayak goes one step further by prefilling the departure date (a month in the future) and the return (one week later). The effect of having all these defaults is that the user spends less time thinking about those parts of the form, and they get a quicker path to their immediate goal—the search results.

Figure 10-45. Kayak

The Fandango mobile app (Figure 10-46) uses the current location and date as its default movie search parameters. When the person opens this app, it uses the current date and location to generate a list of movies for today near where you are. It goes one step further: the default for this screen has a small “toast” or pop-up banner at the bottom (on top of the search results), offering a look at what’s playing today at the very nearest movie theater.

Figure 10-46. Fandango (iOS)

When creating a new image file in Photoshop, it starts by default with the OS clipboard (Figure 10-47). The assumption here is that the user has just created a screenshot and is in the process of editing that image. So Photoshop takes the width and height of the image in the clipboard and uses that to prefill the dimensions of the Create New file, a smart way to save time. No worry that the image and the canvas will have a size mismatch.

Figure 10-47. A Create New dialog in Photoshop CC

When an image canvas is resized in Photoshop, the dialog box shown in Figure 10-48 appears. The original image was 1340 × 1060, as shown. These dimensions become the default Width and Height, which is very convenient for several use cases. The application prefills the width and height of the current image as the starting point for a different canvas size. If the user wants to put a thin frame around the image, they can start with the existing dimensions and increase them by just two pixels each; if they want to make the image canvas wider but not taller, they need only change the Width field; or just click OK now and nothing changes.

Figure 10-48. Canvas Size dialog box in Photoshop CC

What

When there is a form input error, such as a skipped required field, place an eye-catching explanatory error message directly on the form itself. The message might describe how the user can fix the error. If possible, put indicators next to the originating controls.

Use when

Users might enter form information that somehow isn’t acceptable. They might skip required fields, enter numbers that cannot be parsed, 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.

How

First, design the form to prevent certain kinds of errors. Use drop-down lists instead of open text fields if the choices are limited and not easy to type. For text fields, offer Input Hints, Input Prompt, Forgiving Format, Autocompletion, and Good Defaults and Smart Prefills to support text entry. Limit the total number of form fields as much as possible. Have a clear system for marking what fields are optional and what are required.

When errors do happen, and your form is long or complicated, you should show some kind of error message on top of the form. The top is the first thing people see. (It’s also good for visually impaired users—the 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. In contemporary short forms, this step is often omitted.

The universal standard is to mark the form fields that caused the errors. You should display element-specific messages next to each affected control. This will require extra space beside, above, or below the fields—but at the least, use color and/or a small graphic to mark the field. 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. This means checking for and displaying validation feedback to the user as they fill out the form, not after they have submitted it. The contemporary standard is to validate an input as soon as the focus moves to the next input field. Some forms have validation code that begins checking input as soon as the user selects the input field. Errors and feedback can appear once a user triggers it with their data entry. Either way is much quicker: The user has a chance to fix everything before submitting the form. (In some clumsy designs, an error message appears as soon as the user begins to type a valid entry, and it doesn’t disappear until the user finishes a valid string or entry. This is inappropriate and annoying, so don’t do this.)

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.”

Examples

The registration forms for Mailchimp (Figure 10-49), Mint (Intuit) (Figure 10-50) and H&M (Figure 10-51) show a traditional approach. The user fills out the form and then selects submit. The Get Started! button for Mailchimp becomes active after successfully entering an email address and password, but omits checking for the required Username field. To discover this, the user has to submit and then try again. The specific problem inputs are highlighted for correction, with error messages. Mailchimp displays a generic error alert at the top of the form in addition to marking the error inputs. However, the error messaging is clear.

Figure 10-49. Mailchimp registration page

In the Mint example (Figure 10-50), the error message explains that the second password string does not match the first, and needs to be re-entered so it does match.

Figure 10-50. Mint (Intuit) registration screen

At H&M (Figure 10-51) the Become a Member button is always active. If the customer forgets a required field, they get an error message only after selecting Become a Member. The error message itself is good: It says exactly what needs to be done to fix the problem.

Figure 10-51. H&M

The standard solution today is to avoid creating a situation where the user skips a required step or has an invalid entry in the first place. The submit option simply doesn’t become active until the required steps are filled in successfully.

Twitter breaks their sign-up process into multiple steps (Figure 10-52). In Step 1, the option to continue is not active by default. There is no option to go to Step 2 until this screen is successfully filled out. This drives the outcome of completing the form successfully with properly formatted data in order to get to the goal of the next step in registration. Bonus: The form is in a modal dialog box. There is no other navigation to distract, except to quit the whole process. Validation happens in real time, before the user selects the Next button. After the user fixes the required fields, the next step selector becomes active. Email address validation happens in real time. Actionable feedback appears without having to submit the form, saving the user a wasted action.

Figure 10-52. Twitter registration

When you add a not fully specified item to your cart at the Jos. A. Bank site, it uses a gentle message to remind you to fill in missing information, as shown in Figure 10-53. In this case, the Add to Bag button is always active. The shopper must select it to generate the validation error message.

Figure 10-53. Jos. A. Bank