5.2. THE PATTERNS The first two patterns in this chapter talk about two of the many ways to present actionsone common, one not. When you find yourself reflexively putting actions on an application's menu bar or pop-up menu, stop for a moment and consider using Button Groups or Action Panels instead. Button Groups Action Panel
Prominent "Done" Button improves the single most important button on many web pages and dialog boxes. Smart Menu Items is a technique for improving some of the actions you put on menus; this is a very general pattern, useful for many kinds of menus (or buttons and links). Prominent "Done" Button Smart Menu Items
We'd like it if we could complete all user-initiated actions in an application instantly, but that's not realitysome actions are time-consuming. Preview shows the user what's going to happen before such an action is committed. Progress Indicator is a well-known technique for letting the user know what's going on while an operation proceeds, while Cancelability refers to a UI's ability to stop an operation when the user asks it to. Preview Progress Indicator Cancelability
The last three patternsMulti-Level Undo, Command History, and Macrosall deal with sequences of actions. These three interlocking patterns are most useful in complex applications, especially those whose users are committed to learning the software well and using it extensively. (That's why the examples come from software such as Linux, Photoshop, Word, and MATLAB.) Be warned that these patterns are not easy to implement. They require the application to model a user's actions as discrete, describable, and sometimes reversible operations, and such a model is very hard to retrofit into existing software architecture. The "Command" pattern in the book Design Patterns (Addison-Wesley) is one good place to look for implementation advice. Multi-Level Undo Command History Macros
And that's as close as this book gets to implementation details. We'll now return to the realm of interface design. 44. button groups Figure 5-3. Two button groups in a Word's Customize dialog box 
5.2.1.1. what Present related actions as a small cluster of buttons, aligned either horizontally or vertically. Create several of them if there are more than three or four actions. 5.2.1.2. use when You present a small number of actions, say two to five, that are relatedthey might act on the same things, or have similar or complementary effects. OK, Cancel, Apply, and Close buttons usually are found in groups; they all act on the dialog box as a whole. Likewise, buttons that handle the objects in a list (like Move Up, Move Down, or Delete) should be grouped. 5.2.1.3. why Button groups help make an interface self-describing. Well-defined clusters of buttons are easy to pick out of a complex layout, and because they're so visible, they instantly communicate the availability of those actions. They announce, "These are the actions you've got to work with in this context." The Gestalt principles discussed in Chapter 4 apply here. Proximity hints at relatednessthe buttons are all together, so they probably do similar things. So does visual similarity; if you make all the buttons the same dimensions, for instance, they look like they belong together. Proper sizing and alignment help the button group form a larger composite visual shape (this is the principle of closure). 5.2.1.4. how Make a group out of the buttons in question. Label them with short but unambiguous verbs or verb phrases, and don't use jargon unless users expect it. Do not mix buttons that affect different things, or have different scope; see these examples for illustrations of how to do this well. Separate them into different groups. All buttons in the group should be the same height and width (unless the label length varies widely). You can line them up in a single column, or arrange them in a single row if they aren't too wide; two or more columns or rows don't look as good. 5.2.1.4.1. PLACEMENT OF BUTTON GROUPS If the buttons all act on the same object or objects, put the button group to the right of those objects. You could put it below them instead, but users often have a "blind spot" at the bottom of complex UI elements like multicolumn lists and treesthe buttons may not be seen at all. If you have a specific design that works better with the buttons at the bottom, usability-test it and find out. If there are enough buttons, and if they have icons, you could also put them on a toolbar or a toolbar-like strip at the top of the page. When the buttons affect the whole page or dialog box, like Close or OK, then you should follow the style guide for your platform. Usually they'll be in a column on the far-right margin, or in a row on the bottom-right corner. Users will be habituated to look for them there (see Habituation in Chapter 1). But standalone Close buttons are a special case. Sometimes you can get away with just using a simple "X" icon and placing the button in the upper-right cornerWindows users will instinctively know what to do, and users of other platforms often know that convention too. 5.2.1.5. examples The Word dialog box in Figure 5-3 has two button groupsone for list-specific actions, and the other for more general actions. The "scoping" of the button groups is appropriate: the list-specific buttons affect only items on that tab, so they're inside the tab page, whereas the other buttons sit outside the tabs altogether. The "Close" button's position in the lower-right corner is standard for these sorts of dialog boxes, on both Windows and the Mac. Figure 5-4. Amazon uses pairs of related buttons on its recommendations page. The buttons look alike (yellow and rounded), they're placed next to each other, and they do things that are similar from a user's perspective. Note also that the pairs of buttons all are aligned with each other horizontally. In a whole page full of these book recommendationsonly two of which are shown herethey form a strong structural rhythm on the page. 
Figure 5-5. iTunes places button groups at each of the four corners of the main window, plus the standard titlebar buttons (such as close or minimize). When the user browses the Music Store, there are even more actions contained in the web-page-like third panel (not shown)links constitute many of the actions thereand a button for each song in the table.
No fewer than fourteen buttons appear on this interface. I'm not even counting the four scrollbar buttons or the three clickable table headers. There's lots to do here, but thanks to careful visual and semantic organization, the interface is never overwhelming. 
45. action panel Figure 5-6. Powerpoint's "New Presentation" panel 
5.2.2.1. what Instead of using menus, present a large group of related actions on a UI panel that's richly organized and always visible. 5.2.2.2. use when You need to present many actionstoo many for a Button Group. You could put them into a menu, but maybe you don't have a menu bar at all, or you'd rather make the actions more obvious. Same for pop-up menus; they're just not visible enough. Your users may not even realize the pop-up menus exist. Or maybe your set of possible actions is too complex even for a menu. Menus are best at showing flat set of actions (since pull-right menus, or cascading menus, are hard for some users to manipulate), in a very simple, linear, one-line-per-item presentation. If your actions need to be grouped, and if those groups don't fit the standard top-level menu namessuch as File, Edit, View, Tools, or Formatthen you might want a different presentation altogether. This pattern can take up a lot of screen space, so it's not usually a good choice for small devices. 5.2.2.3. why The "Use when" section already hinted at the two main reasons for using action panels: visibility and freedom of presentation. By placing the actions out on the main UI, and not hidden inside a traditional menu, you make those actions fully visible to the user. Really, action panels are menus, in the generic sense; they just aren't found in menu bars, dropdowns, or pop-ups. Users don't have to do anything to see what's on an action panelit's right there in front of themso your interface is more discoverable. This is particularly nice for users who aren't already familiar with traditional document model and its menu bars. There are many, many ways to structure objects on an interface: lists, grids or tables, hierarchies, and just about any custom structure you can devise. But button groups and traditional menus only give you a list (and not a very long one). Action panels are freeformthey give you as much freedom to visually organize verbs as you have for nouns. Use it wisely! This is one of the places where web design conventions were "back-ported" into desktop applications. Since early web applications couldn't depend on dynamically shown menus, and they certainly couldn't use the browser's menu bar, page designers found other ways of presenting action menus. Vertical columns of links seemed to work fine. (The fact that they're links, not buttons, is sort of irrelevant; if they're labeled as verbs, and if they appear to perform actions, who cares about their implementation? Users don't.) 5.2.2.3.1. PUTTING THE ACTION PANEL ON THE UI Set aside a block of space on the interface for the action panel. Place it below or to the side of the target of the action. The target usually is a list, table, or tree of selectable items, but it also might be Center Stage (Chapter 4), like the Powerpoint example in Figure 5-6. Remember that proximity is important. If you place the action panel too far away from whatever it acts on, users may not grasp the relationship between them. The panel could be a simple rectangle on the page. It could be one of several tiled panels on the page, perhaps a Movable Panel (see Chapter 4), a "drawer" in Mac OS X, or even a separate window. That choice depends on the nature of your application. If it's closable, then make it very easy to reopen, especially if those actions are present only on the action panel and aren't duplicated on a menu! Odds are good that you'll need to show different actions at different times. The contents of the action panel may depend on the state of the application (e.g., are there any open documents yet?), on the items selected in some list somewhere, or other factors. Let the action panel be dynamic. The changes will attract the user's attention, which is good. 5.2.2.3.2. STRUCTURING THE ACTIONS Next, you need to decide how to structure the actions you need to present. Here are some ways you could do it: If you categorize the actions, consider using task-centered approach. Group them according to what people intend to do. In the Powerpoint example, for instance, there's an "Open a presentation" group, plus several groups for creating new slideshows. Still, try to present these groups linearly. Imagine reading the actions aloud to someone who can't see the screencan you proceed through them in a logical fashion, with obvious start and end points? That, of course, is how a blind user would "hear" the interface. Incidentally, you also can put controls on an action panel, like a text field next to a "Search" button. 5.2.2.3.3. LABELING THE ACTIONS For each action's label, you could use text, icons, or both, depending on what best conveys the nature of the actions. In fact, if you use mostly icons, then you end up with…a traditional toolbar! (Or a palette, if your UI is a visual builder-style application.) Text labels on an action panel can be longer than those on a menu or a button. You can use multiline labels, for instanceno need to be overly parsimonious with words here. Just remember that longer, more descriptive labels are better for first-time or infrequent users, who need to learn (or be remind-ed of) what these actions do. The extra space spent on long labels may not be appreciated in dense high-performance interfaces mostly by experienced users. If there are too many words, even first-time users' eyes will glaze over. There's often no need to make the actions look like buttons, even if they're implemented as buttons. Phrases written in blue text communicate click-ability, since they look like links on a web page; you could enhance the effect by underlining them when the mouse rolls over them. This is what Microsoft does in its interfaces that use action panels. Feel free to experiment. However, usability-test it to make sure users actually see the actions as clickable things, not ordinary text or pictures. 5.2.2.4. examples Figure 5-7. This screenshot of the Windows Explorer shows a directory of pictures attached to an action panel. Microsoft calls this feature a "Task Pane." The panel is composed of closable subpanels (see the Closable Panels pattern in Chapter 4), each of which contains a manageable handful of related actions.
Note that the first two sections, Picture Tasks and File and Folder Tasks, are completely task-oriented: they're phrased as verbs (View, Order, Print, and Copy), and they anticipate things users will commonly want to do. You might recall that in Chapter 1, we talked about organizing interfaces according to lists of objects, actions, categories, and tools. The first two sections are fine examples of lists of actions. But the third section in this panel, "Other Places," is a list of objects instead. 
Figure 5-8. The same panel, but with an image file selected. The panel changes dynamically according to contextthe listed tasks are not the same as in the other screenshot, in which no files are selected. 
46. prominent "done" button Figure 5-9. From http://mapblast.com 
5.2.3.1. what Place the button that finishes a transaction at the end of the visual flow; make it big and well-labeled. 5.2.3.2. use when Whenever you need to put a button like "Done," "Submit," or "OK" on your interface, use this pattern. More generally, use a visually prominent button for the final step of any transactionlike an online purchaseor to commit a group of settings. 5.2.3.3. why A well-understood, obvious last step gives your users a sense of closure. There's no doubt that the transaction will be done when that button is clicked; don't leave them hanging, wondering whether or not their work took effect. Making that last step obvious is what this pattern is really about. Doing it well draws on the layout concepts in Chapter 4visual hierarchy, visual flow, grouping, and alignment. 5.2.3.4. how Create a button that actually looks like a button, not a link; either use platform standards for push buttons, or use a medium-sized button graphic with well-defined borders. This will help the button stand out on the page, and it won't get lost among other things. When labeling the button, prefer text labels to icons. They're easier to understand for actions like this, especially since most users look for a button labeled "Done," "Submit," or "OK." The text in that label can be a verb or a short verb phrase that describes what will happen, in the user's terms"Send," "Buy," or "Change Record" are more specific than "Done," and can sometimes communicate more effectively. Place the button where the user most likely will find it. Trace the task flow down through the page or form or dialog box, and put the button just beyond the last step. Usually that will be on the bottom and/or right of the page. Your page layouts may have a standard place for them (see the Visual Framework pattern in Chapter 4), or the platform standard may prescribe it; if so, use the standard. In any case, make sure the button is near the last text field or control. If it's too far away, then the user may not find it immediately upon finishing his work, and he may look for other affordances in his quest for "what to do next." On the Web, he may end up abandoning the page (and possibly a purchase) without realizing it. 5.2.3.5. examples Figure 5-10 shows a typical web form. You probably can see the button in question without even reading the labels, due to visual design alone: The orange color stands out. It's a saturated color; it contrasts with the white background, and it echoes the orange of the logo in the upper leftthose are the only orange things on the page. (Note the use of the Diagonal Balance pattern, anchored by those two orange elements. See Chapter 4.) The graphic used for the button looks like a button. It's a rounded or "pill" shape, with a very slight drop shadow, which makes it pop out from the background. The button is positioned at the right edge of the form, directly under the body of the form itself. Both the task flow (the user will work from top to bottom) and the visual flow bring the eye to rest at that button The button is set off by whitespace on its left, right, and bottom. That groups it with the form, but there's nothing else around it to compete with it.
Figure 5-10. From http://ofoto.com 
47. smart menu items Figure 5-11. Word's Edit menu 
5.2.4.1. what Change menu labels dynamically to show precisely what they would do when invoked. 5.2.4.2. use when Your UI has menu items that operate on specific objects, like Close, or that behave slightly differently in different contexts, like Undo. 5.2.4.3. why Menu items that say exactly what they're going to do make the UI self-explanatory. The user doesn't have to think about what object will be affected. She's also less likely to accidentally do something she didn't intend, like deleting "Chapter 8" instead of "Footnote 3." It thus encourages Safe Exploration. 5.2.4.4. how Every time the user changes the selected object (or current document, last undoable operation, etc.), change the menu items that operate on it to include the specifics of the action. Obviously, if there is no selected object, you should disable the menu item, thus reinforcing the connection between the item and its object. Incidentally, this pattern also could work for button labels, links, or anything else that is a "verb" in the context of the UI. What if there are multiple selected objects? There's not a whole lot of guidance out therein existing software, this pattern mostly applies to documents and undo operationsbut you could write in a plural, like "Delete Selected Objects." 5.2.4.5. example Figure 5-12. A menu from Illustrator's menu bar. The last filter the user applied in this case was the "Hatch Effects" filter. The menu remembers that, so it changes its first two items to (1) reapply the same filter again and (2) modify the filter before reapplying. ("Hatch Effects…" brings up the dialog box to modify it.) The user might have applied so many filters that she'd find it useful to be reminded of the last one. And the accelerator keystrokes are handy for repeated application of the same filter! 
48. preview Figure 5-13. PowerPoint's Print Preview screen 
5.2.5.1. what Show users a preview or summary of what will happen when they perform an action. 5.2.5.2. use when The user is just about to do a "heavyweight" actionsuch as opening a large file, printing a 10- page document, submitting a form that took time to fill out, or committing a purchase over the Web. The user wants some assurance that he's doing it correctly. Doing it wrong would be time-consuming or otherwise costly. Alternatively, the user might be about to perform a graphic action that isn't particularly heavyweight, but he'd still like to know what it will do in advance. 5.2.5.3. why Previews help prevent various errors. A user may have made a typo, or he may have misunderstood something that led up to the action in question (like purchasing the wrong item online). By showing him a summary or visual description of what's about to happen, you give him a chance to back out or correct any mistakes. Previews also can help an application become more self-describing. If someone's never used a certain action before, or doesn't know what it will do under certain circumstances, a preview explains it better than any documentationthe user learns about the action exactly when and where he needs to. 5.2.5.4. how Just before the user commits an action, display whatever information gives him the clearest picture of what's about to happen. If it's a print preview, show what the page will look like on the chosen paper size; if it's an image operation, show a closeup of what the image will look like; if it's a transaction, show a summary of everything the system knows about that transaction. Show what's importantno more, no less. Give the user a way to commit the action straight from the preview page. There's no need to make the user close the preview or navigate elsewhere. Likewise, give the user a way to back out. If he can salvage the transaction by correcting previously entered information, give him a chance to do that, too. In many wizards and other linear processes, this is just a matter of navigating a few steps backwards. 5.2.5.5. examples Figure 5-14. Amazon's order summary page comes at the end of a multipage purchase process, during which items were chosen and shipping and payment details were provided. The format is compact and readable, the content is segmented into Titled Sections (Chapter 4), and many pieces of information have a convenient "Change" button next to them. The "Place your order" buttons (two, you might notice, for people too rushed to read the whole page) are clear, large, and brightly coloredvery easy to find. 
Figure 5-15. Photoshop's image filtering software is complex, and the filters can be time-consuming to apply to enormous digital images. A user might need to experiment with many similar filters before finding one that has the desired effect, and he wants quick turnaround as he browses through the filter library. This is a classic preview situation.
The user chooses filters from the center panel in this screenshot; the preview appears on the left, using a fraction of the user's image. A tiny sample picture not related to the user's image represents each filter, so the user actually sees two levels of preview, in a senseone to pick a filter, and the other to see the results as applied to the actual work. (See the Illustrated Choices pattern in Chapter 7.) 
49. progress indicator Figure 5-16. Internet Explorer progress dialog box 
5.2.6.1. what Show the user how much progress was made on a time-consuming operation. 5.2.6.2. use when A time-consuming operation interrupts the UI, or runs in the background, for longer than two seconds or so. 5.2.6.3. why Users get impatient when the UI just sits there. Even if you change the mouse pointer to a clock or hourglass (which you should in any case, if the rest of the UI is locked out), you don't want to make a user wait for an unspecified length of time. Experiments show that if users see an indication that something is going on, they're much more patient, even if they have to wait longer than they would without a progress indicator. Maybe it's because they know that "the system is thinking," and it isn't just hung or waiting for them to do something. 5.2.6.4. how Show an animated indicator of how much progress has been made. Either verbally or graphically (or both), tell the user: As far as time estimates are concerned, it's okay to be wrong sometimes, as long as your estimates converge on something accurate quickly. But sometimes the UI can't tell how far along it is. In that case, show something animated anyway that is noncommittal about percentages. Think about the browsers' image loops that keep rolling while a page loads. Most GUI toolboxes provide a widget or dialog box that implements this pattern, like Java Swing's JProgressBar. Beware of potentially tricky threading issues, howeverthe progress indicator must be updated consistently, while the operation itself proceeds uninhibited. If you can, keep the rest of the UI alive too. Don't lock up the UI while the progress indicator is visible. If it's possible to cancel the operation whose progress is monitored, offer a cancel button or similar affordance on or near the progress indicator; that's where a user probably will look for it. See the Cancelability pattern (next) for more information. 5.2.6.5. example Figure 5-17. This startup screen uses icons to show what KDE does while it startseach icon becomes sharply defined when that step is reached. No timing numbers are used, but they aren't really necessary (the user is a captive audience until KDE finishes starting), and they may not be accurate anyway. 
50. cancelability Figure 5-18. Firefox's stop-loading button 
5.2.7.1. what Provide a way to instantly cancel a time-consuming operation, with no side effects. 5.2.7.2. use when A time-consuming operation interrupts the UI, or runs in the background, for longer than two seconds or sosuch as when you print a file, query a database, or load a large file. Alternatively, the user is engaged in an activity that literally or apparently shuts out most other interactions with the system, such as when working with a modal dialog box. 5.2.7.3. why Users change their minds. Once a time-consuming operation starts, a user may want to stop it, especially if a Progress Indicator tells her that it'll take a while. Or the user may have started it by accident in the first place. Cancelability certainly helps with error prevention and recoverya user can cancel out of something she knows will fail, like loading a page from a web server she realizes is down. A user will feel better about exploring the interface and trying things out if she knows that anything is cancelable. It encourages Safe Exploration (see Chapter 1), which in turn makes the interface easier and more fun to learn. 5.2.7.4. how First, find out if there's a way to speed up the time-consuming operation so it appears instantaneous. It doesn't even have to be genuinely fast; if a user perceives it as immediate, that's good enough. On the Web or a networked application, this may mean preloading data or codesending it to the client before it's asked foror sending data in increments, showing it to the user as it comes in. Remember, people can only read so fast. You might as well use the loading time to let the user read the first page's worth of data, then another page, and so on. However, if you really do need to cancel it, here's how to do it. Put a cancel button directly on the interface, next to the Progress Indicator (which you are using, right?) or wherever the results of the operation appear. Label it with the word Stop or Cancel, and/or put an internationally recognizable stop icon on it: a red octagon, a red circle with a horizontal bar, or an X. When the user clicks or presses the Cancel button, cancel the operation immediately. If you wait too long, for more than a second or two, the user may doubt that the cancel actually worked (or you may dissuade him from using it, since he might as well wait for the operation to finish). Tell the user that the cancel workedhalt the progress indicator, and show a status message on the interface, for instance. Multiple parallel operations present a challenge. How does the user cancel a particular one and not others? The cancel button's label or tooltip can state exactly what gets canceled when it's pressed (see the Smart Menu Items pattern for a similar concept). If the actions are presented as a list or a set of panels, you might consider providing a separate cancel button for each action, to avoid ambiguity. 5.2.7.5. examples If you've ever tried to cancel a photocopier jobmaybe you accidentally requested 600 copies of somethingit's usually pretty obvious how to do it. There's a big Stop or Cancel button on the copier panel. When you hit it, the copier stops as soon as it's finished the current copy or page. In Windows, however, if you send a document to the printer and then need to cancel it (maybe you just printed 600 pages by accident), you first must bring up the printer's properties window. It's not immediately obvious how to get there, though there are several ways to do it. Once there, no Cancel button presents itself. You need to use either the menu bar or the context menu (shown here) to cancel the print job. Then a confirmation dialog box asks you if you're really sure. Thus it takes many clicks and a not-so-obvious path to cancel a print job. Figure 5-19. Windows XP printer window, with a hard-to-find Cancel operation. Don't do it this way. 
51. multi-level undo Figure 5-20. Photoshop's visual representation of the "undo stack" 
5.2.8.1. what Provide a way to easily reverse a series of actions performed by the user. 5.2.8.2. use when You've designed a highly interactive UI that is more complex than simple navigation or form fill-in. This includes mail readers, database software, authoring tools, graphics software, and programming environments. 5.2.8.3. why The ability to undo a long sequence of operations lets users feel that the interface is safe to explore. While they learn the interface, they can experiment with it, confident that they aren't making irrevocable changeseven if they accidentally do something "bad." This is true for users of all levels of skill, not just beginners.[1] [1] Alan Cooper and Robert Reimann devote an entire chapter to the Undo concept in their book About Face 2.0: The Essentials of Interaction Design (Wiley).
Once the user knows the interface well, she can move through it with the confidence that mistakes aren't permanent. If her finger slips and she hits the wrong menu item, no complicated and stressful recovery is necessary; she doesn't have to revert to saved files, shut down and start afresh, or go ask a system administrator to restore a backup file. This spares users wasted time and occasional mental anguish. Multi-level undo also lets expert users explore work paths quickly and easily. For instance, a Photoshop user might perform a series of filtering operations on an image, study the result to see if she likes it, and then undo back to her starting point. Then she might try out another series of filters, maybe save it, and undo again. She could do this without multi-level undo, but it would take more time (for closing and reloading the image). When a user works creatively, speed and ease-of-use are important for maintaining focus and the experience of flow. See Chapter 1 for more information, especially the Safe Exploration and Incremental Construction patterns. 5.2.8.4. how 5.2.8.4.1. UNDOABLE OPERATIONS The software your UI is built on first needs a strong model of what an action iswhat it's called, what object it was associated with, and how to reverse it. Then you can build an undo interface on it. Decide which operations need to be undoable. Any action that might change a file, or anything that could be permanent, should be undoable, while transient or view-related states often are not. Specifically, these kinds of changes are expected to be undoable in most applications: Text entry for documents or spreadsheets Database transactions Modifications to images or painting canvases Layout changesposition, size, stacking order, or grouping in graphic applications File operations, such as deleting or modifying files Creation, deletion, or rearrangement of objects such as email messages or spreadsheet columns Any cut, copy, or paste operation
The following kinds of changes generally are not undoable. Even if you think you want to go above and beyond the call of duty and make them undoable, consider that you might thoroughly irritate users by cluttering up the "undo stack" with useless undos: Text or object selection Navigation between windows or pages Mouse cursor and text cursor locations Scrollbar position Window or panel positions and sizes Changes made in an uncommitted or modal dialog box
Some operations are on the borderline. Form fill-in, for instance, sometimes is undoable and sometimes is not. However, if tabbing out of a changed field automatically commits that change, it's probably a good idea to make it undoable. (Certain kinds of operations are impossible to undo. But usually the nature of the application makes that obvious to users with any experience at all. Impossible undos include the purchase step of an e-commerce transaction, posting a message to a bulletin board or chatroom, or sending an emailas much as we'd sometimes like to undo that!) In any case, make sure the undoable operations make sense to the user. Be sure to define and name them in terms of how the user thinks about the operations, not how the computer thinks about them. You should undo typed text, for instance, in chunks of words, not letter-by-letter. 5.2.8.4.2. DESIGN AN UNDO STACK Each operation goes on the top of the stack as it is performed, and each Undo reverses the operation at the top, then the next one down, then the next. Redo similarly works its way back up the stack. The stack should be at least 10 to 12 items long to be useful, and longer if you can manage it. Longterm observation or usability testing may tell you what your usable limit is. (Constantine and Lock-wood assert that having more than a dozen items usually is unnecessary, since "users are seldom able to make effective use of more levels."[2] Expert users of high-powered software might tell you differently. As always, know your users.) [2] See Larry Constantine and Lucy Lockwood, "Instructive Interaction: Making Innovative Interfaces Self-Teaching," at http://foruse.com/articles/instructive.htm.
5.2.8.4.3. PRESENTATION Finally, decide how to present the undo stack to the user. Most desktop applications put Undo/Redo items on the Edit menu. Also, Undo usually is hooked up to Control-Z or its equivalent. The most well-behaved applications use Smart Menu Items to tell the user exactly which operation is next up on the undo stack. But see the screenshot at the top of this pattern (Figure 5-20) for a different, more visual presentation. Photoshop shows a scrolling list of the undoable operationsincluding ones that were already undone (one is shown, in gray). It lets the user pick the point in the stack that they want to revert to. A visual command history like this can be quite useful, even just as a reminder of what you've recently done. See the Command History pattern for more information. 5.2.8.5. examples Figure 5-21. A more typical presentation of Multi-Level Undo. In this case, the user typed some text, and then inserted a table. The first Undo removes the table. Once that's done, the following Undothe next action in the undo stackis the typed text, and invoking Undo again removes that text. Meanwhile, the user has the opportunity to "undo the undo" with the Redo menu item. If we're at the top of the stack (as in the first screenshot), then there is no Redo, and that menu item is overloaded with a Repeat action.
Confusing? You bet. Most users never will develop a clear mental picture of the algorithms used here; most people don't know what a "stack" is, let alone how it is used in conjunction with Repeat and Redo. That's why the Smart Menu Items are absolutely critical to usability here. They explain exactly what's going to happen, which reduces the cognitive burden on the user. 
52. command history Figure 5-22. MATLAB's command history, shown in the lower left 
5.2.9.1. what As the user performs actions, keep a visible record of what was done, to what, and when. 5.2.9.2. use when Users perform long and complex sequences of actions, either with a GUI or a command line. Most users are fairly experienced, or if not, they at least want an efficient interface that's supportive of long-term and recurring work. Graphical editors and programming environments usually are good candidates for this pattern. 5.2.9.3. why Sometimes a user needs to remember or review what he did in the course of working with the software. For instance, he may want to do any of these things: Repeat an action or command done earlier, one he doesn't remember well Recall the order in which some actions were done Repeat a sequence of operations, originally done to one object, on a different object Keep a log of his actions, for legal or security reasons Convert an interactive series of commands into a script or macro (see the Macros pattern in this chapter)
Computers are good at keeping an accurate record of steps taken; people aren't. Take advantage of that. 5.2.9.4. how Keep a running list of the actions taken by the user. If the interface is driven from a command line, then you have it easyjust record everything typed there. See Figure 5-22. If you can, keep track of the history across sessions, so the user can see what was done even a week ago or longer. If it's a graphic interface, or a combination of graphic and command-line interfaces, then things get a little more complicated. Find a way to express each action in one consistent, concise way, usually with words (though there's no reason why it can't be done visually). Make sure you define these with the right granularityif one action is done en masse to seventeen objects, record it as one action, not seventeen. What commands should you record, and which ones shouldn't you? See the Multi-Level Undo pattern for a thorough discussion of what commands should "count." If a command is undoable, it should be recorded in the history. Finally, display the history to the user. That display should be optional in most software, since it will almost certainly play a supporting role in the user's work, not a starring role. Lists of commandsoldest to newesttend to work well. If you'd like, you could timestamp the history display somehow. MATLAB, shown in Figure 5-22, puts a date and time into the history whenever the program restarts. 5.2.9.5. examples Figure 5-23. Unix and its many variants use shell programs, such as tcsh and bash, that keep track of their own command histories in files. The user can call it up with the "history" command, as shown here. The history also is accessible through various command-line constructs, like "!!" (reuse the last command), "!3" (reuse the command issued three commands ago), and Control-P, which you can issue repeatedly to show the previous commands one at a time. 
Figure 5-24. Photoshop's undo stack, also seen in the Multi-Level Undo pattern, is effectively a command history. You can use it to undo what you did, but you don't have to; you can just look at it and scroll through it, reviewing what you did. It uses icons to identify different classes of actions, which is unusual, but nice to use. 
53. macros Figure 5-25. Photoshop's actions list 
5.2.10.1. what Macros are single actions composed of other, smaller actions. Users can create them by putting together sequences of actions. 5.2.10.2. use when Users want to repeat long sequences of actions or commands. They might want to loop over lists of files, images, database records, or other objects, for instance, doing the same things to each object. You might already have implemented Multi-Level Undo or Command History. 5.2.10.3. why No one wants to perform the same set of repetitive interactive tasks over, and over, and over again! This is exactly what computers are supposed to be good at. Chapter 1 described a user-behavior pattern called Streamlined Repetition; macros are precisely the kind of mechanism that can support that well. Macros obviously help users work faster. However, by reducing the number of commands or gestures needed to get something done, they also reduce the possibility of finger-slips, oversights, and similar mistakes. You might also recall the concept of "flow," also discussed in Chapter 1. When a user can compress a long sequence of actions down to a single command or keyboard shortcut, the experience of flow is enhancedthe user can accomplish more with less effort and time, and she can keep her larger goals in sight without getting bogged down in details 5.2.10.4. how Provide a way for the user to "record" a sequence of actions and easily "play them back" at any time. The playback should be as easy as giving a single command, pressing a single button, or dragging and dropping an object. 5.2.10.4.1. DEFINING THE MACRO The user should be able to give the macro a name of her choice. Let her review the action sequence somehow, so she can check her work or revisit a forgotten sequence to see what it did (as in the Command History pattern). Make it possible for one macro to refer to another so they can build on each other. Users will want to save macros from one day to the next, so make sure they're persistentsave them to files or a database. Present them in a searchable, sortable, and even categorizable list, depending on your users' needs. 5.2.10.4.2. RUNNING THE MACRO The macro itself could be played back literally, to keep things simple; or, if it acts upon an object that can change from one invocation to another, you could allow the sequence to be parameterized (e.g., use a placeholder or variable instead of a literal object). Macros also should be able to act on many things at once. How the names of the macros (or the controls that launch them) are presented depends heavily upon the nature of the application, but consider displaying them with built-in actions rather than making them second-class citizens. The ability to record these sequences, plus the facility for macros to build on one another, create the potential for a user to invent entirely new linguistic or visual grammara grammar that is finely tuned to their own environment and work habits. This is a very powerful capability. In reality, it's programming; but if your users don't think of themselves as programmers, don't call it that or you'll scare them off. ("I don't know how to program anything; I must not be able to do this.") 5.2.10.5. examples Figure 5-26. Microsoft Excel allows macros to be recorded, named, stored along with the document, and even assigned to a keyboard shortcut. The user also can choose to run it from a button on the toolbar, or an ActiveX control in the document itself (which means you can use them as callbacks for buttons or text fields). 
Figure 5-27. These Excel macros are written in Visual Basic, and the user can hand-edit them if desired. This is when it becomes programming. Because Visual Basic provides access to so much general-purpose functionalitymost of it not directly related to spreadsheet operationsmacros can be a serious security risk for Office applications. By sharply constraining the functionality available to macros and limiting the number of ways users can run macros (e.g., clicking on toolbar buttons), you can trade power for safety. 
|
