As in many things in interaction design, there are advantages and disadvantages to both approaches. In cases where it is desirable to allow a user to make a series of selections before committing to the action, there should be an explicit imperative control (i.e., button). In cases where users would benefit from seeing the immediate impact of their actions, and those actions are easy to undo, it is completely reasonable for the selection control to double as an imperative control.
Check boxes
The check box was one of the earliest visual control idioms invented, and it is the favorite for presenting a single, binary choice (see Figure 21-3). The check box has a strong visual affordance for clicking; it appears as a pliant area because of a mouseover highlight or a 3D “recessed” visual treatment. After a user clicks on it and sees the checkmark appear, he has learned all he needs to know to make it work at will: Click to check; click again to uncheck. The check box is simple, visual, and elegant.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 444
444
Part III: Designing Interaction Details
Figure 21-3 These are standard check boxes from Microsoft Windows (on the left) and Apple OS X (on the right). Again, the use of shading and highlights suggest dimensionality, which gives the check boxes affordance or clickability.
Notice how the Windows check boxes feature the more typical recessed look, whereas those from OS X are raised.
The check box is, however, primarily a text-based control. The check box is a familiar, effective idiom, but it has the same strengths and weaknesses as menus. Well-written text can make check boxes unambiguous. However, this exacting text forces users to slow down to read it, and takes a considerable amount of real estate.
Traditionally, check boxes are square. Users recognize visual objects by their shape, and the square check box is an important standard. There is nothing inherently good or bad about squareness; it just happens to have been the shape originally chosen and many users have already learned to recognize this shape. There is no good reason to deviate from this pattern. Don’t make them diamond-shaped or round, regardless of what the marketing or graphic arts people say.
However, it is possible to implement a more graphical approach to the check box function by expanding on the butcon. The button evolved into the butcon by replacing its text with an icon, then migrating onto the toolbar. Once there, the metamorphosis of the button continued by the simple expedient of allowing it to stay in the recessed — or pushed-in — state when clicked, then returning to the raised aspect when it is clicked again, a latching butcon or toggle (see Figure 21-4).
The state of the toggle is no longer momentary, but rather locks in place until it is clicked again. The character of the control has changed sufficiently to move it into an entirely different category: from imperative to selection control.
Figure 21-4 These images depict toggle butcons in their flat, mouseover, clicked, and selected states in Microsoft Office 2003.
The toggle button is widely superseding the check box as a single-selection idiom and is especially appropriate in modeless interactions that do not require interruption of a user’s flow to make a decision. Latching butcons are more space efficient than check boxes are: They are smaller because they can rely on visual recognition
27_084113 ch21.qxp 4/3/07 6:10 PM Page 445
Chapter 21: Controls
445
instead of text labels to indicate their purpose. Of course, this means that they exhibit the same problem as imperative butcons: the inscrutability of the icon. We are saved once again by ToolTips. Those tiny, pop-up windows give us just enough text to disambiguate the butcon without permanently consuming too many pixels.
Flip-flop buttons: A selection idiom to avoid
Flip-flop buttons are an all-too-common control variant used to save interface real estate. Unfortunately, this savings comes at the cost of considerable user confusion.
The verb on the flip-flop button is always one of multiple states that the control can be in. A classic example here is collapsing play and pause onto the same button on an audio player, where it contains the universal play triangle icon until you click it, and then it contains the universal pause icon of two vertical bars.
The control suggests that you can click it, so when it displays the play icon it intends to mean that by clicking it music will start. The button then changes to display the pause icon to indicate that clicking it again will pause playback. The problem with this approach is that the control could be interpreted to serve as an indicator of the state of the player (paused or playing). This means that there are two very reasonable and contradictory interpretations of the icons on the button. The control can either serve as a state indicator or as a state-switching selection control, but not both (see Figure 21-5).
The solution to this one is to either spell it out on the button as a verb or verb phrase — Play or Pause — or better yet, to use some other technique entirely, such as replacing it with two buttons. The downside is that this consumes more screen real estate.
ON
click
OFF
The control
The control
is now in the
is now in the
OFF state
ON state
Figure 21-5 Flip-flop button controls are very efficient. They save space by controlling two mutually exclusive options with a single control. The problem with flip-flop controls is that they fail to fulfill the second duty of every control — to inform users of their current state. If the button says ON when the state is off, it is unclear what the setting is. If it says OFF when the state is off, however, where is the ON button? Don’t use them.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 446
446
Part III: Designing Interaction Details
Radio buttons
Similar in appearance to the check box is the radio button (see Figure 21-6). The name says it all. When radios were first put in automobiles, we all discovered that manually tuning an analog radio with a rotating knob while driving was dangerous to your health. So automotive radios were offered with a newfangled panel consisting of a half-dozen chrome-plated buttons, each of which would twist the tuner to a preset station. Now you could tune to your favorite station, without taking your eyes off of the road, just by pushing a button. The idiom is a powerful one, and it still has many practical uses in interaction design.
Figure 21-6 The image on the left shows radio buttons from Microsoft Windows XP. On the right are radio buttons from Macintosh OS X.
The behavior of radio buttons is mutually exclusive, which means that when one option is selected, the previously selected option automatically deselects. Only one button can be selected at a time.
In consequence of mutual exclusion, radio buttons always come in groups of two or more, and one radio button in each group is always selected. A single radio button is undefined — it must act like a check box instead. (You should use a check box or similar nonmutual selection control in this instance.)
Radio buttons can consume even more screen real estate than check boxes. They use the same amount of space as check boxes, but radio buttons are only meaningful in groups, so their use of space is always multiplied. In some cases, the space is justified, particularly where it is important to show users the full set of available choices at all times. Radio buttons are well suited to a teaching role, which means that they can be justified in infrequently used dialog boxes, but drop-down list boxes are often a better choice on the surface of a sovereign application which must cater to daily users.
For the same reason that check boxes are traditionally square — that’s how we’ve always done it — radio buttons are round (except in the case of Motif, where radio buttons were diamonds, but this seems not to have caught on).
As you might imagine, the butcon has also done to the radio button what it did to the check box: replaced it on the surface of an application. If two or more latching butc
ons are grouped together and mux-linked — so that only one of them at a time can be latched — they behave in exactly the same way as radio buttons. They form a radio butcon.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 447
Chapter 21: Controls
447
They work just like radio buttons: One is always selected — latched down — and whenever another one is pressed, the first one returns to its normal — raised —
position. The alignment controls on Word’s toolbar are an excellent example of a radio butcon, as shown in Figure 21-7.
Figure 21-7 Word’s alignment controls are a radio butcon group, acting like radio buttons. One is always selected, and when another is clicked, the first one returns to its normal, raised position. This variant is a very space-conservative idiom that is well suited for frequently used options.
Just as in all butcon idioms, these are very efficient consumers of space, letting experienced users rely on pattern recognition to identify them and letting infrequent users rely on ToolTips to remind users of their purpose. First-time users will either be clever enough to learn from the ToolTips or will learn more slowly, but just as reliably, from other, parallel, pedagogic command vectors.
Combutcons
A variant of the radio butcon is a drop-down version. Because of its similarity to the combo box control, we call this a combutcon (see Figure 21-8). Normally, it looks like a single butcon with a small down-arrow to its right (in Windows), but if you click the arrow, it drops down a menu of several butcons, which users may choose among. The selected butcon now appears on the toolbar next to the arrow.
Clicking on the butcon itself actuates the imperative indicated by the selected state.
Like menus, the butcons should also activate if the user clicks and holds on the arrow, drags and then releases over the desired selection.
Figure 21-8 This combutcon from Microsoft Office 2003 is a group of latching butcons that behave like a combo box.
Variations on combutcons include drawing a small, downward- or right-pointing triangle in the lower-right corner of the combutcon icon in place of the separate down arrow that is seen in Microsoft toolbars. Adobe products make use of this variant in their palette controls; this variant also requires a click and hold on the
27_084113 ch21.qxp 4/3/07 6:10 PM Page 448
448
Part III: Designing Interaction Details
butcon itself to bring up the menu (which, in Adobe palette controls, unfolds to the right rather than down, as shown in Figure 21-9). You can vary this idiom quite a bit, and creative software designers are doing just that in the never-ending bid to cram more functions onto screens that are always too small.
You can see a Microsoft variant in Word, where the butcon for specifying the colors of highlights and text show combutcon menus that look more like little palettes than stacks of butcons. As you can see from Figure 21-9, these menus can pack a lot of power and information into a very compact control. This facility is definitely for frequent users, particularly mouse-heavy users, and not at all for first-timers. However, for a user who has at least a basic familiarity with the available tools, the idiom is instantly clear after it is discovered or demonstrated. This is an excellent control idiom for sovereign-posture programs with which users interact for long hours. It demands sufficient manual dexterity to work a menu with relatively small targets, but it is much faster than going to the menu bar, pulling down a menu, selecting an item, waiting for the dialog box to deploy, selecting a color on the dialog box, and then clicking the OK button.
Figure 21-9 These combutcons taken from Adobe Photoshop (left) and Mozilla Firefox (right) show the diversity of applications of the idiom. In Photoshop, the combutcon is used to switch between various modal cursor tools, whereas in Firefox it is used to select a previously visited Web page to return to. In the first example, it is used to configure the user interface, whereas in the second it is used to perform an action.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 449
Chapter 21: Controls
449
List controls
List controls allow users to select from a finite set of text strings, each representing a command, object, or attribute. These controls are sometimes called picklists because they offer lists of items from which the user can pick a selection; they are also known as list boxes or listviews, depending on which platform and which control variant you are talking about. Like radio buttons, list controls are powerful tools for simplifying interaction because they eliminate the possibility of making an invalid selection.
List controls are small text areas with a vertical scrollbar on the right-hand edge (see Figure 21-9). The application displays objects as discrete lines of text in the box, and the scrollbar moves them up or down. A user can select a single line of text at a time by clicking on it. A list control variant allows multiple selection, where a user can select multiple items at one time, usually by pressing the Shift or Ctrl key while clicking with the mouse.
The drop-down is a variant of the list control. These ubiquitous controls show only the selected item in a single row, until the arrow button is pressed, which reveals other available choices (also illustrated in Figure 21-10).
Figure 21-10 On the right is a standard list control from Windows. The images on the left show a drop-down list control in its closed and open states.
Early list controls handled only text. Unfortunately, that decision often affects their behavior to this day. A list control filled with line after line of text unrelieved by visual symbols is a dry desert indeed. However, starting with Windows 95, Microsoft has allowed each line of text in a listview control to be preceded with an icon (without need of custom coding). This can be quite useful — there are many situations in which users benefit from seeing a graphical identifier next to important text entries (see Figure 21-11). A newer convention is to use the list items in a drop-down or other listview control as a preview facility. This is commonly used in cases where the control is doubling as a selection control and an imperative control, such as the selection of a style in Microsoft Word (also see Figure 21-11).
27_084113 ch21.qxp 4/3/07 6:10 PM Page 450
450
Part III: Designing Interaction Details
Figure 21-11 On the left is a list control with icons from Windows XP that allows users to visually identify the application they are looking for. On the right is the style drop-down list from Office 2007. Here, the items in the list provide a preview for the effects of their selection.
DESIGN
Distinguish important text items in lists with graphic icons.
principle
Listviews are, true to their name, good for displaying lists of items and allowing users to select one or more of them. They are also good idioms for providing a source of draggable items (though clearly not with the drop-down variant). If the items are draggable within the listview itself, it makes a fine tool for enabling the user to put items in a specific order (see the “Ordering lists” section later in this chapter).
Earmarking
Generally speaking, users select items in a list control as input to some function, such as selecting the name of a desired font from a list of several available fonts.
Selection in a list control is conventional, with keyboard equivalents, focus rectangles, and selected items shown in highlighted colors.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 451
Chapter 21: Controls
451
Occasionally, however, list controls are used to select multiple items, and this can introduce complications. The selection idiom in list controls is very well suited for single selection but much weaker for multiple selection. In general, the multiple selection of discrete objects works adequately if the entire playing field is visible at once, like the icons on a desktop. If two or more icons are selected at the same time, you can clearly see this because all the icons are visible.
But if the pool of available discrete
items is too large to fit in a single view and some of it must be scrolled offscreen, the selection idiom immediately becomes unwieldy. This is the normal state of affairs for list controls. Their standard mode of selection is mutual exclusion, so when you select one thing, the previous selected thing is deselected. It is thus far too easy, in the case of multiple selection, for users to select an item, scroll it into invisibility, and then select a second item, forgetting that they have now deselected the first item because they can no longer see it.
The alternative is equally unpalatable: The list control is programmed to disable the mutual-exclusion behavior of a standard list control in its selection algorithm, allowing users to click on as many items as they like with them all remaining selected. Things now work absolutely perfectly (sort of): A user selects one item after another, and each one stays selected. The fly in the ointment is that there is no visual indication that selection is behaving differently from the norm. It is just as likely that a user will select an item, scroll it into invisibility, then spot a more desirable second item and select it expecting the first — unseen — item to automatically be deselected because the control is mutually exclusive. You get to choose between offending the first half of your users or the second half. Bad idea.
When objects can scroll off the screen, multiple selection requires a better, more distinct idiom. The correct action is to use a different idiom from simple selection, one that is visually distinct. But what is it?
It just so happens we already have another well-established idiom to indicate that something is selected — the check box. Check boxes communicate their purposes and their settings quite clearly and, like all good idioms, are extremely easy to learn.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 60