15_084113 ch10.qxp 4/3/07 6:05 PM Page 210
210
Part II: Designing Behavior and Form
Programmers tend to view possibilities as being the same as probabilities. For example, a user has the choice of ending the application and saving his work, or ending the application and throwing away the document he has been working on for the last six hours. Either of these choices is possible. Conversely, the probability of this person discarding his work is at least a thousand to one against, yet the typical application always includes a dialog box asking the user if he wants to save his changes, like the one shown in Figure 10-4.
Figure 10-4 This is easily the most unnecessary dialog box in the world of GUI.
Of course, we want to save our work! It is the normal course of events. Not saving it would be something out of the ordinary that should be handled by some dusty dialog box. This single dialog box does more to force users into knowing and understanding the useless and confusing facts about RAM and disk storage than anything else in their entire interaction with their computer. This dialog box should never be used.
The dialog box in Figure 10-4 is inappropriate and unnecessary. How often do you choose to abandon changes you make to a document? This dialog is tantamount to your spouse telling you not to spill soup on your shirt every time you eat. We’ll discuss the implications of removing this dialog in Chapter 17.
Programmers are judged by their ability to create software that handles the many possible, but improbable, conditions that crop up inside complex logical systems.
This doesn’t mean, however, that they should render that readiness to handle off-beat possibilities directly into a user interface. The obtrusive presence of edge case possibilities is a dead giveaway for user interfaces designed by programmers.
Dialogs, controls, and options that are used a hundred times a day sit side by side with dialogs, controls, and options that are used once a year or never.
You might get hit by a bus, but you probably will drive safely to work this morning.
You don’t stay home out of fear of the killer bus, so don’t let what might possibly happen alter the way you treat what almost certainly will happen in your interface.
DESIGN
Contextualize information.
principle
15_084113 ch10.qxp 4/3/07 6:05 PM Page 211
Chapter 10: Orchestration and Flow
211
The way that an application represents information is another way that it can obtrude noisily into a person’s consciousness. One area frequently abused is the representation of quantitative, or numeric, information. If an application needs to show the amount of free space on disk, it can do what the Microsoft Windows 3.x File Manager did: give you the exact number of free bytes, as shown in Figure 10-5.
Figure 10-5 The Windows 3.x File Manager took great pains to report the exact number of bytes used by files on the disk. Does this precision help us understand whether we need to clear space on the disk? Certainly not. Furthermore, is a seven-digit number the best way to indicate the disk’s status? Wouldn’t a graphical representation that showed the space usage in a proportional manner (like a pie chart) be more meaningful? Luckily, Microsoft Windows now uses pie charts to indicate disk usage.
In the lower-left corner, the application tells us the number of free bytes and the total number of bytes on the disk. These numbers are hard to read and hard to interpret. With more than ten thousand million bytes of disk storage, it ceases to be important to us just how many hundreds are left, yet the display rigorously shows us down to the kilobyte. But even while the application is telling us the state of our disk with precision, it is failing to communicate. What we really need to know is whether or not the disk is getting full, or whether we can add a new 20 MB application and still have sufficient working room. These raw numbers, precise as they are, do little to help make sense of the facts.
Visual presentation expert Edward Tufte says that quantitative presentation should answer the question, “Compared to what?” Knowing that 231,728 KB are free on your hard disk is less useful than knowing that it is 22% of the disk’s total capacity.
Another Tufte dictum is, “Show the data,” rather than simply telling about it textually or numerically. A pie chart showing the used and unused portions in different colors would make it much easier to comprehend the scale and proportion of hard disk use. It would show us what 231,728 KB really means. The numbers shouldn’t go away, but they should be relegated to the status of labels on the display and not be the display itself. They should also be shown with more reasonable and consistent precision. The meaning of the information could be shown visually, and the numbers would merely add support.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 212
212
Part II: Designing Behavior and Form
In Windows XP and Vista, Microsoft’s right hand giveth, while its left hand taketh away. The File Manager shown in Figure 10-5 is long dead, replaced by the Explorer dialog box shown in Figure 10-6. This replacement is the properties dialog associated with a hard disk. The Used Space is shown in blue and the Free Space is shown in magenta, making the pie chart an easy read. Now you can see at a glance the glad news that GranFromage is mostly empty.
Figure 10-6 In Windows XP and Vista, Microsoft has replaced the electric chair with lethal injection. Instead of long, inscrutable numbers at the bottom of the File Manager, you can request a Properties dialog box from Windows Explorer.
The good news is that you can finally see how your disk is doing in a meaningful, graphic way with the pie chart. The bad news is that you have to stop what you’re doing and open a dialog box to see fundamental information that should be readily available. In Windows 2000, this graph was automatically displayed on the left side of the Explorer window when a disk was selected; XP’s solution represents a step backwards.
Unfortunately, that pie chart isn’t built into the Explorer’s interface. Instead, you have to seek it out with a menu item. To see how full a disk is, you must bring up a modal dialog box that, although it gives you the information, takes you away from
15_084113 ch10.qxp 4/3/07 6:05 PM Page 213
Chapter 10: Orchestration and Flow
213
the place where you need to know it. The Explorer is where you can see, copy, move, and delete files, but it’s not where you can easily see if things need to be deleted.
That pie chart should have been built into the face of the Explorer. In Windows 2000, it was shown on the left-hand side when you selected a disk in an Explorer window. In XP, however, Microsoft took a step backwards, and the graphic has once again been relegated to a dialog. It really should be visible at all times in the Explorer, along with the numerical data, unless a user chooses to hide it.
DESIGN
Provide direct manipulation and graphical input.
principle
Software frequently fails to present numerical information in a graphical way. Even rarer is the capability of software to enable graphical input. A lot of software lets users enter numbers, then, on command, it converts those numbers into a graph.
Few products let a user draw a graph and, on command, convert that graph into a vector of numbers. By contrast, most modern word processors let you set tabs and indentations by dragging a marker on a ruler. Someone can say, in effect, “here is where I want the paragraph to start,” and let the application calculate that it is precisely 1.347 inches in from the left margin instead of forcing a user to enter 1.347.
This principle applies in a variety of situations. When items in a list need to be reordered, a user may want them ordered alphabetically, but he may also want them in order of personal preference; something no algorithm can offer. A user should be able to drag the items into the desired order directly, without an algorithm interfering with this fundamental operation.
DESIGN
Reflect object and application status.
principle
Whe
n someone is asleep, he usually looks asleep. When someone is awake, he looks awake. When someone is busy, he looks busy: His eyes are focused on his work and his body language is closed and preoccupied. When someone is unoccupied, he looks unoccupied: His body is open and moving, his eyes are questing and willing to make contact. People not only expect this kind of subtle feedback from each other, they depend on it for maintaining social order.
Our applications and devices should work the same way. When an application is asleep, it should look asleep. When an application is awake, it should look awake, and when it’s busy, it should look busy. When the computer is engaged in some significant internal action like performing a complex calculation and connecting to a
15_084113 ch10.qxp 4/3/07 6:05 PM Page 214
214
Part II: Designing Behavior and Form
database, it should be obvious to us that it won’t be quite as responsive as usual.
When the computer is sending a fax, we should see a small representation of the fax being scanned and sent (or at least a modeless progress bar).
Similarly, the status of user interface objects should be apparent to users. Most e-mail programs do a good job making it obvious which messages have not been read and which have been responded to or forwarded. Taking this concept a step further, wouldn’t it be great if, when you were looking at events on a calendar in Microsoft Outlook or IBM Lotus Notes, you could tell how many people had agreed to attend and how many hadn’t responded yet?
Application and object state is best communicated using forms of rich modeless feedback, briefly discussed earlier in this chapter. More detailed examples of rich modeless feedback may be found in Chapter 25.
DESIGN
Avoid unnecessary reporting.
principle
For programmers, it is important to know exactly what is happening in a program.
This is necessary to be able to control all the details of the program. For users, it is disconcerting and distracting to know all the details of what is happening. Nontechnical people may be alarmed to hear that the database has been modified, for example. It is better for the application to just do what has to be done, issue reassuring clues when all is well, and not burden users with the trivia of how it was accomplished.
Many applications are quick to keep users apprised of the details of their progress even though a user has no idea what to make of this information. Applications pop up dialog boxes telling us that connections have been made, that records have been posted, that users have logged on, that transactions were recorded, that data have been transferred, and other useless factoids. To software engineers, these messages are equivalent to the humming of the machinery, the babbling of the brook, the white noise of the waves crashing on the beach: They tell us that all is well. They were, in fact, probably used while debugging the software. To a normal person, however, these reports can be like eerie lights beyond the horizon, like screams in the night, like unattended objects flying about the room.
As discussed before, the application should make clear that it is working hard, but the detailed feedback can be offered in a more subtle way. In particular, reporting information like this with a modal dialog box brings the interaction to a stop with no particular benefit.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 215
Chapter 10: Orchestration and Flow
215
It is important that we not stop the proceedings to report normalcy. When some event has transpired that was supposed to have transpired, never report this fact with a dialog box. If you must use them at all, reserve dialogs for events that are outside of the normal course of events.
DESIGN
Don’t use dialogs to report normalcy.
principle
By the same token, don’t stop the proceedings and bother a user with problems that are not serious. If the application is having trouble creating a connection to a server, don’t put up a dialog box to report it. Instead, build a status indicator into the application so the problem is clear to the interested user but is not obtrusive to someone who is busy elsewhere.
The key to orchestrating a user interaction is to take a goal-directed approach. You must ask yourself whether a particular interaction moves a person rapidly and directly to his goal. Contemporary applications are often reluctant to take any forward motion without a person directing them in advance. But most people would rather see the application take some “good enough” first step and then adjust it to what is desired. This way, the application has moved a person closer to his goal.
DESIGN
Avoid blank slates.
principle
It’s easy to assume nothing about what your users want, and rather, ask a bunch of questions up front to help determine what they want. How many applications have you seen that start with a big dialog asking a bunch of questions? But normal people — not power users — aren’t always capable or comfortable explaining what they want to an interactive product. They would much rather see what the application thinks is right and then manipulate that to make it exactly right. In most cases, your application can make a fairly correct assumption based on past experience.
For example, when you create a new document in Microsoft Word, the application creates a blank document with preset margins and other attributes rather than opening a dialog that asks you to specify every detail. PowerPoint does a less adequate job, asking you to choose the base style for a new presentation each time you create one. Both applications could do better by remembering frequently and recently used styles or templates, and making those the defaults for new documents.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 216
216
Part II: Designing Behavior and Form
DESIGN
Ask for forgiveness, not permission.
principle
Just because we use the word think in conjunction with an interactive product doesn’t mean that the software needs to be intelligent (in the human sense) and try to determine the right thing to do by reasoning. Instead, it should simply do something that has a statistically good chance of being correct and then provide a user with powerful tools for shaping that first attempt, instead of merely giving the user a blank slate and challenging him to have at it. This way the application isn’t asking for permission to act but rather for forgiveness after the fact.
For most people, a completely blank slate is a difficult starting point. It’s so much easier to begin where someone has already left off. A user can easily fine-tune an approximation provided by the application into precisely what he desires with less risk of exposure and mental effort than he would have from drafting it from nothing. As we discuss in Chapter 11, endowing your application with a good memory is the best way to accomplish this.
DESIGN
Differentiate between command and configuration.
principle
Another problem crops up quite frequently whenever functions with many parameters are invoked by users. The problem comes from the lack of differentiation between a function and the configuration of that function. If you ask an application to perform a function itself, the application should simply perform that function and not interrogate you about your precise configuration details. To express precise demands to the program, you would request the configuration dialog.
For example, when you ask many applications to print a document, they respond by launching a complex dialog box demanding that you specify how many copies to print, what the paper orientation is, what paper feeder to use, what margins to set, whether the output should be in monochrome or color, what scale to print it at, whether to use PostScript fonts or native fonts, whether to print the current page, the current selection, or the entire document, and whether to print to a file and if so, how to name that file. All those options are useful, but all we wanted was to print the document, and that is all we thought we asked for.
A much more reasonable design would be to have a command to print and another co
mmand for print setup. The print command would not issue any dialog but would just go ahead and print, either using previous settings or standard, vanilla
15_084113 ch10.qxp 4/3/07 6:05 PM Page 217
Chapter 10: Orchestration and Flow
217
settings. The print setup function would offer up all those choices about paper and copies and fonts. It would also be very reasonable to be able to go directly from the configure dialog to printing.
The print control on the Word toolbar offers immediate printing without a dialog box. This is perfect for many people, but for those with multiple printers or printers on a network, it may offer too little information. A user may want to see which printer is selected before he either clicks the control or summons the dialog to change it first. This is a good candidate for some simple modeless output placed on a toolbar or status bar (it is currently provided in the ToolTip for the control, which is good, but the feedback could be better still). Word’s print setup dialog is called
“Print...” and is available from the File menu. Its name could be more descriptive, although the ellipsis does, according to GUI standards, give some inkling that it will launch a dialog.
There is a big difference between configuring and invoking a function. The former may include the latter, but the latter shouldn’t include the former. In general, any user invokes a command ten times for every one time he configures it. It is better to make a user ask explicitly for configuration one time in ten than it is to make a user reject the configuration interface nine times in ten.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 31
