Check boxes are also very clearly disassociated from any hint of mutual exclusion.
If we were to add a check box to every item in our problematic list control, the user would not only clearly see which items were selected and which were not, he would also clearly see that the items were not mux-linked, solving both of our problems in one stroke. This check box alternative to multiple selection is called earmarking, an example of which is shown in Figure 21-12.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 452
452
Part III: Designing Interaction Details
Figure 21-12 Selection is normally a mutually exclusive operation. When the need arises to discard mutual exclusivity in order to provide multiple selection, things can become confusing if some of the items can be scrolled out of sight.
Earmarking is a solution to this. Put check boxes next to each text item and use them instead of selection to indicate the user’s choices. Check boxes are a clearly non–mutually exclusive idiom and a very familiar GUI idiom. Users grasp the workings of this idiom right away.
Dragging and dropping from lists
List controls can be treated as palettes of goodies to use in a direct-manipulation idiom. If the list were part of a report-writing program, for example, you could click on an entry and drag it to the surface of the report to add a column representing that field. It’s not selection in the usual sense, because it is a completely captive operation. Without a doubt, many programs would benefit if they made use of list controls that supported dragging and dropping.
Such draggable items can help users gather items into a set. Providing two adjacent list controls, one showing available items and the other showing chosen items, is a common GUI idiom. One or sometimes a bidirectional pair of buttons placed between them allows items to be selected and transferred from one box to the other, as shown in Figure 21-13. It is so much more pleasant when the idiom is buttressed with the capability to just click and drag the desired item from one box to another without having to go through the intermediate steps of selection and function invocation.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 453
Chapter 21: Controls
453
Figure 21–13 This dialog from Microsoft Outlook Express would benefit from the capability to drag a contact from the list at the left into the To, Cc, and Bcc lists at the right. Also notice the unfortunate use of horizontal scrollbars in all list fields.
In the left-hand field, in particular, ToolTips could show the full row of information in the left-hand box. (Alternately, the dialog could be expanded. There’s no practical reason to limit it to this size.)
Ordering lists
Sometimes the need arises to drag an item from a list control to another position in the same list control. (Actually, this need arises far more often than most interaction designers seem to think.) Many programs offer automatic sort facilities for important lists. Windows Explorer, for example, allows sorting files by name, by type, by modification date, and by size. That’s nice, but wouldn’t it be even better if users could order them by importance? Algorithmically, the program could order them by frequency of user access, but that won’t always get the right results. Adding in a factor of how recently files were accessed, as well, would get closer but still wouldn’t be exactly right. (Microsoft does this with its font picker in some applications, and it works pretty well for this purpose.) Why not let users move what’s important to them to a region at the top, and sort those things separately (in alphabetical or whatever order), in addition to sorting the full directory below? For example, you might want to rearrange a list of the people in your department in descending order by where they sit. There is no automatic function that will do this;
27_084113 ch21.qxp 4/3/07 6:10 PM Page 454
454
Part III: Designing Interaction Details
you just have to drag them until it’s right. Now, this is the kind of customizing that an experienced user wants to do after long hours of familiarization with an application. It takes a lot of effort to fine-tune a directory like this, and the program must remember the exact settings from session to session — otherwise, the capability to reorder things is worthless.
Being able to drag items from one place to another in a list control is powerful, but it demands that auto-scrolling be implemented (see Chapter 19). If you pick up an item in the list but the place you need to drop it is currently scrolled out of view, you must be able to scroll the listview without putting down the dragged object.
Horizontal scrolling
List controls normally have a vertical scrollbar for moving up and down through the list. List controls can also be made to scroll horizontally. This feature allows the programmer to put extra-long text into the list controls with a minimum of effort.
However, it offers nothing to users but a major pain.
Scrolling text horizontally is a terrible thing, and it should never, ever be done, except in large tables such as spreadsheets where locked row and column headers can provide context for each column. When a text list is scrolled horizontally, it hides from view one or more of the first letters of every single line of text showing.
This makes none of the lines readable and the continuity of the text is utterly destroyed.
DESIGN
Never scroll text horizontally.
principle
If you find a situation that seems to call for horizontal scrolling of text, search for alternative solutions. Begin by asking yourself why the text in your list is so long.
Can you shorten the entries? Can you wrap the text to the next line to avoid that horizontal length? Can you allow the user to enter aliases for the longer entries?
Can you use graphical entries instead? Can you use ToolTips? Ideally, you should alternatively be asking yourself if there is some way to widen the control. Can you rearrange things on the window or dialog to expand horizontally?
Absent the ability to widen the control, the best answer will usually be to wrap the text onto the next line, indenting it so it is visually different from other entries. This means that you now have a list control with items of variable height, but this is still better than horizontal scrolling.
Remember, we’re just talking about text. For graphics or large tables, there is nothing wrong with horizontal scrollbars or horizontally scrollable windows in general.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 455
Chapter 21: Controls
455
But providing a text-based list with a required horizontal scrollbar is like providing a computer with a required pedal-powered electrical generator — bad news.
Entering data into a list
Little work has been done historically to enable users to make direct text entry into an item in a list control. Of course, the need to enter text where text is output is widespread, and much of the kludginess of dialog box design can be directly attributed to programmers trying to dodge the bullet of having to write edit-in-place code.
However, modern list and tree controls in Windows and other platforms offer an edit-in-place facility. Windows Explorer uses both of these controls, and you can see how they work by renaming a file or directory. To rename a file in the Mac OS
or in Windows 95, you click twice — but not too quickly (lest it be interpreted as a double-click and open the object in question) — on the desired name. You then enter whatever changes are desired. (This changed a bit in Windows XP, so that in some views you need to select Rename from a right-click menu to get into Rename mode — is this progress?) Items that are editable in other circumstances should, when displayed in list controls, be editable there as well.
The edge case that makes edit-in-place a real problem is adding a new entry to the list. Most designers use other idioms to add list items: Click a button or select a menu item and a new, blank entry is added to the list and the user can then edit-in-place its name. It would be more sensible if you could, say, double-click in the space b
etween existing entries to create a new, blank entry right there, or at least have a perpetual open space at the beginning or end of the list with a Click to Add Entry label on it to make it discoverable. Another solution to this problem is the combo box, which we’ll talk about next.
Combo boxes
Windows 3.0 introduced a new control called the combo box. It is — as its name suggests — a combination of a list box and an edit field (see Figure 21-14). It provides an unambiguous method of data entry into a list control. As with normal list boxes, there is a drop-down variant that has a reduced impact on screen real estate.
Combo boxes clearly differentiate between the text-entry part and the list-selection part, minimizing user confusion. For single selection, the combo box is a superb control. The edit field can be used to enter new items, and it also shows the current selection in the list. When the current selection is showing in the edit field, a user can edit it there — sort of a poor man’s edit-in-place.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 456
456
Part III: Designing Interaction Details
Figure 21-14 The Word font selection drop-down combo box allows users to make a font selection from the drop-down list, or to simply type the name of the desired font into the text field.
Because the edit field of the combo box shows the current selection, the combo box is by nature a single-selection control. There is no such thing as a multiple-selection combo box. Single selection implies mutual exclusion, which is one of the reasons why the combo box is fast replacing groups of radio buttons for selection amongst mutually exclusive options. (The Mac OS had pop-up menus before Windows had the combo box, and these served to replace large banks of radio buttons on that platform. The Mac versions didn’t have the combo box’s edit feature, however.) The other reasons include its space efficiency and its capability to add items dynamically, something that radio buttons cannot do.
When the drop-down variants of the combo box are used, the control shows the current selection without consuming space to show the list of choices. Essentially, it becomes a list-on-demand, much like a menu provides a list of immediate commands on demand. A combo box is a pop-up list control.
The screen efficiency of the drop-down combo box allows it to do something remarkable for a control of such complexity: It can reasonably reside permanently on a program’s main screen. It can even fit comfortably on a toolbar. It is a very effective control for deployment on a sovereign-posture application. Using combo boxes on the toolbar is more effective than putting the equivalent functions on menus, because the combo boxes display their current selection without requiring any action on the user’s part, such as pulling down a menu to see the current status.
If drag-and-drop is implemented in list controls, it should also be implemented in combo boxes. For example, being able to open a combo box, scroll to a choice, and then drag the choice onto a document under construction is a very powerful idiom.
Drag-and-drop functionality should be a standard part of combo boxes.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 457
Chapter 21: Controls
457
Tree controls
Mac OS 7 and Windows 95 both brought us general-purpose tree controls, which had already been in use in the Unix world for some time. Tree controls are listviews that can present hierarchical data. They display a sideways tree, with icons for each entry.
The entries can be expanded or collapsed the way that many outline processors work.
Programmers tend to like this presentation. It is often used as a file system navigator, and is a highly effective way to present inherently hierarchical information.
Unfortunately, hierarchical trees are one of the most inappropriately used controls in the toolbox. They can be highly problematic for users; many people have difficulty thinking in terms of hierarchical data structures. We have seen countless interfaces where programmers have forced nonhierarchical data into a tree control with the rationale that trees are “intuitive.” While they certainly are intuitive for programmers (and other people are certainly becoming more accustomed to them), the big problem is that they do not allow users to capitalize on other, more interesting relationships between objects other than a strict hierarchy.
In general, it only makes sense to use a treeview (no matter how tempting it may be) in the case where what is being represented is “naturally” thought of as a hierarchy (such as a family tree). Using a treeview to represent arbitrary objects organized in an arbitrary fashion at the whim of a programmer is asking for big trouble when it comes to usability.
Entry Controls
Entry controls enable users to enter new information into an application, rather than merely selecting information from an existing list.
The most basic entry control is a text edit field. Like selection controls, entry controls represent nouns to the program. Because a combo box contains an edit field, some combo box variants qualify as entry controls, too. Also, any control that lets users enter a numeric value is an entry control. Controls such as spinners, gauges, sliders, and knobs fit in this category.
Bounded and unbounded entry controls
Any control that restricts the available set of values that a user can enter is a bounded entry control. A slider that moves from 1 to 100, for example, is bounded.
Regardless of a user’s actions, no number outside those specified by the program can be entered with a bounded control. It is thus impossible for users to enter an invalid value with bounded entry controls.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 458
458
Part III: Designing Interaction Details
Conversely, a simple text field can accept any alphanumeric data a user keys into it.
This open-ended entry idiom is an example of an unbounded entry control. With an unbounded entry control, it is easy for users to enter invalid values. The program may subsequently reject it, of course, but users can still enter it.
Simply put, bounded controls should be used wherever bounded values are needed.
If the program needs a number between 7 and 35, presenting users with a control that accepts any numeric value from –1,000,000 to +1,000,000 is not doing anyone any favors. People would much rather be presented with a control that embodies 7
as its bottom limit and 35 as its upper limit (clearly indicating these limits is also useful). Users are smart, and they will immediately comprehend and respect the limits of their sandbox.
It is important to understand that we mean a quality of the entry control and not of the data. To be a bounded control, it needs to clearly communicate, preferably visually, the acceptable data boundaries to the user. A text field that rejects a user’s input after he has entered it is not a bounded control. It is simply a rude control.
DESIGN
Use bounded controls for bounded input.
principle
Most quantitative values needed by software are bounded, yet many programs allow unbounded entry with numeric fields. When a user inadvertently enters a value that the program cannot accept, the program issues an error message box. This is cruelly teasing the user with possibilities that aren’t.“What would you like for dessert? We’ve got everything,” we say. “Ice cream,” you respond. “Sorry, we don’t have any,” we say.
“How about pie?” you innocently ask. “Nope,” we say. “Cookies?” “Nope.” “Candy?”
“Nope.” “Chocolate?” “Nope.” “What, then?” you scream in anger and frustration.
“Don’t get mad,” we say indignantly. “We have plenty of fruit compote.” This is how users feel when we put up a dialog box with an unbounded edit field when the valid values are bounded. A user types 17, and we reward this innocent entry with an error message box that says “You can only enter values between 4 and 8.” This is poor user-interface design; a much better scheme is to use a bounded control that automatically limits the input to 4, 5, 6, 7, or 8. If the bounded set o
f choices is composed of text rather than numbers, you can still use a slider of some type, or a combo box, or list box. Figure 21-15 shows a bounded slider used by Microsoft in the Windows Display Settings dialog. It works like a slider or scrollbar, but has four discrete positions that represent distinct resolution settings. Microsoft could easily have used a noneditable combo box in its place, too. In many cases, a slider is a nice choice because it telegraphs the range of valid entries. A combo box isn’t much smaller but it keeps its cards hidden until clicked — a less friendly stance.
27_084113 ch21.qxp 4/3/07 6:10 PM Page 459
Chapter 21: Controls
459
Figure 21-15 A bounded control lets users enter only valid values. It does not let them enter invalid values, only to reject them when then try to move on. This figure shows a bounded slider control from the Display Settings dialog in Windows XP.
The little slider has four discrete positions. As you drag the slider from left to right, the legend underneath it changes from “800 by 600 pixels” to “1024 by 768 pixels”
to to “1280 by 1024” to “1400 by 1050 pixels.”
If a user must express a choice that requires a numeric value within specific boundaries, give her a control that intrinsically communicates those limits and prevents her from entering a value outside of the boundaries. The slider control does this.
Although sliders have significant drawbacks, they are exemplary in one area: They allow users to enter quantitative information by analogy. Sliders allow users to specify numeric values in relative terms, rather than by directly keying in a number.
That is, a user moves the sliding thumb to indicate, by its relative position, a proportional value for use inside the program. Sliders are less useful for entering precise numbers, though many programs use them for that purpose. Controls such as spinners are better for entering exact numbers.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 61