226
Part II: Designing Behavior and Form
DESIGN
Don’t weld on training wheels.
principle
“Pure” excise
Many actions are excise of such purity that nobody needs them, from power users to first-timers. These include most hardware-management tasks that the computer could handle itself, like telling an application which COM port to use. Any demands for such information should be struck from user interfaces and replaced with more intelligent application behavior behind the scenes.
Visual excise
Visual excise is the work that a user has to do to decode visual information, such as finding a single item in a list, figuring out where to begin reading on a screen, or determining which elements on it are clickable and which are merely decoration.
Designers sometimes paint themselves into excise corners by relying too heavily on visual metaphors. Visual metaphors such as desktops with telephones, copy machines, staplers, and fax machines — or file cabinets with folders in drawers —
are cases in point. These visual metaphors may make it easy to understand the relationships between interface elements and behaviors, but after users learn these fundamentals, managing the metaphor becomes pure excise (for more discussion on the limitations of visual metaphors, see Chapter 13). In addition, the screen space consumed by the images becomes increasingly egregious, particularly in sovereign posture applications (see Chapter 9 for an extensive discussion of the concept of posture). The more we stare at the application from day to day, the more we resent the number of pixels it takes to tell us what we already know. The little telephone that so charmingly told us how to dial on that first day long ago is now a barrier to quick communication.
Users of transient posture applications often require some instruction to use the product effectively. Allocating screen real estate to this effort typically does not contribute to excise in the same way as it does in sovereign applications. Transient posture applications aren’t used frequently, so their users need more assistance understanding what the application does and remembering how to control it. For sovereign posture applications, however, the slightest excise becomes agonizing
16_084113 ch11.qxp 4/3/07 6:05 PM Page 227
Chapter 11: Eliminating Excise
227
over time. Another significant source of visual excise is the use of excessively stylized graphics and interface elements (see Figure 11-1). The use of visual style should always be primarily in support of the clear communication of information and interface behavior.
Depending on the application, some amount of ornamentation may also be desirable to create a particular mood, atmosphere, or personality for the product. However, excessive ornamentation can detract from users’ effectiveness by forcing them to decode the various visual elements to understand which are controls and critical information and which are mere ornaments. For more about striking the right balance to create effective visual interface designs, see Chapter 14.
Figure 11-1 The home page at Disney.com provides a good example of visual excise. Text is highly stylized and doesn’t follow a layout grid. It’s difficult for users to differentiate between décor and navigational elements. This requires users to do visual work to interact with the site. This isn’t always a bad thing — just the right amount of the right kind of work can be a good source of entertainment (take puzzles, for example).
16_084113 ch11.qxp 4/3/07 6:05 PM Page 228
228
Part II: Designing Behavior and Form
Determining what is excise
Certain tasks are mainly excise but can be useful for occasional users or users with special preferences. In this case, consider the function excise if it is forced on a user rather than made available at his discretion. An example of this kind of function is windows management. The only way to determine whether a function or behavior such as this is excise is by comparing it to personas’ goals. If a significant persona needs to see two applications at a time on the screen in order to compare or transfer information, the ability to configure the main windows of the applications so that they share the screen space is not excise. If your personas don’t have this specific goal, the work required to configure the main window of either application is excise.
Stopping the Proceedings
One form of excise is so prevalent that it deserves special attention. In the previous chapter, we introduced the concept of flow, whereby a person enters a highly productive mental state by working in harmony with her tools. Flow is a natural state, and people will enter it without much prodding. It takes some effort to break into flow after someone has achieved it. Interruptions like a ringing telephone will do it, as will an error message box. Some interruptions are unavoidable, but most others are easily dispensable. But interrupting a user’s flow for no good reason is stopping the proceedings with idiocy and is one of the most disruptive forms of excise.
DESIGN
Don’t stop the proceedings with idiocy.
principle
Poorly designed software will make assertions that no self-respecting individual would ever make. It states unequivocally, for example, that a file doesn’t exist merely because it is too stupid to look for it in the right place, and then it implicitly blames you for losing it! An application cheerfully executes an impossible query that hangs up your system until you decide to reboot. Users view such software behavior as idiocy, and with just cause.
Errors, notifiers, and confirmation messages
There are probably no more prevalent excise elements than error message and confirmation message dialogs. These are so ubiquitous that eradicating them takes a lot of work. In Chapter 25, we discuss these issues at length, but for now, suffice it to
16_084113 ch11.qxp 4/3/07 6:05 PM Page 229
Chapter 11: Eliminating Excise
229
say that they are high in excise and should be eliminated from your applications whenever possible.
The typical error message box is unnecessary. It either tells a user something that he doesn’t care about or demands that he fix some situation that the application can and should usually fix just as well. Figure 11-2 shows an error message box displayed by Adobe Illustrator 6 while a user is trying to save a document. We’re not exactly sure what it’s trying to tell us, but it sounds dire.
Figure 11-2 This is an ugly, useless error message box that stops the proceedings with idiocy. You can’t verify or identify what it tells you, and it gives you no options for responding other than to admit your own culpability with the OK button. This message comes up only when the application is saving; that is, when you have entrusted it to do something simple and straightforward. The application can’t even save a file without help, and it won’t even tell you what help it needs.
The message stops an already annoying and time-consuming procedure, making it take even longer. A user cannot reliably fetch a cup of coffee after telling the application to save his artwork, because he might return only to see the function incomplete and the application mindlessly holding up the process. We discuss how to eliminate these sorts of error messages in Chapter 25.
Another frustrating example, this time from Microsoft Outlook, is shown in Figure 11-3.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 230
230
Part II: Designing Behavior and Form
Figure 11-3 Here is a horrible confirmation box that stops the proceedings with idiocy. If the application is smart enough to detect the difference, why can’t it correct the problem itself? The options the dialog offers are scary. It is telling you that you can explode one of two boxes: one contains garbage, and the other contains the family dog — but the application won’t say which is which. And if you click Cancel, what does that mean? Will it still go ahead and explode your dog?
This dialog is asking you to make an irreversible and potentially costly decision based on no information whatsoever! If the dialog occurs just after
you changed some rules, doesn’t it stand to reason that you want to keep them? And if you don’t, wouldn’t you like a bit more information, like exactly what rules are in conflict and which of them are the more recently created? You also don’t have a clear idea what happens when you click Cancel. . . . Are you canceling the dialog and leaving the rules mismatched? Are you discarding recent changes that led to the mismatch? The kind of fear and uncertainty that this poorly designed interaction arouses in users is completely unnecessary. We discuss how to improve this kind of situation in Chapter 24.
Making users ask permission
Back in the days of command lines and character-based menus, interfaces indirectly offered services to users. If you wanted to change an item, such as your address, first you explicitly had to ask the application permission to change it. The application would then display a screen where your address could be changed. Asking permission is pure excise, and unfortunately things haven’t changed much — if you want to change one of your saved addresses on Amazon.com, you have to click a button and go to a different page. If you want to change a displayed value, you should be able to change it right there. You shouldn’t have to ask permission or go to a different room.
DESIGN
Don’t make users ask permission.
principle
16_084113 ch11.qxp 4/3/07 6:05 PM Page 231
Chapter 11: Eliminating Excise
231
As in the last example, many applications have one place where the values (such as filenames, numeric values, and selected options) are displayed for output and another place where user input to them is accepted. This follows the implementation model, which treats input and output as different processes. A user’s mental model, however, doesn’t recognize a difference. He thinks, “There is the number. I’ll just click on it and enter a new value.” If the application can’t accommodate this impulse, it is needlessly inserting excise into the interface. If options are modifiable by a user, he should be able to do so right where the application displays them.
DESIGN
Allow input wherever you have output.
principle
The opposite of asking permission can be useful in certain circumstances. Rather than asking the application to launch a dialog, a user tells a dialog to go away and not come back again. In this way, a user can make an unhelpful dialog box stop badgering him, even though the application mistakenly thinks it is helping. Microsoft now makes heavy use of this idiom. (If a beginner inadvertently dismisses a dialog box and can’t figure out how to get it back, he may benefit from another easy-to-identify safety-net idiom in a prominent place: a Help menu item saying, “Bring back all dismissed dialogs,” for example.)
Common Excise Traps
You should be vigilant in finding and rooting out each small item of excise in your interface. These myriad little extra unnecessary steps can add up to a lot of extra work for users. This list should help you spot excise transgressions:
Don’t force users to go to another window to perform a function that affects the current window.
Don’t force users to remember where they put things in the hierarchical file system.
Don’t force users to resize windows unnecessarily. When a child window pops up on the screen, the application should size it appropriately for its contents. Don’t make it big and empty or so small that it requires constant scrolling.
Don’t force users to move windows. If there is open space on the desktop, put the application there instead of directly over some other already open program.
Don’t force users to reenter their personal settings. If a person has ever set a font, a color, an indentation, or a sound, make sure that she doesn’t have to do it again unless she wants a change.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 232
232
Part II: Designing Behavior and Form
Don’t force users to fill fields to satisfy some arbitrary measure of completeness. If a user wants to omit some details from the transaction entry screen, don’t force him to enter them. Assume that he has a good reason for not entering them. The completeness of the database (in most instances) isn’t worth badgering users over.
Don’t force users to ask permission. This is frequently a symptom of not allowing input in the same place as output.
Don’t ask users to confirm their actions (this requires a robust undo facility).
Don’t let a user’s actions result in an error.
Navigation Is Excise
The most important thing to realize about navigation is that it is largely excise.
Except in the case of games where the goal is to navigate successfully through a maze of obstacles, the work that users are forced to do to get around in software and on Web sites is seldom aligned with their needs, goals, and desires. (Though it should be noted that well-designed navigation can be an effective way to instruct users about what is available to them, which is certainly much more aligned with their goals.)
Unnecessary or difficult navigation is a major frustration to users. In fact, in our opinion, poorly designed navigation presents one of the largest and most common problems in the usability of interactive products — desktop, Web-based, or otherwise. It is also the place where the programmer’s implementation model is typically made most apparent to users.
Navigation through software occurs at multiple levels:
Among multiple windows, views, or pages
Among panes or frames within a window, view, or page
Among tools, commands, or menus
Within information displayed in a pane or frame (for example: scrolling, panning, zooming, following links)
While you may question the inclusion of some of these bullets as types of navigation, we find it useful to think in terms of a broad definition of navigation: any action that takes a user to a new part of the interface or which requires him to locate objects, tools, or data. The reason for this is simple: These actions require people to understand where they are in an interactive system and how to find and actuate what they want. When we start thinking about these actions as navigation, it becomes clear that they are excise and should, therefore, be minimized or eliminated. The following sections discuss each of these types of navigation in more detail.
16_084113 ch11.qxp 4/3/07 6:05 PM Page 233
Chapter 11: Eliminating Excise
233
Navigation among multiple screens,
views, or pages
Navigation among multiple application views or Web pages is perhaps the most disorienting kind of navigation for users. It involves a gross shifting of attention that disrupts a user’s flow and forces him into a new context. The act of navigating to another window also often means that the contents of the original window are partly or completely obscured. At the very least, it means that a user needs to worry about window management, an excise task that further disrupts his flow. If users must constantly shuttle back and forth between windows to achieve their goals, their disorientation and frustration levels will rise, they will become distracted from the task at hand, and their effectiveness and productivity will drop.
If the number of windows is large enough, a user will become sufficiently disoriented that he may experience navigational trauma: He gets lost in the interface.
Sovereign posture applications can avoid this problem by placing all main interactions in a single primary view, which may contain multiple independent panes.
Navigation between panes
Windows can contain multiple panes — adjacent to each other and separated by splitters (see Chapters 19 and 20) or stacked on top of each other and denoted by tabs. Adjacent panes can solve many navigation problems because they provide useful supporting functions, links, or data on the screen in close reach of the primary work or display area, thus reducing navigation to almost nil. If objects can be dragged between panes, those panes should be adjacent to each other.
Problems arise when adjacent supporting panes bec
ome too numerous or are not placed on the screen in a way that matches users’ workflows. Too many adjacent panes result in visual clutter and confusion: Users do not know where to go to find what they need. Also, crowding forces scrolling, which is another navigational hit.
Navigation within the single screen thus becomes a problem. Some Web portals, trying to be everything to everyone, have such navigational problems.
In some cases, depending on user workflows, tabbed panes can be appropriate.
Tabbed panes include a level of navigational excise and potential for user disorientation because they obscure what was on the screen before the user navigated to them. However, this idiom is appropriate for the main work area when multiple documents or independent views of a document are required (such as in Microsoft Excel; see Figure 11-4).
16_084113 ch11.qxp 4/3/07 6:05 PM Page 234
234
Part II: Designing Behavior and Form
Figure 11-4 Microsoft Excel makes use of tabbed panes (visible in the lower left) to let users navigate between related worksheets. Excel also makes use of splitters to provide adjacent panes for viewing multiple, distant parts of a single spreadsheet without constant scrolling. Both these idioms help reduce navigational excise for Excel users.
Some programmers use tabs to break complex product capabilities into smaller chunks. They reason that using these capabilities will somehow become easier if the functionality is cut into bite-sized pieces. Actually, putting parts of a single facility onto separate panes increases excise and decreases users’ understanding and orientation.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 33