FAST Consulting

A button used to turn attributes or states on and off. Users can set any number of check boxes, including none.

Check boxes are square (radio buttons are round) and can have either text or iconic (picture) labels. The "on" setting is usually indicated by a check mark or an X inside the box. However, Motif and iconic check boxes (see Fig. 3) simply look pushed-in.

Toggling a small number of independent attributes or states on and off (Fig. 1).

Toggling one setting on and off. Use a single check box for a toggle (Fig. 2). See "Two-state toggles" below.

Use radio buttons or single-selection list boxes instead. However, see "Mixed-value states" below.

Although check boxes can be used on menus (for example, to toggle settings on and off) and in windows (for example, to toggle data points on and off on graphs), they are most common in dialog boxes, toolbars, and palettes simply because the reason that these components exist is to hold settings.

Text labels appear on the side of the button (in countries where the writing runs left to right, on the right side).

Iconic labels appear on the check box itself (Fig. 3). For more on iconic labels, see Iconic Labels.

Every check box is a toggle—the setting is either on or off. When you have a group of check boxes, you have a group of independent and mutually inclusive toggles.

When you have a single-button toggle, on the other hand, you are taking advantage of the fact that a check box’s two states or settings are mutually exclusive—either yes or no, on or off—in a Boolean sort of way. For example:

What is the opposite of full duplex? To the uninitiated, probably empty duplex (or a single-floor apartment, depending on the context). For modem connections, however, the right answer is half duplex.

One solution is to change the label depending on the setting, but that becomes confusing for two reasons (Microsoft 1995a, 138):

It’s confusing to describe, and worse to specify and program. Here are some better ideas:

The rule is, if the box is checked (true), then the answer to the question (actual or implied) is yes. Otherwise, the answer is no.

Therefore, to avoid double negatives when the boxes are empty, always label the buttons with positive statements. For example, "Disable sound card" means, if unchecked, "Don’t disable sound card," which really means, "Do enable sound card." Eliminate the negative dis- and use "Enable sound card."

As mentioned in "Do Not Use For" above, avoid three-state buttons (Yes, No, Doesn’t Matter, for example). Since users have little or no experience with three-state buttons, they either won’t notice the different states or won’t know what to do with them if they do notice the differences. Radio buttons or list boxes are better choices.

However, the Microsoft guidelines allow a mixed-value toggle when it reflects rather than sets an actual user choice. For example, say that you’ve selected an entire paragraph, some of which is roman, some of which is italic, and some of which is bold. If you then open a font palette containing check boxes, the italic and bold check boxes show a gray "mixed value" state, as in Fig. 4. If you click italic once, italic is turned on for the entire selection, which is indicated by an X or check mark in the box. If you click twice, italic is turned off for the entire selection and you see an empty check box. If you click three times, the value returns to the mixed state (Microsoft 1995a, 148-149).

If a mixed-value toggle is important to your application, test it on users. They may not notice the change in values or, if they notice it, they may not understand it. If you do identify difficulties and you can’t eliminate them, you might want to add a note right on the interface or in a tooltip. Also flag the issue in your "getting started" documentation and online help.

If the settings are related: Unless you have a lot of spare room on the screen, switch to a multiple-selection list box when you get to about seven check boxes.

If the settings are visual (colors on a palette for example): Use as many check boxes as you need, but group them into categories or some natural order (the spectrum, for example). See List Box, Multiple Selection for more information on categorization styles.

If you have a long list of toggle check boxes: Try to break them into chunks of five or so buttons, or divide them in some natural way among tabbed dialog boxes.

If you have an international audience, watch out for terminology problems. Carl Zetie points out that "in British English, we ‘tick’ a box, we don’t ‘check it.’" If the documentation says "Check the Italic button," instead of clicking it, your international users may look to see if the button is there. He adds that, in many cultures, X means "wrong" and is used to cross something out, not to select it. Use checkmarks (ü ) rather than Xs as the selection cue (Zetie 1996, 164).

Alternatives to "check" are "click on" and "click off," or "select" and "unselect."

For groups of check boxes, test that the labels (text or icon) make sense to users. You can use a paper and pencil test in early iterations.

Also test that the groupings make sense. Ask your participants to categorize the buttons themselves, and use the groupings for which there is agreement. In complex systems, however, make sure that you use expert participants. Subject-matter experts and novices may have different conceptual models, and you need to match the expert model.

A combination of a list box and a text-entry area. The list box allows only single selections. The text-entry area has two functions: searching and data-entry. Depending on the type of combo box, the text-entry area may simply show whatever item was selected from the drop-down list, let users type in search items, or let them add new entries to a database.

Combo box

Fig. 5. A drop-down list box, one of the three types of combo boxes.

Design guidelines:

Visual Basic and other development packages offer three styles of combo boxes: Simple, drop-down combo, and drop-down list. Users can add new items to the simple or drop-down combo boxes, but not to a drop-down list. Users can search all three types by typing the search item in the entry area.

The simple combo box (Fig. 6) is an entry area with a list below it. Use this style whenever you have enough space—being able to see the list items is always good.

The drop-down combo box (Fig. 7) is an entry area with a down-arrow button to its right. Use this style when space is limited—for example, on a toolbar. Note that, in Windows 3.x (but not in Windows 95), the down arrow is separated from the entry area by a space to distinguish it from a drop-down list box, described below. This cue may be too subtle for all but the most detail-oriented users. On the other hand, it does no harm.

Fig. 7. The drop-down combo box. Note the space between the entry area and the arrow button—
it indicates that the control is a combo box rather than a drop-down list.

The drop-down list box (Fig. 8) looks the same as a drop-down combo box except that there is no space between the entry area and the arrow button. It acts differently, however: Users cannot enter new items. They can only select from the items already on the list. See Drop-Down List Box for details.

Fig. 8. The drop-down list box. There is no space between the entry area and the arrow button.

The text-entry area of a combo box has two functions: searching and data-entry. The search (or "jump-ahead") feature is useful when the list is very long and scrolling takes too much time. Users can search for items on the list by typing one character (Fig. 9 and Fig. 10), or more than one if the combo box is set up to do progressive searching (Fig. 11 and Fig. 12).

Combo box

Fig. 9. In one-character searches, pressing "S" goes to the first S item.

Combo box

Fig. 10. Then pressing "T" goes to the first T item. Suitable for short lists with few similar items.

Combo box

Fig. 11. In progressive searches, pressing "S" also goes to the first S item.

Combo box

Fig. 12. Then pressing "T" goes to the first ST item.
Use with long lists or lists in which many of the items start with the same first letter.

Once the item is highlighted, the user can select it. The item is then displayed in the entry area.

Use progressive searching for long lists with many similar items (in a progressive search, typing C+A+T finds "Cat"). Another style of progressive search lets users step through a set of items that all have the same first letter (N+N+N finds "Nebraska," "New Jersey," and then "New York"). This style is also useful for long lists.

Use single-letter searching only for short lists (C finds "cat," A finds "apple," and T finds "tamarind").

Data Entry

A general usability rule is: Don’t force users to pick items from a fixed list if the list is incomplete. Aside from the frustration this creates, if your users don’t have the information they need, they may pick any item and thereby invalidate your data-collection efforts.

For example, if your program insists that every client entry have an SIC code (standard industrial classification), but SIC codes are often missing from the source material, typists who are under pressure to enter hundreds of records a day are not going to look up the client company and find its SIC code. They are going to pick the first code on the list or pick codes at random, just to get through the record.

Instead of creating situations in which users are forced to pick incorrect items, let them enter new codes. However, keep in mind that if you let users enter new items, they may enter misspellings or synonyms for items that already exist elsewhere on the list. Whether you can let users enter wrong information depends on the results of your task analysis:

As Carl Zetie says, "One of the major conflicts in any application is balancing freedom against constraint. Free taskflow allows the user to work as he finds best. Constrained taskflow guides the user to a successful conclusion" (1995, 91). For a detailed discussion of methods for handling constraints, see Zetie’s chapter 3, "Taskflow."

Size of the list

First, make sure you can do what you want to do. Your development package (or other considerations) may restrict the number of items on the list. Check your specifications against your tools before committing yourself to a combo box (or any type of list box). For example, say you want to create a combo box for ZIP codes (a good idea because the U.S. Post Office does add ZIP codes occasionally). If your development kit only lets you create 100-item lists, you can’t use a combo box for ZIP codes.

Second, figure out where you want to set the trade-off between ease of use and available real estate. Research and experience indicates that the more options you can display at once, the more quickly users will select the correct item. Having to click the drop-down arrow and scroll through the list slows users down. However, the combo box’s search options can mitigate some of these delays.

In general, the part of the list that users see should be about seven items long. Go to 10 or even 20 items if the entire list is long—a longer list may prevent users from closing the list box by mistake, because they won’t be scrolling as much and therefore won’t make a slip of the mouse (Leavens 1994, 287).

Make sure that all items can be viewed horizontally. If you can’t make the entry area or the list as wide as the widest item on the list, make it at least as wide as the average item. Then include a horizontal scroll bar, make the width of the list dynamic, or show the entire list item when the user touches it with the mouse (like tool tips). Too many file-name list boxes (for example) are so narrow that they show only the first part of the path names and never the file names. These lists are, therefore, utterly useless.

If your application may ever be internationalized, keep in mind that items will expand. Design for automatic text expansion wherever you can. See Label for information on rates of expansion between languages.

Make sure that users know that they can type in the box as well as select from the list of options. If you find that this feature is not apparent, highlight it in your "getting started" documentation and online help.

Providing shortcuts for expert or professional users, especially in programming, spreadsheets, and financial applications (Fig. 14). Typing can be faster for experienced users.

Excel

Fig. 14. The command line in Excel is the third area from the top, where the statement "A1+A2+A3" appears.

Supporting already defined DOS and UNIX batch files or scripts that perform repetitive or customized work. Customers are usually not willing to give up their script files (unless you are willing to rewrite them as GUI macros).

Inexperienced or occasional users because expert use depends on memorization, which generally requires long-term familiarity.

Design guidelines:

One of the benefits of GUIs is visibility: All available actions, for example, are made visible in the menus. In the same way that recognition is more effective than recall (memorization), GUIs, which show users all choices rather than make them try to remember a command, are more effective than command-line interfaces. If there is no way to access an operation other than recall, you cannot count on most users to remember all the options.

Menus also give new users an intellectual advantage. Test participants who are taught to use the menus first and commands second, "fared better in their overall knowledge of the functionality of the system. Participants in the command language condition learned only a limited number of task-specific functions" (Norman 1991, 317-318). In other words, although a command line is a good tool, use it in addition to¾ not as a replacement for¾ menu access.

When to keep or add a command line

There are certain users for whom command-line interfaces are suitable. Consider including (or retaining) a command line when:

Fig. 15. The askSam command line appears below the formatting toolbar (under "Times New Roman").

When askSam Systems ported askSam, a text database program, from DOS to Windows, the company retained the command line. According to Phil Schnyder, president of askSam Systems, "In askSam, you can search for any word by pressing one key to get into the command line, typing the word, and pressing Enter. I've tried other databases¾ you can put information in theirs just as quickly as ours, but to get it out, you had to go through too many dialog boxes." (We asked Schnyder if askSam's long-time DOS users still used the command line to start programs or access commands. "Not really," he said. "You get tired of typing in the commands. It's easier to use the menus than the command line for the programs.")

Analyze users carefully

Good deployment of GUI command lines requires in-depth user analysis. It isn’t enough to say, "Well, our audience is UNIX system administrators and they really like command lines. So we won’t bother about adding menus." The problem is that, even if your audience is truly restricted to UNIX system administrators,

Also, in spite of your expectations, your audience may not be homogenous. End-users start picking up shortcuts from the local gurus, and suddenly everyone is mucking around in the guts of the application and needing more support than you expected.

The solution is to find out which operations are most likely to be used often and define command-line shortcuts for those operations. Less popular operations should be added to a menu system, bundled together into macros or wizards, or described in detail in a readily accessible help system. (Make sure that the help system contains an index with lots of synonyms for the various operations.)

Note that some applications offer command-line functionality that is not available through the GUI, says Steven Feldberg. "Typically, however, these are systems that suffered the grafting of a GUI onto a prior, command-driven interface. [But other types of] examples abound, such as Access (or pretty much any database product) that allows you to put inline commands from the ‘Application Development Language’ into the command line. Another example is searching via command lines which often allows for complex Boolean expressions that cannot be constructed via the GUI" (Feldberg, 1997).

It is probably a mistake to have hidden functionality, but sometimes it can’t be helped. For example, existing users may want to be able to use old commands, but since you don’t want to support the old functionality for new users, you don’t document it; a function is new and untested, but it’s so cool you want the digerati to try it anyway, so you mention it at a user’s group meeting; your application has both end-user functionality and a behind-the-scenes application programming interface (API). Sometimes these disjunctions are resolved by time—in other words, the old users die off, the hidden functionality becomes public, the technical writing department writes a separate API manual, thereby letting your company package the end-user and programmer versions separately. Nevertheless, for both usability and support reasons, it is best to push the process along as quickly as possible.

Where to put a command line

The Motif guidelines suggest putting the command line at the bottom of the window or, if the window also has a message area, just above the message area (OSF 1993, 6-12- 6-13).

Windows 3.x and Windows 95 systems have Run options on File (3.x) and the Startup (95) menus.

Spreadsheets put the command line below the toolbars, to the right or middle of the window, and above the cells.

Commercial financial applications seem to put command lines at the top left just below the menubar.

If there is any question about the right location, test the various possibilities on users.

If appropriate, test whether users refer to the commands the same way you do—for example, if you create a delete command, do the users lean toward RM, DEL, ERASE, or CUT? If there is no clear-cut winner, set up aliases for the top three or four.

Also check the use of punctuation. For example, how do your users indicate a Boolean AND on a search command line?

Rank the styles and make sure your program treats the most common ones as synonyms. (The simplest way to do this is to make copies of the commands and use all the synonyms as the names of the copies. For example, in a DOS batch system, you could copy DEL.BAT to RM.BAT, CUT.BAT, and so on.)

Note: BLACK + WHITE may seem really wrong to you, but if users use +, and + isn’t used for anything else in the system, you should consider using it as a synonym. However, if it is used elsewhere and you can tell that the command-line entry is not mathematical, display an error message and teach the user something helpful about the system.

A character that visually indicates the point at which the user’s next action will occur. (Note that there are audio as well as visual cursors.)

cursor

Fig. 16. The lasso is the selection cursor; the outline
is the selected area. (Cursor from CorelDraw.)

Text cursors come with the operating system and in development kits; they do not have to be designed.

A selection cursor is a more of a visual effect than a cursor. It indicates the location at which the next keyboard event will occur.

Since a cursor is a form of feedback, the only design issues are whether the user can spot the cursor and whether the cursor gets in the way of the user’s action.

If you have designed your own cursor or have modified the system’s text cursor in some way, observe users carefully to make sure that:

Most platforms let users change standard cursor shapes and sizes at the operating-system level. You might want to add this functionality to your own cursors as well.