In a typical print operation, for example, an application begins sending the 20
pages of a report to the printer and simultaneously puts up a print process dialog box with a Cancel button. If the user quickly realizes that he forgot to make an important change, he clicks the Cancel button just as the first page emerges from the printer. The application immediately cancels the print operation. But unbe-knownst to the user, while the printer was beginning to work on page 1, the computer has already sent 15 pages into the printer’s buffer. The application cancels the last five pages, but the printer doesn’t know anything about the cancellation; it just knows that it was sent 15 pages, so it goes ahead and prints them. Meanwhile, the application smugly tells the user that the function was canceled. The application lies, as the user can plainly see.
The user isn’t very sympathetic to the communication problems between the application and the printer. He doesn’t care that the communications are one-way. All he knows is that he decided not to print the document before the first page appeared in the printer’s output basket, he clicked the Cancel button, and then the stupid application continued printing for 15 pages even though he acted in plenty of time to stop it. It even acknowledged his Cancel command. As he throws the 15 wasted sheets of paper in the trash, he growls at the stupid application.
Imagine what his experience would be if the application could communicate with the print driver and the print driver could communicate with the printer. If the software were smart enough, the print job could easily have been abandoned before the second sheet of paper was wasted. The printer certainly has a Cancel function — it’s just that the software was built to be too indolent to use it.
17_084113 ch12.qxp 4/3/07 6:06 PM Page 260
260
Part II: Designing Behavior and Form
Designing Smart Products
In addition to being considerate, helpful products and people must also be smart.
Thanks to science fiction writers and futurists, there is some confusion about what it means for an interactive product to be smart. Some naive observers think that smart software is actually capable of behaving intelligently.
While this would certainly be nice, the fact of the matter is that our silicon-enabled tools are still a ways away from delivering on that dream. A more useful understanding of the term (if you’re trying to ship a product this decade) is that these products are capable of working hard even when conditions are difficult and even when users aren’t busy. Regardless of our dreams of thinking computers, there is a much greater and more immediate opportunity to get our computers to work harder. The remainder of this chapter discusses some of the most important ways that software can work a bit harder to serve humans better.
Putting the idle cycles to work
Because every instruction in every application must pass single-file through the CPU, we tend to optimize our code for this needle’s eye. Programmers work hard to keep the number of instructions to a minimum, ensuring snappy performance for users. What we often forget, however, is that as soon as the CPU has hurriedly finished all its work, it waits idle, doing nothing, until the user issues another command. We invest enormous efforts in reducing the computer’s reaction time, but we invest little or no effort in putting it to work proactively when it is not busy reacting to the user. Our software commands the CPU as though it were in the army, alternately telling it to hurry up and wait. The hurry up part is great, but the waiting needs to stop.
In our current computing systems, users need to remember too many things, such as the names they give to files and the precise location of those files in the file system. If a user wants to find that spreadsheet with the quarterly projections on it again, he must either remember its name or go browsing. Meanwhile, the processor just sits there, wasting billions of cycles.
Most current software also takes no notice of context. When a user is struggling with a particularly difficult spreadsheet on a tight deadline, for example, the application offers precisely as much help as it offers when he is noodling with numbers in his spare time. Software can no longer, in good conscience, waste so much idle time while users work. It is time for our computers to begin to shoulder more of the burden of work in our day-to-day activities.
17_084113 ch12.qxp 4/3/07 6:06 PM Page 261
Chapter 12: Designing Good Behavior
261
Most users in normal situations can’t do anything in less than a few seconds. That is enough time for a typical desktop computer to execute at least a billion instructions. Almost without fail, those interim cycles are dedicated to idling. The processor does nothing except wait. The argument against putting those cycles to work has always been: “We can’t make assumptions; those assumptions might be wrong.”
Our computers today are so powerful that, although the argument is still true, it is frequently irrelevant. Simply put, it doesn’t matter if the application’s assumptions are wrong; it has enough spare power to make several assumptions and discard the results of the bad ones when the user finally makes his choice.
With Windows and Mac OS X’s preemptive, threaded multitasking and multicore, multichip computers, you can perform extra work in the background without significantly affecting the performance most users see. The application can launch a search for a file, and if the user begins typing, merely abandon it until the next hiatus. Eventually, the user stops to think, and the application will have time to scan the whole disk. The user won’t even notice. This is precisely the kind of behavior that makes Mac OS X’s Spotlight search capabilities vastly superior to that in those windows. Search results are almost instantaneous because the operating system takes advantage of downtime to index the hard drive.
Every time an application puts up a modal dialog box, it goes into an idle waiting state, doing no work while the user struggles with the dialog. This should never happen. It would not be hard for the dialog box to hunt around and find ways to help. What did the user do last time? The application could, for example, offer the previous choice as a suggestion for this time.
We need a new, more proactive way of thinking about how software can help people reach their goals and complete their tasks.
Smart products have a memory
When you think about it, it’s pretty obvious that for a person to perceive an interactive product as considerate and smart, that product must have some knowledge about the person and be capable of learning from their behavior. Looking through the characteristics of considerate products presented earlier reinforces this fact: For a product to be truly helpful and considerate it must remember important things about the people interacting with it.
Quite often, software is difficult to use because it operates according to rational, logical assumptions that, unfortunately, are very wrong. Programmers and designers often assume that the behavior of users is random and unpredictable, and that users must be continually interrogated to determine the proper course of
17_084113 ch12.qxp 4/3/07 6:06 PM Page 262
262
Part II: Designing Behavior and Form
action. Although human behavior certainly isn’t deterministic like that of a digital computer, it is rarely random, and asking silly questions is predictably frustrating for users.
If your application, Web site, or device could predict what a user is going to do next, couldn’t it provide a better interaction? If your application could know which selections the user will make in a particular dialog box or form, couldn’t that part of the interface be skipped? Wouldn’t you consider advance knowledge of what actions your users take to be an awesome secret weapon of interface design?
Well, you can predict what your users will do. You can build a sixth sense into your application that will tell it with uncanny accuracy exactly what the user will do next! All those billions of wasted processor cycles can be put to great use: All you need to do is give your interface a memory.
When we use the term memory in this context, we don’t mean RAM, bu
t rather a facility for tracking and responding to user actions over multiple sessions. If your application simply remembers what the user did the last several times (and how), it can use that as a guide to how it should behave the next time.
If we enable our products with an awareness of user behavior, a memory, and the flexibility to present information and functionality based upon previous user actions, we can realize great advantages in user efficiency and satisfaction. We would all like to have an intelligent and self-motivated assistant who shows initiative, drive, good judgment, and a keen memory. A product that makes effective use of its memory is more like that self-motivated assistant, remembering helpful information and personal preferences without needing to ask. Simple things can make a big difference: the difference between a product your users tolerate and one that they love. The next time you find your application asking your users a question, make it ask itself one instead.
You might think that bothering with a memory isn’t necessary; it’s easier to just ask the user each time. Many programmers are quick to pop up a dialog box to request any information that isn’t lying conveniently around. But as we discussed in Chapter 10, people don’t like to be asked questions. Continually interrogating users is not only a form of excise, but also, from a psychological perspective, it is a subtle way of expressing doubt about their authority.
Most software is forgetful, remembering little or nothing from execution to execution. If our applications are smart enough to retain any information during and between uses, it is usually information that makes the job easier for the programmer and not for the user. The application willingly discards information about the way it was used, how it was changed, where it was used, what data it processed, who used
17_084113 ch12.qxp 4/3/07 6:06 PM Page 263
Chapter 12: Designing Good Behavior
263
it, and whether and how frequently the various facilities of the application were used. Meanwhile, the application fills initialization files with driver names, port assignments, and other details that ease the programmer’s burden. It is possible to use the exact same facilities to dramatically increase the smarts of your software from the perspective of the user.
Task coherence
Predicting what a user will do by remembering what he did last is based on the principle of task coherence: the idea that our goals and the way we achieve them (via tasks) is generally similar from day to day. This is not only true for tasks like brushing our teeth and eating our breakfasts, but it also describes how we use our word processors, e-mail applications, cell phones, and enterprise software.
When a consumer uses your product, there is a good chance that the functions he uses and the way he uses them will be very similar to what he did in previous uses of the product. He may even be working on the same documents, or at least the same types of documents, located in similar places. Sure, he won’t be doing the exact same thing each time, but his tasks will likely be variants of a limited number of repeated patterns. With significant reliability, you can predict the behavior of your users by the simple expedient of remembering what they did the last several times they used the application. This allows you to greatly reduce the number of questions your application must ask the user.
Sally, for example, though she may use Excel in dramatically different ways than Kazu, will tend to use Excel the same way each time. Although Kazu likes 9-point Times Roman and Sally prefers 12-point Helvetica and uses that font and size with dependable regularity. It isn’t really necessary for the application to ask Sally which font to use. A very reliable starting point would be 12-point Helvetica, every time.
Remembering choices and defaults
The way to determine what information the application should remember is with a simple rule: If it’s worth the user entering, it’s worth the application remembering.
If it’s worth the user entering, it’s worth the application remem-DESIGN
principle
bering.
Any time your application finds itself with a choice, and especially when that choice is being offered to a user, the application should remember the information from run to run. Instead of choosing a hard-wired default, the application can use the
17_084113 ch12.qxp 4/3/07 6:06 PM Page 264
264
Part II: Designing Behavior and Form
previous setting as the default, and it will have a much better chance of giving a user what he wanted. Instead of asking a user to make a determination, the application should go ahead and make the same determination a user made last time, and let her change it if it was wrong. Any options users set should be remembered, so that the options remain in effect until manually changed. If a user ignores aspects of an application or turns them off, they should not be offered again. The user will seek them out when and if he is ready for them.
One of the most annoying characteristics of applications without memories is that they are so parsimonious with their assistance regarding files and disks. If there is one place where users need help, it’s with files and disks. An application like Word remembers the last place a person looked for a file. Unfortunately, if she always puts her files in a directory called Letters, then edits a document template stored in the Template directory just one time, all her subsequent letters will be stored in the Template directory rather than in the Letters directory. So, the application must remember more than just the last place the files were accessed. It must remember the last place files of each type were accessed.
The position of windows should also be remembered, so if you maximized the document last time it should be maximized next time. If you positioned it next to another window, it is positioned the same way the next time without any instruction from the user. Microsoft Office applications now do a good job of this.
Remembering patterns
Users can benefit in several ways from a product with a good memory. Memory reduces excise, the useless effort that must be devoted to managing tools and not doing work. A significant portion of the total excise of an interface is in having to explain things to the application that it should already know. For example, in your word processor, you might often reverse-out text, making it white on black. To do this, you select some text and change the font color to white. Without altering the selection, you then set the background color to black. If the application paid enough attention, it would notice the fact that you requested two formatting steps without an intervening selection option. As far as you’re concerned, this is effectively a single operation. Wouldn’t it be nice if the application, upon seeing this unique pattern repeated several times, automatically created a new format style of this type — or better yet, created a new Reverse-Out toolbar control?
Most mainstream applications allow their users to set defaults, but this doesn’t fit the bill as a memory would. Configuration of this kind is an onerous process for all but power users, and many users will never understand how to customize defaults to their liking.
17_084113 ch12.qxp 4/3/07 6:06 PM Page 265
Chapter 12: Designing Good Behavior
265
Actions to remember
Everything that users do should be remembered. There is plenty of storage on our hard drives, and a memory for your application is a good investment of storage space. We tend to think that applications are wasteful because a big application might consume 200 MB of disk space. That is typical usage for an application, but not for user data. If your word processor saved 1 KB of execution notes every time you ran it, it still wouldn’t amount to much. Let’s say that you use your word processor 10 times every business day. There are approximately 200 workdays per year, so you run the application 2000 times a year. The net consumption is still only 2 MB, and that gives an exhaustive recounting of the entire year! This is probably not much more than the background image you put on your desktop.
File locations
All file-open facilities should remember where the user gets his files. Most users o
nly access files from a few directories for each given application. The application should remember these source directories and offer them on a combo box on the File Open dialog. The user should never have to step through the tree to a given directory more than once.
Deduced information
Software should not simply remember these kinds of explicit facts, but should also remember useful information that can be deduced from these facts. For example, if the application remembers the number of bytes changed in the file each time it is opened, it can help the user with some reasonableness checks. Imagine that the changed-byte-count for a file was 126, 94, 43, 74, 81, 70, 110, and 92. If the user calls up the file and changes 100 bytes, nothing would be out of the ordinary. But if the number of changed bytes suddenly shoots up to 5000, the application might suspect that something is amiss. Although there is a chance that the user has inadvertently done something about which he will be sorry, the probability of that is low, so it isn’t right to bother him with a confirmation dialog. It is, however, very reasonable for the application to make sure to keep a milestone copy of the file before the 5000 bytes were changed, just in case. The application probably won’t need to keep it beyond the next time the user accesses that file, because the user will likely spot any mistake that glaring immediately, and he would then demand an undo.
Multisession undo
Most applications discard their stack of undo actions when the user closes the document or the application. This is very shortsighted on the application’s part.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 37
