1. Guidelines For Obtaining Input From The User

1.1. Selecting From A Set

1.1.1. "One Of Many" Choices

The choice of the correct interface form for mutually exclusive choice groups depends on the following criteria:

1. number of times used,
2. number of items in the group,
3. space available on the display,
4. frequency with which items are added or deleted from the group,
5. nature of the attributes themselves (i.e., discrete or continuous attributes)

When using a mutually exclusive choice, you should be most sensitive to the number of times the mutually exclusive choice group is used. For example, if the user is frequently changing the attribute values (e.g., in a paint application the user might be switching paint tools frequently), do not use a dialog box. This would be too tedious. It would be better, in this case, to use a pull-down menu or a continuously displayed icon panel.

Table 1-1 presents the selection criteria in the left column and the recommended interface form in the right column. If your criteria do not fit exactly into one of the boxes on the left column choose the one that is closest to the kind of items you have. Each of the interface forms and its variants is discussed in detail below.

If Mutually Exclusive Items are...	Then Use the Following Form...
attributes or values that are selected frequently are limited in number (2-8) are best represented verbally, and change rarely.	Attribute menu items
attributes or values that are selected infrequently are limited in number (2-8) change infrequently, and require little screen space.	Pop-up menu or Drop-down list
attributes or values or objects (e.g., file names) that are potentially large in number are best represented verbally, and can change frequently.	Single-selection lists
attributes or values or objects that are selected infrequently are relatively few in number (8 or fewer) have sufficient screen space available, and do not change.	Radio buttons
commands that are selected frequently, and have only two conditions.	Toggled-menu items
commands that are selected infrequently, and have only two conditions	Toggled-command buttons
attributes that are selected very frequently are limited in number are best represented graphically are discrete in nature, and change very rarely.	Icons, icon lists, or icon palettes
attributes or values that are best represented graphically, where other forms do not apply.	Specialized graphical control

Table 1-1: This table presents the conditions for selecting the proper interface form for mutually exclusive choices

1.1.1.1. Interface Forms

1.1.1.1.1. Attribute Menu Items

1.1.1.1.1.1. Proper Usage

+Use an attribute menu when

• options must be accessed frequently
• the number of options in the group is small (i.e., no more than eight), and
• the items in the group rarely change.

Comment: There is a tradeoff between the time it takes to find an item and the number of selections that must be made. While the optimal menu design for any application is task dependent, research on menu design indicates that the optimal number of items per menu group (A "group" is any set of menu items. A group on a pull-down menu is anything between two separators or the whole list if there are no separators on the pull-down menu. Choice groups must be offset by separators.) is between four and eight. Moreover, there is another practical consideration: As the number of menu items increases, the menu gets longer. It is strongly suggested that you limit the size of the menu such that the whole menu; can be displayed entirely without scrolling.

The frequent (and excusable) exception to the numerical limits are the Font and Size menus used in most text editors. A system may have available hundreds of fonts that the user might wish to access regularly. Most users will have between 5 and 20 fonts installed; these should be listed on an attribute menu. Putting the list of fonts in a scrolling list on a dialog box requires users to work more than do attribute menus. (However, a scrolling list may be acceptable if the fonts are not regularly added and/or deleted; see below.)

The symbol used to mark the selection on the menu itself differs across platforms and is discussed in Section 3.1.3.2.

Figure 1-1 shows an example of the attribute menu. The Font menu is used to pick the active font in a text editor. In this case, Athens has a diamond next to it, meaning the Athens font is currently in use. If the user next picked London the diamond would move to London, and the London font would be applied to the objects in force at the insertion point.

Figure 1-1: An attribute menu list is used to set one item in force. In this case, the Athens font is the one selected.

1.1.1.1.1.2. Variations

One variation of the attribute menu is to put the attribute choices on a cascaded menu. For instance, many text editors use Text as the menu title. Within the Text menu they list Font, Size, and Style as three menu items, each with a cascaded menu. In general, the use of cascaded menus for making mutually exclusive choices is acceptable with the following three caveats. First, do not go beyond one level of a cascaded menu; it is too hard for users to keep track of all the settings or to undo a mistaken setting. For instance, with cascaded menus, if the user wants to see the font size, she or he has to pull down the menu and make another selection before she or he can find the current font size. Second, cascaded menu items must be attributes; do not put commands on cascaded menus. Third, consider using cascaded menus only when it makes sense to use a pull-down menu, and the menu bar is getting crowded with other entries.

1.1.1.1.1.3. Misusage

Attribute menu items must not be used as commands. If the user will frequently access a set of choices, consider using a palette instead of an attribute menu.

More Reading

• Apple HIG, p. 67-69.
• OSF/MSG, § 4.2.3.
• Windows ADG, § 5.1.1., 5.1.3., 5.2.2.1, 5.3.1.1.3.
• Kobara, p. 112-116, 152-154.
• OL/ASG, p. 293-294.
• IBM SAA CUA AIDR, p. 233-234.
  

  Go to Top ^

1.1.1.1.2. Pop-Up Menu

Figure 4-2: A Pop-up menu used in Apple.

Figure 1-3: An example of a drop-down list that allows the rapid setting of styles in Microsoft Excel in Windows.

1.1.1.1.2.1. Proper Usage

+Use pop-up menus or drop-down lists when

• the attributes and values on the menu are set infrequently,
• there are only a limited number of choices available, and
• screen space is limited.

+The objects in the group should rarely change.

If they change often, consider using a scrolling list instead.

1.1.1.1.2.2. Variations

Pop-up menus in Apple may also contain graphics; more discussion of this variation is found below in Section 4.2.4.

1.1.1.1.2.3. Misusage

Only use pop-up menus or drop-down lists to set related attributes and values; they must not contain commands. This is more restrictive than the guidelines set forth by Motif, CUA, and Windows.

Do not use pop-up menus when there are over 15 potential choices; use a scrolling list instead (see Section 4.1.1.1.3).

More reading

• Apple HIG, p. 88-90.
• OSF/MSG, § 4.2.3.
• Windows ADG, § 6.3.1.3.
• Kobara, p. 112-117.
• OL/ASG, p. 143-145, 278-280.
• IBM SAA CUA AIDR, p. 184-185.
  

  Go to Top ^

1.1.1.1.3. List

1.1.1.1.3.1. Proper Usage

+Use lists for setting attributes or picking objects when

• items are not selected frequently,
• the set of items is large, and
• choices can change frequently.

Figure 1-4 shows a list from which the user can select a single item. Note that the scroll bars should appear (although disabled) even if the list cannot scroll.

Figure 1-4: Use a list to reflect choices when those items vary as the application runs or when users are able to edit the items as they appear on the list.

+Use lists on dialog boxes where the user must select a file or a predefined style. Motif provides some compound widgets, whose principal component is a list for handling objects: commanddialog, selectiondialog, and fileselectiondialog. These widgets allow the user to select one object from among the many that are available. Do not build other kinds of list objects to handle these transactions when the standard widgets will work.

1.1.1.1.3.2. Variations

One variation on the list is the spin button (Windows calls it a "spin box"; IBM CUA SAA AIDR, p. 246, Windows ADG, § 6.4.2.). The spin button has a text box and two arrows that allow a user to display in sequence a list of mutually exclusive choices. For example, a spin button could be used to display the months of the year.

+Spin buttons should only be used for highly predictable discrete sets of values (e.g., months or days of the week).

1.1.1.1.3.3. Misusage

The list box is flexible enough to handle most kinds of mutually exclusive choices. However, list boxes require more work on the part of the user than do other kinds of mutually exclusive controls. Thus, even though a list box can be used, it does not mean that it is ideally suited for the job. Consequently, do not use a list box if another control is more appropriate. Refer to Table 4-1 to select a more appropriate form.

More reading

• OSF/MSG, § 4.1.2.1.
• Windows § 6.3.
• Kobara, p. 134-136,153-154.
• OL/ASG, p. 216-221.
• IBM SAA CUA AIDR, p. 49-50, 82-85, 132-133.

1.1.1.1.4. Radio Buttons (Or As Windows Calls Them Option Buttons)

1.1.1.1.4.1. Proper Usage

The labels on radio buttons must not change.

+Use radio buttons for setting attributes or values when

• there are eight or fewer options,
• there is sufficient screen space, and
• the user does not need to change settings frequently.

+Put a group box around the radio button group for visual separation, such as indicated in Figure 4-5.

If available screen space is limited, consider using a pop-up menu or list box.

Figure 4-5: Radio buttons provide a clear and efficient way for users to set attributes or values, especially when discrete and few in number.

1.1.1.1.4.2. Misusage

Radio buttons must not to be used for commands; however, selecting a radio button can be used to activate other controls.

Radio buttons convey an exclusive-or relation among a group of items and must not be used by themselves; that is, there should always be more than one radio button in a group.

+When arranging a set of related radio buttons, make sure that the choices are labeled clearly and kept visually cohesive. Figure 4-6 shows an example where the designer used a set of radio buttons, it is not clear which button controls which frequency setting. Generally, it is easier for the eye to scan up and down a list of radio buttons than to scan left to right. While this particular case is not dramatic nor particularly error prone, with some thought the designer could have done better.

poor practice:

Figure 4-6: An example of the use of radio buttons that might have been laid out more carefully.

More reading

• Apple HIG, p. 57.
• OSF/MSG, p. 7-96.
• Windows ADG, § 6.1.2.
• Kobara, p. 67-72.
• IBM SAA CUA AIDR, p. 201-202.

  Go to Top ^

1.1.1.1.5. Toggled-Menu Items

Figure 4-7: Shows the use of a toggled-menu item. Depending on the current condition (i.e., whether the grid is currently displayed or not) the menu item would change to reflect the command indicating the opposite action.

1.1.1.1.5.1. Proper Usage

+Use toggled-menu items for two and only two opposite commands that are accessed frequently (e.g., Hide Ruler/Show Ruler, Turn X On/Turn X Off, etc.).

+Since toggled-menu items are commands, they should begin with verbs (not adjectives!) that unambiguously represent the outcome of the command.

1.1.1.1.5.2. Variations

One alternative to toggled-menu items is to put two controls on a menu. For instance, in Figure 4-7 Hide Grid and Show Grid could be represented as two separate menu items under the View menu title, with dis/enabling doing the work of the toggling. This two-item approach is discouraged because it (1) requires two menu items where one will do, and (2) increases visual clutter. Although if the two commands are not exactly opposite, the two item approach might be best for the sake of clarity (see Windows ADG, p. 83).

1.1.1.1.5.3. Misusage

The difference between a command and an attribute, differences can sometimes be confusing. Some commands have the effect of setting attributes. For instance, in Figure 4-8 the Align menu is used to align application objects to a grid or to other application objects (e.g., circles in a draw program). Because the Align setting is Left each new or moved object is aligned to the nearest left grid mark. It might be tempting to implement this as a toggled-command, as demonstrated in Figure 4-7; however, it would be difficult to use a toggled-menu to set the attributes left and right or top and bottom. In toggled-menu items, often the leading command verbs change (e.g., Hide and Show). When setting attributes, the command itself (e.g., Align) does not change, but the adjective (e.g., Left vs. Right) does. Thus, an attribute menu item is more appropriate for setting these command-like attributes.

Figure 1-8: A toggled menu item is used to set one item in control. In this case, in both the left/right and top/bottom dimensions the user can set one, and only one, attribute to be in effect in each dimension for alignment.

More reading

• Apple HIG, p. 68.
• OL/ASG, p. 293-294.
• Windows ADG, p. 83.

1.1.1.1.6. Toggled Command Buttons

1.1.1.1.6.1. Proper Usage

+Use a toggled command button when the user needs to issue one of two opposite commands while setting options or picking objects on a list. For instance, the user picks an object on a list and depending on the state of the object, the command button will perform the appropriate action. In one state, the button label indicates an action, such as Add in Figure 4-9. As with toggled-menu items, the labels should be verbs not adjectives.

Figure 1-9: Shows the use of a toggled-command button. In this particular instance, the user picks an item from a list, and if the item is currently on the menu bar the Delete label is used. If the item is not on the menu the user can add it by selecting the item and pressing Add.

1.1.1.1.7. Icons, Icon Lists, And Icon Palettes

Note: There is another class of icons that has properties in and of itself. For instance, a telephone icon that shows its on-hook state with the handset being on the switchhook might change to showing the handset off the switchhook if the user is on a call. These kind of icons will be covered in a future release of this document.

1.1.1.1.7.1. Proper Usage

+Use icon palettes under the following conditions:

• Users must change the attribute frequently. If the paint tools displayed in the left panel of Figure 4-10 were available to the user in a menu or a list, the application would be tedious to use.
• The icons should unambiguously represent concrete real-world objects. If they do not convey a clear meaning, then consider not using icons at all, or possibly using icons with labels, on icons. The best way to find out whether the icons are .clear and unambiguous is to test them with users.

Figure 1-10: Icons can be used to represent attributes and current settings of the user's application environment. The left panel shows a panel of icons used in a paint program. Each of these tools needs to be accessed frequently, and can be reasonably well represented as an icon. In the right panel, the icons signify how the text is to be justified.

1.1.1.1.7.2. Variations

Icons can be presented on fixed palettes, or floating palettes. Use fixed palettes (such the tool sets shown in Figure 4-10) if the attributes on the palette need to be available all the time. Use floating palettes for selections that are needed heavily at certain times and infrequently at others.

1.1.1.1.7.3. Misusage

The use of icons is encouraged where icons accurately and simply convey the meaning of the action or attribute, especially if they represent attributes the user can pick from menus. However, do not use icons when words alone will do the job better than icons (i.e., icons are confusing). In such cases, a pop-up menu (or other mutually exclusive object) would be more appropriate.

More reading

• Apple HIG, p. 90-92.
• OSF/MSG, § 4.1.1, 5.2.3, 5.5.
• Windows ADG, § 4.2.8., 7.3.3.
• Kobara, p. 181-193.
• OL/ASG, p. 294-296.
• IBM SAA CUA AIDR, p. 113-114.

  Go to Top ^

1.1.1.1.8. Specialized Graphical Controls

Specially designed graphics (e.g., a volume knob or sliding bar) can be the most appropriate means of setting an attribute that has a continuous value (e.g., sound level). Since each graphic is unique each would be controlled differently, but the underlying idea is that a graphic should make it easy for the user to interpret what it is and how it works.

1.1.1.1.8.1. Proper Usage

+Use graphical controls when

• the set of possible values is continuous with a large range (i.e., the saturation level of the color red), and
• the attribute lends itself well to graphical depiction or manipulation.

When designing these graphics keep the following two things in mind:

• The graphic must unambiguously represent a concrete real-world object. A specialized graphical control should not be used if it is more complicated than another interface object in the toolkit. The only way to find out whether it is harder to use than a toolkit object is to test it with real users.
• Keep the graphics simple. Complicated graphics stand out from the application environment, and probably will not be easily recognizable or usable.

Examples of graphical controls are color wheels on the Macintosh and color sliders in Motif. Figure 4-11 provides an example of the use of a slider to allow the user to manipulate the size of an object through use of the slider. Figure 4-11 also shows the good practice of putting the precise value (i.e., 50%), in addition to the level of the slider, next to the control itself. In fact, put the value in an editable field, so that if the user wants to enter a precise value the user does not have to use the slider.

Figure 1-11: An example of a graphical object (i.e., a slider) that conveys a continuous state. This object is familiar and easily interpreted by most users.

1.1.1.1.8.2. Misusage

+Specially designed graphics can be a powerful way to present mutually exclusive choices, provided that the use of graphics is consistent throughout the application. Unless there is a compelling reason to create a special graphic, use the objects provided in the respective toolkits. Remember that for any specialized graphic, the user will have to spend time figuring out how to use it, when he or she may already know how to control, say, a radio button.

More reading

• Apple HIG, p. 57.
• OSF/MSG, p. 7-103.
• Windows ADG, § 6.6
• Kobara, p. 94-98.
• OL/ASG, p. 255-259.
• IBM SAA CUA AIDR, p. 242-243.

1.1.1.2. Incorrect Forms

There are several incorrect ways of presenting "one of many" choices. Some of them were covered in the preceding section. Listed below is one of the more common errors.

1.1.1.2.1. Check Boxes

Check boxes should be used in groups for non-mutually exclusive choices. Often they are used for mutually exclusive binary choices, but this practice is discouraged. A check box, in isolation, is not as easily interpreted as a pair of radio buttons, especially to novice or casual users (Figure 4-12 shows an example). A check box requires the user to interpret the meaning of both states of "Network" rather than have them stated explicitly (as in the case of the radio buttons).

Appropriate use of radio buttons for binary choice

Inappropriate use of check box for binary choice

Figure 1-12: Experienced users might not have trouble using or understanding the radio buttons in Panel A or the check box in Panel B. The novice or casual user might find ambiguity of the check box makes it more difficult to interpret than radio buttons.

Figure 1-13 further demonstrates why a check box can be difficult; the wording is often ambiguous. When the box in Figure 4-13 is not checked, it is not clear whether the icon is in the foreground or does not even exist.

Figure 1-13: Check boxes can often be worded ambiguously when used in isolation to indicate a binary state.

Check boxes may be used if another control is not appropriate and if check boxes unambiguously represent the choice; take care to word check boxes so that the meaning is clear in both the selected and unselected state.

1.1.2. "N Of Many" Choices

The choice of the recommended interface form depends on the

1. number of times that an option is selected,
2. number of items in the group,
3. space available on the display, and
4. frequency with which items themselves can be added or deleted from the list of available choices.

The developer should put most weight on the frequency of selection, i.e., item (1) above. If the user is frequently selecting from the attribute group, make the selection as easy and available as possible; in this case, a fixed icon palette or a pull-down menu with attribute menu items would be appropriate.

Table 1-2 presents the selection criteria in the left column and the recommended interface form in the right column. If your criteria do not fit exactly into one of the boxes on the left column choose the one that is closest to the kind of items you have. Each of the interface forms and its variants is discussed in detail below.

If Non-Mutually Exclusive Items are...	Then Use the Following Form...
attributes or values that are selected frequently are few in number (2-8 choices) are best represented verbally, and change rarely.	Attribute menu items
attributes or values or objects (i.e., file names) that are selected infrequently are potentially large in number are best represented verbally, and can change frequently.	Multiple-selection lists
attributes or objects or values that are selected infrequently are relatively few in number (8 or fewer) have sufficient screen space available, and do not change.	Check boxes

Table 1-2: This table presents the conditions for selecting the proper interface form for non-mutually exclusive choices.

1.1.2.1. Interface Forms

1.1.2.1.1. Attribute Menu Items

Attribute menu items located on a pull-down menu provide the user with a set of items from which the user can make several selections. In other words, these are non-mutually exclusive choices. The items themselves are attributes rather than actions or commands. When selected, these attributes remain in force until they are deselected by selecting them a second time.

1.1.2.1.1.1. Proper Usage

+Use an attribute menu for displaying non-mutually exclusive choice groups when:

• options need to be frequently accessed,
• the number of options in the group is small (i.e., no more than 8), and
• when the choices themselves change infrequently, if at all.

Figure 4-14 shows an example of an attribute menu. The Style menu is used to pick which style is to be used at the insertion point (or applied to a group of selected text) in a text editor. In this case, Bold and Underline have check marks next to them, meaning the current text will be both emboldened and underlined. If the user next picked Italics a checkmark would appear next to Italics and the current text would be emboldened, underlined, and italicized.

Figure 1-14: An attribute menu can be used to set several items in force. In this case, the Bold and Underlined items are selected.

Note: According to strict standards, there should not be interdependencies among the settings in a non-mutually exclusive choice group. However, in the case of Figure 4-14 the text cannot be both condensed and extended at the same time, so selecting one has to deselect the other. While this is technically a violation of the standard, in practice "non- mutually exclusive" means that not all combinations are possible.

Include one option that deselects all other options (e.g., Plain text in Figure 4- 14). The rationale is if the user wants to globally disable all the settings, it makes sense to allow the user to do so with one simple action. In situations where this logic makes sense, you are encouraged to employ such an option and create dependencies.

1.1.2.1.1.2. Variations

Non-mutually exclusive attribute menu items can be implemented on cascaded menus, if menu space is a limiting factor. See Section 4.1.1 for more details.

1.1.2.1.1.3. Misusage

Attribute menu items must not be used as commands.

More reading

• Apple HIG, p. 68.
• OSF/MSG, p. 7-15.
• Windows ADG, § 5.1.1., 5.1.3., 5.2.2.1, 5.3.1.1.3.
• Kobara, p. 64-66.

1.1.2.1.2. Multiple-Selection Lists

1.1.2.1.2.1. Proper Usage

+Use a multiple-selection list box for non-mutually exclusive choices when:

• there are a large number of items available to the user, and
• the group needs to be accessed infrequently; from a user standpoint, list boxes can be cumbersome - use them sparingly.

+Lists are also a good choice if the user can edit the labels of items that show up in the scrolling lists, or add and delete items themselves. For example, in file dialog boxes the list contains the names of all the files available for opening, and the user ultimately has control over the names of the files. Presenting files in anything other than a list would require changing the label of a widget every time it appears.

Most of the time list boxes are used for mutually exclusive selections involving objects, like fonts, files, data records, etc. In Figure 4-15 the user is picking several different (non-contiguous) items to install into the application. While it is possible to use list boxes for selecting attributes, it would be awkward to use a list box to select multiple-text attributes like underlined, italicized, etc.

Figure 1-15:Use a list to present choices when those items vary as the application runs or when users are able to edit the labels of items as they appear on the list.

1.1.2.1.2.2. Misusage

Note that a list is used for picking items only.