Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)

by About Face 3- The Essentials of Interaction Design (pdf)

  Mobile phones and other small-screened devices (such as blood glucose meters) are typically even a generation behind drop-down menus and provide interaction idioms much in the vein of the sequential hierarchical menu (which you’ll recall from earlier in the chapter). When designing for such a platform, you have little to work with, so every decision really counts. In applications where choices are mapped to the numeric keypad (and some choices may be relegated to the “More”

  submenu), it is of utmost importance to make sure the most frequently used functions are mapped to the number keys. Similarly, the sequence of functions should provide both cognitive guidance (by locating similar functions next to each other) and the most commonly used functions at the top of the list.

  Notes

  1. Mitchell, J., & Shniederman, B., 1989

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 493

  23

  Toolbars

  Ubiquitous, toolbars are actually a relatively recent GUI development. Unlike so many GUI idioms that were popularized on the Apple Macintosh, Microsoft was the first to introduce these to mainstream user interfaces. An important complement to a menu system, the toolbar has proven to be an effective mechanism for providing persistent, direct access to functions. Whereas menus are complete toolsets with the main purpose of teaching, toolbars are for frequently used commands and offer little help to new users.

  In this chapter, we’ll discuss the merits and shortcomings of the toolbar command idiom. We’ll also talk about ToolTips and toolbar variants such as the ribbon.

  Toolbars: Visible, Immediate

  Commands

  The typical toolbar is a collection of butcons (icons that serve as buttons), usually without text labels, in a horizontal slab positioned directly below the menu bar or in a vertical slab attached to the side of the main window (see Figure 23-1). Essentially, a toolbar is a single row (or column) of visible, immediate, graphical, functions.

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 494

  494

  Part III: Designing Interaction Details

  Figure 23-1 This image shows the Standard and Formatting toolbars in Microsoft Word 2003. Notice how the toolbar is made up of butcons without static hinting, rather than buttons. This saves space and improves readability.

  Great ideas in user-interface design often seem to spring from many sources simultaneously. The toolbar is no exception. It appeared on many programs at about the same time, and nobody can say who invented it first. What is clear is that its advantages were immediately apparent to all. In a stroke, the invention of the toolbar solved the problems of the pull-down menu. Toolbar functions are always plainly visible, and users can trigger them with a single mouse click.

  Toolbars versus Menus

  Toolbars are often thought of as just a speedy version of the menu. The similarities are hard to avoid: They offer access to the program’s functions, and they usually form a horizontal row across the top of the screen. It seems that some designers imagine that toolbars, beyond being a command vector in parallel to menus, are an identical command vector to menus. They think that the functions available on toolbars should be the same as those available on menus.

  In fact, in many cases, toolbars should serve a different purpose than menus do.

  Toolbars and their controls should be designed to provide immediate access to functions frequently accessed by users who are already familiar with the application’s basics. Because of their concise nature, toolbars are typically not an ideal way for beginners to understand an application’s capabilities and operation (though ToolTips alleviate this to some extent). Menus provide a much more comprehensive and descriptive view of an application, and are often more appropriate as the pedagogic vector for beginners.

  Toolbars provide experienced users fast access to frequently used DESIGN

  principle

  functions.

  The great strength of menus is their completeness and verbosity. Everything a user needs can be found somewhere on the program’s menus. Of course, this very richness means that menus can get big and cumbersome. To avoid consuming too many pixels, these big menus have to be folded away most of the time and only popped-up on request. The act of popping up excludes menus from the ranks of

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 495

  Chapter 23: Toolbars

  495

  visible and immediate commands. The trade-off with menus is thoroughness and power in exchange for a small but uniform dose of clunkiness applied at every step.

  The butcons on toolbars, on the other hand, are incomplete and inscrutable; but they are undeniably visible, immediate, and very space-efficient compared to menus.

  Toolbars and Toolbar Controls

  The toolbar gave birth to the butcon, a happy marriage between a button and an icon. As a visual mnemonic of a function, butcons are excellent. They can be hard for newcomers to interpret, but then, they’re not for newcomers.

  Icons versus text on toolbars

  If the butcons on a toolbar act the same as the items on a drop-down menu, why are the menu items almost always shown with text and the toolbar buttons almost always shown with little images? There are good reasons for the difference, although we almost certainly stumbled on them accidentally.

  Text labels, like those on menus, can be very precise and clear — they aren’t always, but precision and clarity is their basic purpose. To achieve this, they demand that a user take the time to focus on them and read them. As we discussed in Chapter 14, reading is slower and more difficult than recognizing images. In their pedagogic role, menus must offer precision and clarity — a teacher who isn’t precise and clear is a bad teacher. Taking the extra time and effort is a reasonable trade-off in order to teach.

  On the other hand, well-designed pictorial symbols are easy for humans to recognize, but they often lack the precision and clarity of text. Pictographs can be ambiguous until you learn their meaning. However, once you learn it, you don’t easily forget it, and your recognition remains lightning fast (whereas you still have to read the text every time).

  Because toolbars are primarily for providing quick access to frequently used tools, their identifiers must elicit quick recognition from experienced users. The pictorial imagery of symbols suits that role better than text does. Butcons have the pliancy of buttons, along with the fast-recognition capability of images. They pack a lot of power into a very small space, but their great strength is also their great weakness: the icon.

  Relying on pictographs to communicate is reasonable as long as the parties have agreed in advance what the icons mean. They must do this because the meaning of

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 496

  496

  Part III: Designing Interaction Details

  an icon of any kind is by nature ambiguous until it is learned. Many designers think that they must invent visual metaphors for butcons that adequately convey meaning to first-time users. This is a Quixotic quest that not only reflects a misunderstanding of the purpose of toolbars but also reflects the futile hope for magical powers in metaphors, which we discussed in Chapter 13.

  The image on the butcon doesn’t need to teach users its purpose; it merely needs to be easily recognizable. Users should have help learning its purpose through other means. This is not to say that the designer shouldn’t strive to achieve both ends, but don’t fool yourself: It can’t be done very often. It’s a lot easier to find images that represent things than it is to find images that represent actions or relationships. A picture of a trash can, printer, or chart is somewhat easy to interpret, but it’s much more difficult to convey “apply style,” “connect,” or “convert.” And when it comes down to it, perhaps a user will find himself wondering what a picture of a printer means. It could mean “find a printer,” “change the printer’s settings,” or “report on the status of the printer.” Of course, after he learns that the little printer means

  “print one copy of the current document on
the default printer now,” he won’t have trouble with it again.

  The problem with labeling butcons

  It might seem like a good idea to label butcons with both text and images. There is not only logic to this argument but precedent, too. The original icons on the Macintosh desktop had text subtitles, as did the icon controls on some older Web browsers. Icons are useful for allowing quick classification, but beyond that, we need text to tell us exactly what the object is for.

  The problem is that using both text and images is very expensive in terms of pixels.

  Except in rare circumstances, screen space is far too valuable to use this way. Designers who choose to label their icons are trying to satisfy two groups of users with different needs: One wants to learn in a gentle, forgiving environment; the other knows where the sharp edges are but sometimes needs a brief reminder. ToolTips provide an effective way to bridge the gap between these two classes of users.

  Explaining Toolbar Controls

  The biggest problem with toolbars is that although their controls are fast and quickly memorable, they are not initially decipherable. How is a new user supposed to learn what butcons and other toolbar controls do?

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 497

  Chapter 23: Toolbars

  497

  Balloon help: A first attempt

  Apple was the first to attempt a solution with the introduction of balloon help in the System 7 OS, which provided comic-book-style speech balloons describing the purpose and operation of whatever a user’s mouse cursor passed over (this is called a fly-over, rollover, or mouseover facility).

  Despite good intentions, balloon help was ill-received. Because there was no lag between when the cursor passed over an object and when the balloon was displayed, it rendered the application largely unusable when balloon help was enabled.

  As a result, it was basically a modal help system. Users had to choose between learning about the application and using the application, and it hardly needs to be pointed out that this is not consistent with the way people learn most effectively. Of course, experienced users would usually keep balloon help off. Then, when they had to use a part of the application they weren’t familiar with, they had to go up to the Help menu, pull it down, turn balloon help on, point to the unknown object, read the balloon, go back to the menu, and turn balloon help off. What a pain.

  Needless to say, balloon help never really caught on, and developers typically created content only for the most obvious and well-known functions, ultimately undermining its usefulness. Mac OS X marked the death of balloon help in favor of a ToolTip mechanism similar to that popularized in Microsoft products.

  ToolTips

  Though not historically known for inventive user interfaces, Microsoft created a variant of balloon help called ToolTips that is one of the cleverest and most effective user-interface idioms we’ve ever seen (see Figure 23-2). At first, ToolTips may seem similar to balloon help, but on closer inspection you can see the minor physical and behavioral differences that have a huge effect from a user’s point of view.

  First of all, ToolTips have a well-timed lag that displays the helpful information only after a user has dwelled on the item for a second or so. This is just enough time for a user to point to and select the function without getting the ToolTip. This ensures that users aren’t barraged by little pop-ups as they move the mouse across the toolbar trying to do actual work. It also means that if a user forgets what a rarely used butcon is for, she only need to invest a half-second to find out.

  Figure 23-2 This ToolTip from Microsoft Word 2003 helps users who have forgotten the meaning of the icon without using a lot of real estate on text labels.

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 498

  498

  Part III: Designing Interaction Details

  ToolTips typically contain a single word or a very short phrase that describes the function. They don’t traditionally attempt to explain in prose how the object is used; they assume that you will get the rest from context. This illustrates the difference in design intent between Microsoft and Apple. Apple wanted their bubbles to teach things to first-time users. Microsoft figured that first-timers would just have to learn how things work through “F1 Help” or by reading the manual and that ToolTips would merely act as a memory jogger for frequent users.

  Super ToolTips in Microsoft Office 2007 now integrate help content into the ToolTip, in a manner very similar to balloon help. While it remains to be seen how this is received, there’s no reason why it shouldn’t be effective, provided that it doesn’t get in the way of experienced users. By taking advantage of the inherent context sensitivity of ToolTips, better integration with other help mechanisms can only serve to reduce the excise involved in learning an application.

  ToolTips make the controls on the toolbar much more accessible for intermediate users, which has allowed the toolbar to evolve beyond simply providing alternative access to menu commands. As a result, toolbars were able to take the lead as the main idiom for issuing commands to sovereign applications. This has allowed the menu to recede into the background as a command vector for beginners and for invoking advanced or occasionally used functions. The natural order of butcons as the primary idiom, with menus as a backup, makes sovereign applications much easier to use. In fact, this trajectory has continued into Microsoft Office 2007 with its Ribbon control, which replaces the menu altogether with a visually and textually expressive tabbed toolbar. We further discuss the ribbon later in this chapter.

  DESIGN

  Use ToolTips with all toolbar and iconic controls.

  principle

  Disabling toolbar controls

  Toolbar controls should become disabled if they are not applicable to the current selection. They must not offer a pliant response: The butcon must not depress, for example, and controls should also gray themselves out to make matters absolutely clear.

  Some programs make disabled toolbar controls disappear altogether, which can have undesirable effects. Users remember toolbar layouts by position. If butcons disappear, the trusted toolbar becomes a skittish, tentative idiom that scares the daylights out of new users and disorients even those more experienced.

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 499

  Chapter 23: Toolbars

  499

  Evolution of the Toolbar

  After people started to regard the toolbar as something more than just an accelerator for the menu, its growth potential became more apparent. Designers began to see that there was no reason other than habit to restrict the controls on toolbars to butcons. Soon designers began to invent new idioms expressly for the toolbar. With the advent of these new constructions, the toolbar truly came into its own as a primary control device, separate from — and in many cases superior to — menus.

  After the butcon, the next control to find a home on the toolbar was the combo box, as in Microsoft Word’s Style, Font, and Font Size controls. It is perfectly natural that these selectors be on the toolbar. They offer the same functionality as those on the drop-down menu, but they also show the current style, font, and font size as a property of the current selection. The idiom delivers more information in return for less effort by users.

  After combo boxes were admitted onto the toolbar, the precedent was set, and all kinds of idioms appeared, as we have already discussed in Chapter 21. Some of these toolbar idioms are shown in Figure 23-1.

  State-indicating toolbar controls

  This variety of controls contributed to a broadening use of the toolbar. When it first appeared, the toolbar was merely a place for fast access to frequently used functions.

  As it developed, controls on it began to reflect the state of the program’s data. Instead of a butcon that simply changed a word from plain to italic text, the butcon now began to indicate — by its state — whether the currently selected text was already italicized. The butcon not only controlled the application of the style, but it also represented the status of t
he selection with respect to the style.

  Menus on toolbars

  As the variety of controls on the toolbar grows, we find ourselves in the ironic position of adding menus to it. The Word toolbar shown in Figure 23-3 shows the Undo drop-down. Sophisticated and powerful idioms such as this are pushing the old-fashioned menu bar further into the background as a secondary command vector.

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 500

  500

  Part III: Designing Interaction Details

  Figure 23-3 Toolbars now contain drop-down menus such as the Undo menu shown here. This provides a compact way to provide powerful functionality.

  Movable toolbars

  Microsoft has done more to develop the toolbar as a user-interface idiom than any other software publisher. This is reflected in the quality of its products. In its Office suite, all the toolbars are very customizable. Each program has a standard battery of toolbars that users can choose to make visible or invisible. If they are visible, they can be dynamically positioned in one of five locations. They can be attached — or docked — to any of the four sides of the program’s main window. If a user drags the toolbar away from the edge, it configures itself as a floating toolbar, complete with a mini title bar, as shown in Figure 23-4.

  Figure 23-4 Toolbars can be docked horizontally (top), vertically (left), and dragged off the toolbar to form free-floating palettes.

  29_084113 ch23.qxp 4/3/07 6:11 PM Page 501

  Chapter 23: Toolbars

  501

  Allowing users to move toolbars around also provided the possibility for users to obscure parts of toolbars with other toolbars. Microsoft handily addresses this problem with an expansion combutcon or drop-down menu that appears only when a toolbar is partly obscured, and provides access to hidden items via a drop-down menu, as shown in Figure 23-5.