Figure 23-5 Microsoft’s clever way of allowing users to overlap toolbars but still get at all their functions. This provides a very lightweight kind of customization; power users would more likely perform full toolbar customization to address similar needs via the Customize . . . item at the bottom of the drop-down menu.
It’s also important to note that these toolbars do have a default anchored location — users aren’t forced to move them around without good reason, which would be pure excise.
Customizable toolbars
Microsoft has clearly seen the dilemma that arises because toolbars represent the frequently used functions for all users, but at least a few of those functions are different for each user. Microsoft apparently arrived at this solution: Ship the program with the best guess at what typical users’ daily-use controls are, and let the others customize this. This solution has been diluted somewhat, however, by the addition of non-daily-use functions. For example, the Word toolbar’s default butcon suite contains functions that certainly are not frequently used. Controls like Insert Auto-text or Insert Excel Spreadsheet seem more like feature checklist items than practical, daily options for the majority of users. Although they may be useful at times, most users do not frequently use them. The use of personas and scenarios is a useful tool for sorting out situations such as these (see Chapters 5 and 6).
Word gives more advanced users the ability to customize and configure the toolbars to their hearts’ content. There is a certain danger in providing this level of cus-tomizability to the toolbars, as it is possible for a reckless user to create a really unrecognizable and unusable toolbar. However, it takes some effort to totally wreck things. People generally won’t invest much effort into creating something that is
29_084113 ch23.qxp 4/3/07 6:11 PM Page 502
502
Part III: Designing Interaction Details
ugly and hard to use. More likely, they will make just a few custom changes and enter them one at a time over the course of months or years. Microsoft has extended the idiom so that you can create your own completely new, completely custom toolbars. The feature is certainly overkill for normal users, but there are those who appreciate such flexibility.
The ribbon
As we discussed earlier in this chapter and in Chapter 22, Microsoft introduced a new GUI idiom with Office 2007: The ribbon (see Figure 23-6). In essence, it is a tabbed toolbar with textual labels for groups of functions, as well as a heterogeneous presentation of butcons and textual commands. The tabs provide groupings similar to those used in menus (such as Home, Insert, Page Layout, References, Mailings, Review, and View in Word 2007).
Figure 23-6 The ribbon in Microsoft Word 2007 replaces the menu system with what is essentially a tabbed toolbar. While it does provide a more visual way to access functions than a traditional menu, its lack of text labels may limit its effectiveness as a pedagogical mechanism.
Aside from creating a more visually structured way of presenting a considerable number of functions, which is certainly of value, it isn’t clear that the ribbon is quite as innovative as Microsoft suggests. (And although positioned differently, it also seems quite similar to Apple’s “Inspectors.” For example, iWeb has a tool palette that changes contents based on selection of a tool at the top. It is not represented as a tab, but it behaves as one.)
In fact, the near abandonment of text commands as found in traditional menus (which users have to go to Options to turn on) in favor of butcons may have grave implications for users learning to use the products. At the time of writing, this idiom has only been in widespread use for a few months, and it is too early to assess its success.
29_084113 ch23.qxp 4/3/07 6:11 PM Page 503
Chapter 23: Toolbars
503
Contextual toolbars
A truly useful evolution of the toolbar idiom is the contextual toolbar. Similar to a right-click contextual menu, it provides a small group of butcons adjacent to the mouse cursor. In some implementations, the specific butcons presented are dependent on the object selected: If text is selected, the buttons provide text-formatting options; if a drawing object is selected, the buttons enable users to change object properties. A variation of this idiom was also popularized with Microsoft Office 2007 (where it is called the “Mini Toolbar”), though similar idioms have been used in several applications, including Adobe Photoshop (where the toolbar is docked) and Apple’s Logic music production environment (where the toolbar is a modal cursor palette).
29_084113 ch23.qxp 4/3/07 6:11 PM Page 504
30_084113 ch24.qxp 4/3/07 6:11 PM Page 505
24
Dialogs
As we discussed in Chapter 21, the hallmark of bad interaction design is a user interface that consists primarily of control-laden modal dialog boxes. It is very difficult to create fluid interactions by forcing users through a maze of dialogs. If a user is the chef, and the application is the kitchen, then a dialog box is the pantry.
The pantry plays a secondary role, as should dialog boxes. They are supporting actors rather than lead players, and although they may ratchet the action forward, they should not be the engines of motion.
Appropriate Uses for Dialog Boxes
Dialogs are superimposed over the main window of the application. A dialog engages users in a conversation by offering information and requesting some input.
When a user has finished viewing or changing the information presented, he has the option of accepting or rejecting his changes. The dialog then disappears and returns the user to the main application window.
Unfortunately, many users and programmers have come to think of dialog boxes as the primary user-interface idiom of the GUI (this is largely a result of the ease with which dialogs can be implemented). Many applications use dialogs to provide the main method of interaction with the program (and we’re not talking about simple applications that are composed of just a single dialog box; in those cases, the dialog
30_084113 ch24.qxp 4/3/07 6:11 PM Page 506
506
Part III: Designing Interaction Details
assumes the role of a main window). In most applications, users are forced to bounce back and forth between the main window and its dialog boxes, inevitably leading to fatigue and frustration.
DESIGN
Put primary interactions in the primary window.
principle
When an application presents a dialog box, it temporarily moves the action out of the primary flow, abandoning a user’s main focus of attention to introduce a secondary issue. If you asked your dinner party guests to temporarily abandon their soup and step into the pantry, the smooth flow of conversation would be broken, which is clearly to be avoided unless you have a darn good reason for dragging them in there. In the same way, a dialog box breaks the smooth flow of rapport between a user and the program. Dialogs, for good or ill, interrupt the interaction and make users react to the program instead of driving it.
It’s sometimes useful to take users out of their flow to force them to focus on particular interactions. Dialogs are appropriate for functions or features that are out of the mainstream: Anything that is confusing, dangerous, or rarely used can usefully be placed in a dialog box. This is particularly true for dislocating actions that make immediate and gross changes to the application state. Such changes can be visually disturbing to users and should be cordoned off from users unfamiliar with them.
For example, a function that allows wholesale reformatting of a document should be considered a dislocating action. The dialog helps prevent this feature from being invoked accidentally by assuring that a big, friendly Cancel button is always present, and also by providing the space to show more protective and explanatory information along with the risky controls. The dialog can graphically show users the potential effects of the function with a thumbnail picture of what the changes will look like (and of course, on a separate topic, a robust Undo function should be provided for such actions).
Dialogs are
appropriate for functions that are out of the main
DESIGN
principle
interaction flow.
Dialog boxes are also good for presenting infrequently used functions and settings.
A dialog box serves to isolate these operations from more frequently used functions and settings. A dialog box is generally a roomier setting for presenting controls than other primary control venues are; you have more space for explanatory labels than you do in a toolbar, for example.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 507
Chapter 24: Dialogs
507
Dialog boxes are also well suited for concentrating information related to a single subject, such as the properties of a domain object — an invoice or a customer, for example. They can also gather together all information relevant to a function performed by a program — such as printing reports. This has obvious benefits to users: with all the information and controls related to a given subject in a single place, users don’t have to search around the interface as much for a given function, and navigation excise is reduced.
Dialogs are appropriate for organizing controls and information
DESIGN
principle
about a single domain object or application function.
Similar to menus, dialog boxes can be effective command vectors for users who are still learning an application. Because dialog boxes can be more verbose and structured, they can provide an alternate, pedagogic vector for functions that are also accessible through direct manipulation in the main application window. An example of this can be seen in tab definition in Microsoft Word. A user proficient in the application’s idioms can define tab stops by directly manipulating the small thumbs in the document ruler. This idiom is not terribly easy to discover, so Microsoft designers had the foresight to provide a Tabs command in the Format menu, as well, which gives more guidance to users (though it should be said that this dialog unfortunately does little to teach users how to use the ruler idiom).
Dialog boxes serve two masters: The frequent user who is familiar with the program and uses them to control its more advanced or dangerous facilities, and the infrequent user who is unfamiliar with the scope and use of the program and who is using dialogs to learn the basics. This dual nature means that dialog boxes must be compact and powerful, speedy and smooth, and yet be clear and self-explanatory.
These two goals may seem to contradict each other, but they can actually be useful complements. A dialog’s speedy and powerful nature can contribute directly to its power of self-explanation.
Dialog Box Basics
Most dialogs contain a combination of informative text, interactive controls, and associated text labels. Although there are some rudimentary conventions, the diverse applications of the idiom mean that there are few hard and fast rules. It is important to create dialog boxes in accordance with good visual interface design practices and ensure that they use GUI controls appropriately. In particular, a dialog should exhibit a strong visual hierarchy, visual groupings based upon
30_084113 ch24.qxp 4/3/07 6:11 PM Page 508
508
Part III: Designing Interaction Details
similarities in subject, and a layout based on the conventional reading order (left to right and top to bottom for Western cultures). For more details about these visual interface design practices, see Chapter 14. For more about the appropriate use of standard GUI controls, see Chapter 21.
When instantiated, a dialog box should always initially appear on the topmost visual layer, so it is obvious to the user who requested it. Subsequent user interactions may obscure the dialog with another dialog or application, but it should always be obvious how to restore the dialog to prominence.
A dialog should always have a title that clearly identifies its purpose. If the dialog box is a function dialog, the title bar should contain the function’s action — the verb, if you will. For example, if you request Break from the Insert menu in Word, the title bar of the dialog should say Insert Break. What are we doing? We are inserting a break! We are not breaking, so the title bar should not say Break. A word like that could easily scare or confuse someone.
DESIGN
Use verbs in function dialog title bars.
principle
If the dialog box is used to define the properties of an object, the title bar should contain the name or description of that object. The properties dialogs in Windows work this way. When you request the Properties dialog for a directory named Backup, the title bar says Backup Properties. Similarly, if a dialog box is operating on a selection, it can be useful to reflect a truncated version of the selection in the title in order to keep users oriented.
DESIGN
Use object names in property dialog title bars.
principle
Most conventional dialog boxes have at least one terminating command, a control that, when activated, causes the dialog box to shut down and go away. Most modal dialogs offer at least two pushbuttons as terminating commands, OK and Cancel, although the Close box in the upper-right corner is also a terminating command idiom.
It is technically possible for dialogs not to have terminating commands. Some dialogs are unilaterally erected and removed by the program — for reporting on the progress of a time-consuming function, for example — so their designers may have omitted terminating commands. This is poor design for a variety of reasons, as we will see.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 509
Chapter 24: Dialogs
509
Modal Dialog Boxes
There are two types of dialog boxes: modal and modeless. Modal dialogs boxes are, by far, the most common variety. After a modal dialog opens, the owner application cannot continue until the dialog box is closed. It stops all proceedings in their tracks. Clicking on any other window belonging to the program will only get a user a rude “beep” for his trouble. All the controls and objects on the surface of the owner application are deactivated for the duration of the modal dialog box. Of course, a user can activate other programs while a modal dialog box is up, but the dialog box will stay there indefinitely. When the user goes back to the program, the modal dialog box will still be there waiting.
In general, modal dialogs are the easiest for users (and designers) to understand.
The operation of a modal dialog is quite clear, saying to users, “Stop what you are doing and deal with me now. When you are done, you can return to what you were doing.” The rigidly defined behavior of the modal dialog means that, although it may be abused, it will rarely be misunderstood. There may be too many modal dialog boxes and they may be weak or stupid, but their purpose and scope will usually be clear to users.
Some modal dialogs operate on the entire application or on the entire active document. Others operate on the current selection, in which case, a user can’t change the selection after summoning the dialog. This is the most important difference between modal and modeless dialogs.
Actually, because modal dialog boxes only stop their owning applications, they are more precisely named application modal. It is also possible to create a system modal dialog box that brings every program in the system to a halt. In most cases, applications should never have one of these. Their only purpose is to report truly catastrophic occurrences (such as the hard disk melting) that affect the entire system or a real-world process.
Modeless Dialog Boxes
The other variety of dialog box is called modeless. Modeless dialogs are less common than their modal siblings.
After the modeless dialog opens, the parent program continues without interruption. It does not stop the proceedings, and the application does not freeze. The various facilities and controls, menus, and toolbars of the main program remain active and functional. Modeless dialogs have terminating commands, too, although the conventions for them are far weaker and more confusing than for modal dialogs.
30_084113 ch24.qxp 4/3/07 6:11 PM Page 510
510
Part III: Designing Interaction Details
A modeless dialog box is a much more difficult beast to use and understand, mostly because the scope of its operation is unclear. It appears when you summon it, but you can go back to operating the main program while it stays around. This means that you can change the selection while the modeless dialog box is still visible. If the dialog acts on the current selection, you can select, change, select, change, select, and change all you want. For example, Microsoft Word’s Find and Replace dialog allows you to find a word in text (which is automatically selected), make edits to that word, and then pop back to the dialog, which has remained open during the edit.
In some cases, you can also drag objects between the main window and a modeless dialog box. This characteristic makes them really effective as tool or object palettes in drawing programs.
Modeless dialog issues
Many modeless dialogs are implemented awkwardly. Their behavior is inconsistent and confusing. They are visually very similar to modal dialog boxes, but they are functionally very different. There are few established behavioral conventions for them, particularly with respect to terminating commands.
Much of the confusion creeps into the situation because users are so familiar with the behavior of modal dialogs. A modal dialog can adjust itself for the current selection at the instant it was summoned. It can do this with assurance that the selection won’t change during its lifetime. Conversely, the selection is quite likely to change during the lifetime of a modeless dialog box. Then what should the dialog do? For example, if a modeless dialog box modifies text, what should it do if we now select some nontext object on the main window? Should gizmos on the dialog box gray out? Change? Disappear? Questions such as this require refined design practices, as well as close examination of persona needs, goals, and mental models. Consequently, modeless dialogs can be much more challenging to design and implement than modal dialogs, which avoid these issues by freezing application state.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 67