- Designing Forms: Thinking in Terms of the Whole
- Input Controls: Picking the Right Tool for the Job
- Common Interaction Problems and Solutions
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Input Controls: Picking the Right Tool for the Job
Like any design medium, mastery of Web design in general and form design in particular requires a solid understanding of the available materials. In this case, that means understanding the input controls available in HTML. Although the vocabulary of radio buttons, check boxes, menus, text boxes, and list boxes might seem limited and simple, there are many subtle and not-so-subtle aspects of each control. The following sections explore each control in detail, including examples of their proper use.
Check Boxes
As in the printed forms from which they are derived, check boxes indicate whether an item is selected. Although they often appear in groups, check boxes do not necessarily have any relationship to one another. Correctly used, the options that check boxes present are independent choices that do not affect any other options on the form. The one exception is when a check box is nested with other input controls to indicate an explicit master-slave relationship. This style of nesting is used when an option has associated "sub-options." For example, an email application could have an option to check for spelling errors before sending a message. If the user selected the spell check option, there could be additional options to indicate which language to use, whether to ignore Internet addresses, and so forth.
Remember that check boxes, whether alone or in a group, don't require users to select anything at all. Unlike radio buttons or menus, this means check boxes typically allow for a "null" selection. However, in some situations, users can select one or more of the available options but are required to select at least one; in other words, a null selection is not valid. In these cases, check boxes can take on a hybrid radio button behavior by using JavaScript to ensure at least one check box is always selected. Figure 8.5 illustrates a common implementation of check boxes.
){kind=link}
Figure 8.5 The use of radio buttons for the first two items under Position Data ensures that the user always has at least one of these fields selected, but allows every other field to be optionally selected.
Radio Buttons
Radio buttons derived their name and behavior from the channel selectors on car stereos. In the physical world as well as the virtual one, radio buttons are used to select one, and only one, choice from an exclusive list of options.
Like check boxes, radio buttons are a fundamental element of all graphical user interfaces, including the Web. Although they have the distinct advantage of showing users all the possible options, they also have the disadvantage of scale. In other words, they don't.
Although radio buttons work great with five to seven options, if you go much past that, the required number of radio buttons simply creates too much visual clutter to be effective. In addition, if the number of options varies depending on the user's information or the application's state, radio buttons are a poor design choice because the increase or decrease in the size of the group introduces too much unpredictability into the layout. Because of those two limitations, radio buttons are most appropriate when they represent a fixed set of two to seven options.
Unlike check boxes, there is always an exclusive and dependent relationship between the radio buttons in a single group. Radio buttons are not solitary creatures and should never appear by themselves. Regardless of the size of the radio group, one and only one of the buttons is always selected. That means one of the radio buttons must always be selected by default.
Although some of the best designed applications fail to indicate a default selection within a radio group, doing so places the group in an unnatural state. For example, RedEnvelope's product-ordering pages include a two-button radio group to choose whether or not to wrap the item in its exclusive gift box (see Figure 8.6). However, the application does not indicate a default selection, so users are forced to make an explicit choice between the two radio buttons. This approach succeeds in making users more aware of the gift box option, but it does so by using radio buttons incorrectly and undoubtedly causes input errors.
){kind=link}
Figure 8.6 No default selection is indicated for the two-item radio group—an improper use of radio buttons as input controls.
When there are only two options, using a single check box in place of two radio buttons is sometimes possible. For example, in a stock portfolio application that can include or exclude closed accounts, it is more compact to have a single check box labeled "Include Closed Accounts" rather than one radio button for include and another for exclude. However, this solution works only when the two options are obvious opposites of one another, such as include/exclude, on/off, or hide/show.
List Boxes
As you might guess from their name, list boxes are used to display lists of items in a fixed amount of space. List boxes can operate in a single or multi-select mode, essentially mimicking a list of radio buttons or check boxes, respectively.
Because they require less screen real estate than a comparable group of radio button or check boxes, list boxes are an effective solution when five or more options are being presented. In addition, because they take up a fixed amount of space, they are particularly effective when the number of options is unknown or variable.
The height of a list box is expressed in lines and is one of the few formatting options available. A reasonable question is "What is the optimal number of lines to display in a list box?" A slightly vague but accurate answer is "Tall enough to reveal a useful number of items but short enough to be visually manageable"—in other words, not too tall and not too short. More precisely, you should aim for between five and seven lines, preferably five or seven lines. Lists with an odd number of items are generally easier to digest visually because one of the list items lies at the exact middle. As a result, it's easier to break the list into two smaller units that are quicker to scan.
The height of the list box not only affects the form's visual layout, but also gives the user an important clue about the list box contents. This is similar to how the length of a text field helps communicate the field's intended contents. A list box that displays three lines implies that the total number of items in the list is relatively short, whereas a list box with a height of seven items implies that the total list is much longer. In addition, the height conveys an impression of the list's importance, with bigger lists being perceived as more important choices than shorter lists.
In addition to the height of the list box, HTML also gives you control over the list box's behavior—specifically, whether the user can select multiple items or only a single item in the list. Put another way, does the list behave like a group of radio buttons or a group of check boxes?
The unfortunate answer is that multi-select list boxes cause a number of usability problems and are an unacceptable option for the majority of Web users. When the list box is in multi-select mode, users can make a multiple selection by holding down a modifier key (for example, the Ctrl key for Windows) while clicking additional items in the list box. However, not all users understand or are even aware of this behavior.
It is also common for a selection to include items spread out across the list. As a result, users have to scroll through the list to view the full selection, often losing track of what is and isn't selected. Depending on the selection and the scroll position, the entire selection might be displayed outside the list's visible area, giving the erroneous impression that nothing is selected. Suffice it to say that multi-select list boxes are riddled with opportunity for error and misunderstanding. If the situation calls for a multiple selection from a long list, there are better solutions than a multi-select list box.
A final point is that list boxes, like a group of radio buttons, should always offer a meaningful default. Similarly, if a null selection is allowed, the list box should contain an option labeled "None" instead of being displayed without a selection.
Menus
If you compressed a list box so that it displayed only one item at a time, you would end up with a menu. Despite the differences in behavior and appearance, menus provide the same function as list boxes and radio buttons: making an exclusive choice from a list of multiple options.
The primary advantage of menus is visual efficiency. In addition to their ability to present a large number of options in a small space, their "now you see it, now you don't" behavior makes them particularly appropriate when the number of options is variable.
Unfortunately, menus have one major weakness: They're hard to use. Picking an item from a menu is one of the most complicated mouse operations there is. Selecting an option from a menu requires two clicks, a complex click-and-drag movement, or a combination of keys from the keyboard. To make matters worse, the click target for an item is fairly small, and the error recovery is zilch. If you pick the wrong item, you're all the way back to square one. Finally, the menu behavior hides options from users and gives them few clues about the menus contents. As a result, menus are not only an exercise in physical dexterity, but also a challenge to understanding and recall.
Despite these caveats, however, menus still occupy an important position in the interactive landscape. The challenge is knowing when and where to use them so as to minimize their disadvantages.
In addition to the ever-present concern for how all the form's elements work together, there are two other considerations specific to menus: how many items it contains and the default selection. Because menus can be difficult to navigate, the number of options should generally be kept short. Although there's no hard-and-fast rule, a list of more than 15 items is hard to look at, and anything north of 21 is difficult to use. These limits can be expanded, however, if the contents of the menu are sorted and well understood by the target user group. For example, a menu containing the 50 U.S. states might be a reasonable solution for a site catering to users in the United States, particularly if the state choice was optional. A list of 50 hotel locations, on the other hand, would not be appropriate because users would be unfamiliar with the list's content and would have to read through each option one by one.
The second consideration when using a menu is indicating a default selection. In many cases, an application won't have the necessary information to provide an appropriate default, so the real question becomes "What is the most effective way to communicate that the user needs to make a choice?" Two methods are commonly used in such situations: Don't indicate a default so the menu is displayed without a selection, or select a dummy item labeled "Select...."
Because the fundamental behavior of a menu is to indicate a selection, not having a selection is an invalid state for the control. Therefore, the optimal solution is to select a dummy item labeled "Select...". Even better is to reference the menu's contents in the selection—for example, "Select State...."
Menus are perhaps the most overused and inappropriately used control on the Web. Of course, they're also one of the most useful. Before you place them all over your forms, however, be sure you understand and accept the usability problems they're likely to introduce.
Text Boxes
Text boxes are used to capture strings of text, numbers, or both. They are the most straightforward input control from a behavior perspective, but because there is no real control over what users type in them, they are also a significant source of input errors. To help alleviate this risk, giving users multiple clues about the correct input is essential. As discussed earlier, these clues include clear labels, sample text, useful defaults, and appropriate sizing.
In addition to width, HTML can also specify whether a text box should display one or more lines of text. Although most text boxes display a single line of text, in some situations—the body of an email, for example—a multiline text box is useful. Whatever the case, it still comes down to setting the text box to a size appropriate for the input.
Buttons
The final commonly used input control is the button. From a technical perspective, buttons come in two basic flavors: Submit and Cancel. Submit buttons send a form's contents to the server for processing, and Cancel buttons throw out a form's contents and return users to the page from whence they came. From a user's perspective, however, a button's function is known by its name.
Because there is no control over a button's appearance, most sites use images in place of standard HTML buttons. Unfortunately, some sites also use links in place of standard buttons. The two objects have different uses, however, and should not be used interchangeably. Although there are rare exceptions, in general, links should be used solely as navigational devices, not to submit or save information. Similarly, buttons should be used only to initiate commands, not as navigation. Figure 8.7 illustrates mixing up the use of links and buttons.
){kind=link}
Figure 8.7 In this example from Yahoo!, the designers have inappropriately used links in place of buttons.
Although HTML provides only a small set of input controls (summarized in Table 8.1), don't let the limited vocabulary dissuade you from creating sophisticated interactions. It's true that a more dynamic set of controls would make some operations easier to design and use, but the set that is available can generally get the job done.
Table 8.1 Standard HTML Interface Controls
|
Name |
Purpose |
|
Check box |
Select none, one, or many from a fixed list of options, preferably seven or fewer. |
|
Radio button |
Select one and only one from a fixed list of options, preferably 7 or fewer. |
|
List box |
Select one and only one from a list of any size. (single select) Also used for lists containing an unknown number of options. |
|
Menu |
Select one and only one from a list, preferably fewer than 25 items. Also used for lists containing an unknown number of options. |
|
Text box |
Input a string of any length. |
|
Button |
Perform an action or a command. |
|
File |
Upload a file. |