DESIGN
No matter how cool your interface is, less of it would be better.
principle
Directing your attention to the interaction itself puts the emphasis on the side effects of the tools and technology rather than on the user’s goals. A user interface is an artifact, not directly associated with the goals of a user. Next time you find yourself crowing about what cool interaction you’ve designed, just remember that the ultimate user interface for most purposes is no interface at all.
To create a sense of flow, our interaction with software must become transparent.
When a novelist writes well, the craft of the writer becomes invisible, and the reader sees the story and characters with clarity undisturbed by the technique of the writer. Likewise, when a product interacts well with a person, interaction mechanics disappear, leaving the person face to face with his objectives, unaware of the intervening software. The poor writer is a visible writer, and a poor interaction designer looms with a clumsily visible presence in his software.
DESIGN
Well-orchestrated user interfaces are transparent.
principle
To a novelist, there is no such thing as a “good” sentence in isolation from the story being told. There are no rules for the way sentences should be constructed to be transparent. It all depends on what the protagonist is doing, or what effect the author wants to create. The writer knows not to insert an obscure word in a particularly quiet and sensitive passage, lest it sound like a sour note in a string quartet.
The same goes for software. The interaction designer must train himself to hear sour notes in the orchestration of software interaction. It is vital that all the elements in an interface work coherently together towards a single goal. When an application’s communication with a person is well orchestrated, it becomes almost invisible.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 203
Chapter 10: Orchestration and Flow
203
Webster defines orchestration as “harmonious organization,” a reasonable phrase for what we should expect from interactive products. Harmonious organization doesn’t yield to fixed rules. You can’t create guidelines like, “Five buttons on a dialog box are good” and “Seven buttons on a dialog box are too many.” Yet it is easy to see that a dialog box with 35 buttons is probably to be avoided. The major difficulty with such analysis is that it treats the problem in vitro. It doesn’t take into account the problem being solved; it doesn’t take into account what a person is doing at the time or what he is trying to accomplish.
Designing Harmonious Interactions
While there are no universal rules to define a harmonious interaction (just as there are no universal rules to define a harmonious interval in music), we’ve found these strategies to be effective at getting interaction design moving in the right direction: 1. Follow users’ mental models.
2. Less is more.
3. Enable users to direct, don’t force them to discuss.
4. Keep tools close at hand.
5. Provide modeless feedback.
6. Design for the probable; provide for the possible.
7. Provide comparisons.
8. Provide direct manipulation and graphical input.
9. Reflect object and application status.
10. Avoid unnecessary reporting.
11. Avoid blank slates.
12. Differentiate between command and configuration.
13. Provide choices.
14. Hide the ejector seat levers.
15. Optimize for responsiveness; accommodate latency.
Each principle is discussed in detail below.
DESIGN
Follow users’ mental models.
principle
15_084113 ch10.qxp 4/3/07 6:05 PM Page 204
204
Part II: Designing Behavior and Form
We introduced the concept of mental models in Chapter 2. Different people have different mental models of a given activity or process, but they rarely imagine them in terms of the detailed mechanics of how computers function. Each user naturally forms a mental image about how the software performs its task. The mind looks for some pattern of cause and effect to gain insight into the machine’s behavior.
For example, in a hospital information system, the physicians and nurses have a mental model of patient information that derives from how they think about patients and treatment. It therefore makes most sense to find patient information by using names of patients as an index. Each physician has certain patients, so it makes additional sense to filter the patients in the clinical interface so that each physician can choose from a list of her own patients, organized alphabetically by name. On the other hand, in the business office of the hospital, the clerks there are worried about overdue bills. They don’t initially think about these bills in terms of who or what the bill is for, but rather in terms of how late the bill is (and perhaps how big the bill is). Thus, for the business office interface, it makes sense to sort first by time overdue and perhaps by amount due, with patient names as a secondary organizational principle.
DESIGN
Less is more.
principle
For many things, more is better. In the world of interaction design, the contrary is true. We should constantly strive to reduce the number of elements in user interfaces without reducing the capabilities of the products we are creating. To do this, we must do more with less; this is where careful orchestration becomes important.
We must coordinate and control the power of the product without letting the interface become a gaggle of windows and dialogs, covered with a scattering of unrelated and rarely used controls.
It is very common for user interfaces to be complex but not very powerful. Products like this typically segregate functionality into silos and allow a user to perform a single task without providing access to related tasks. When the first edition of this book was published in 1995, this problem was ubiquitous. Something as common as a “Save” dialog in a Windows application failed to provide the ability for users to also rename or delete the files they were looking at. This required users to go to an entirely different place to accomplish these very similar tasks, ultimately requiring applications and operating systems to provide more interface. Thankfully, contemporary operating systems are much better at this sort of thing. Because they have started to offer appropriate functionality based upon a user’s context, users are less
15_084113 ch10.qxp 4/3/07 6:05 PM Page 205
Chapter 10: Orchestration and Flow
205
often required to shuffle off to various places in the interface to accomplish simple and common tasks.
We have, however, a rather long way to go. In our work we see a lot of enterprise software where each function or feature is housed in a separate dialog or window, with no consideration for the way people must use these functions together to accomplish something. It is not uncommon for a user to use one menu command to open a window to find a bit of information, copy that information to the clip-board, and then use a different menu command for a different window, merely to paste that bit of information in a field. Not only is this inelegant and crude, but it is error-prone and fails to capitalize on a productive division of labor between humans and machines. Typically, products don’t end up this way on purpose —
they have either been built in an ad hoc manner over years, or by several disconnected teams in different organizational silos.
Motorola’s popular Razr phone is an example of the problem: while the industrial design of the phone is deservedly award-winning for its elegance, the software was inherited from a previous generation of Motorola phones, and appears to have been developed by multiple teams who didn’t coordinate their efforts. For example, the phone’s address book uses a different text-entry interface than its calendar application. Each software team must have devised a separate solution, resulting in two interfaces doing the job that one should have done — both a was
te of development resources and a source of confusion and friction to Motorola’s users.
Mullet and Sano’s classic Designing Visual Interfaces includes a useful discussion of the idea of elegance, which can be thought of as a novel, simple, economical, and graceful way of solving a design problem. Because the software inside an interactive product is typically so incredibly complex, it becomes all the more important to value elegance and simplicity; these attributes are crucial for technology to effectively serve human needs.
A minimalist approach to product design is inextricably tied to a clear understanding of purpose — what the user of a product is trying to accomplish using the tool.
Without this sense of purpose, interactive products are just a disorganized jumble of technological capabilities. A model example where a strong sense of purpose has driven a minimal user interface is the classic Google search interface consisting of a text field, two buttons (“Google Search,” which brings the user to a list of results, and “I’m Feeling Lucky,” which brings the user directly to the top result), the Google logotype, and a couple of links to the broader universe of Google functionality (see Figure 10-1). Other good examples of minimal user interfaces include the iPod Shuffle, where by carefully defining an appropriate set of features to meet a specific set of user needs, Apple created a highly usable product with one switch
15_084113 ch10.qxp 4/3/07 6:05 PM Page 206
206
Part II: Designing Behavior and Form
and five buttons (and no screen!), and Hog Bay Software’s WriteRoom, an incredibly simple text editor with no user interface aside from an area in which to write text, which is automatically saved, eliminating the need to even interact with files.
Figure 10-1 The celebrated Google search interface is a classic example of minimalist interface design, where every screen element is purposeful and direct.
It’s worth noting that the quest for simplicity can be taken too far — reduction is a balancing act that requires a good understanding of users’ mental models. The iPod hardware interface mentioned as an example of elegance and economy in design is also at odds with some users’ expectations. If you’re coming from the world of tape decks and CD players, odds are it feels a bit weird to use the iPod’s Play/Pause toggle to shut the device off, and the Menu button to turn the device on. This is a classic case of visual simplicity leading to cognitive complexity. In this situation, these idioms are simple enough to learn easily, and the consequences of getting it wrong are fairly small, so it’s had little impact on the overall success of the product.
DESIGN
Enable users to direct, don’t force them to discuss.
principle
It seems that many developers imagine the ideal interface to be a two-way conversation with a user. However, most people don’t see it that way. Most people would rather interact with the software in the same way they interact with, say, their cars.
They open the door and get in when they want to go somewhere. They step on the accelerator when they want the car to move forward and the brake when it is time to stop; they turn the wheel when they want the car to turn.
This ideal interaction is not a dialogue — it’s more like using a tool. When a carpenter hits nails, she doesn’t discuss the nail with the hammer; she directs the hammer onto the nail. In a car, the driver gives the car direction when he wants to change the car’s behavior. The driver expects direct feedback from the car and its
15_084113 ch10.qxp 4/3/07 6:05 PM Page 207
Chapter 10: Orchestration and Flow
207
environment in terms appropriate to the device: the view out the windshield, the readings on the various gauges on the dashboard, the sound of rushing air and tires on pavement, and the feel of lateral g-forces and vibration from the road. The carpenter expects similar feedback: the feel of the nail sinking, the sound of the steel striking steel, and the heft of the hammer’s weight.
The driver certainly doesn’t expect the car to interrogate him with a dialog box, nor would the carpenter appreciate one (like the one in Figure 10-2) appearing on her hammer.
Figure 10-2 Just because programmers are accustomed to seeing messages like this, it doesn’t mean that people from other walks of life are. Nobody wants his machine to scold him. If we guide our machines in a dunderheaded way, we expect to get a dunderheaded response. Sure, they can protect us from fatal errors, but scolding isn’t the same thing as protecting.
One of the reasons interactive products often aggravate people is that they don’t act like cars or hammers. Instead, they often have the temerity to try to engage us in a dialogue — to inform us of our shortcomings and to demand answers from us.
From a user’s point of view, the roles are reversed: It should be the person doing the demanding and the software doing the answering.
With direct manipulation, we can point to what we want. If we want to move an object from A to B, we click on it and drag it there. As a general rule, the better, more flow-inducing interfaces are those with plentiful and sophisticated direct manipulation idioms.
DESIGN
Keep tools close at hand.
principle
Most applications are too complex for one mode of direct manipulation to cover all their features. Consequently, most applications offer a set of different tools to users.
These tools are really different modes of behavior that the product enters. Offering tools is a compromise with complexity, but we can still do a lot to make tool
15_084113 ch10.qxp 4/3/07 6:05 PM Page 208
208
Part II: Designing Behavior and Form
selection and manipulation easy and to prevent it from disturbing flow. Mainly, we must ensure that information about tools and application state is clear and present and that transitions between tools are quick and simple.
Tools should be close at hand, commonly on palettes or toolbars for beginner and intermediate users, and accessible by keyboard command for expert users. This way, a user can see them easily and can select them with a single click or keystroke.
If a user must divert his attention from the application to search out a tool, his concentration will be broken. It’s as if he had to get up from his desk and wander down the hall to find a pencil. Also, he should never have to put tools away.
DESIGN
Provide modeless feedback.
principle
When users of an interactive product manipulate tools and data, it’s usually important to clearly present the status and effect of these manipulations. This information must be easy to see and understand without obscuring or interfering with a user’s actions.
There are several ways for an application to present information or feedback to users. Unfortunately, the most common method is to pop up a dialog box on the screen. This technique is modal: It puts the application into a special state that must be dealt with before it can return to its normal state, and before the person can continue with her task. A better way to inform users is with modeless feedback.
Feedback is modeless whenever information for users is built into the structures of the interface and doesn’t stop the normal flow of activities and interaction. In Microsoft Word, you can see what page you are on, what section you are in, how many pages are in the current document, and what position the cursor is in, modelessly just by looking at the status bar at the bottom of the screen — you don’t have to go out of your way to ask for that information.
If you want to know how many words are in your document, however, you have to call up the Word Count dialog from the Tools menu, from there you can open a persistent Word Count toolbar, but even this requires users to click Recount to see accurate information (see Figure 10-3). For people writing magazine articles, who need to be careful about word count, this information would be better delivered modelessly. Even though many people don’t use it, there’s plenty of space on the bottom of the screen in the status bar to deliver such statistics.
15_084113 ch10.qxp 4/3/07 6:05 PM Page 209
Chapter 10: Orchestration and Flow
209
Figure 10-3 In Word 2003, if you want to know the number of words in your document, you must choose Word Count... from the Tools menu. This opens a dialog box. To get back to work, you must first click the Close button on the Word Count dialog. This behavior is the opposite of modeless feedback, and it hampers flow. In Word 2007, Microsoft has improved the situation considerably: The number of words in the document is modelessly displayed on the lower-left edge of the window, next to the page count, a similar bit of information.
Jet fighters have a heads-up display, or HUD, that superimposes the readings of critical instrumentation onto the forward view of the cockpit’s windscreen. The pilot doesn’t even have to use peripheral vision but can read vital gauges while keeping her eyes glued on the opposing fighter. Applications can use the edges of the display screen to show users information about activity in the main work area of applications. Many drawing applications, such as Adobe Photoshop, already provide ruler guides, thumbnail maps, and other modeless feedback in the periphery of their windows. We will further discuss these types of rich modeless feedback in Chapter 25.
DESIGN
Design for the probable; provide for the possible.
principle
There are many cases where interaction, usually in the form of a dialog box, slips into a user interface unnecessarily. A frequent source for such clinkers is when an application is faced with a choice. That’s because programmers tend to resolve choices from the standpoint of logic, and it carries over to their software design. To a logician, if a proposition is true 999,999 times out of a million and false one time, the proposition is false — that’s the way Boolean logic works. However, to the rest of us, the proposition is overwhelmingly true. The proposition has a possibility of being false, but the probability of it being false is minuscule to the point of irrelevancy. One of the most potent methods for better orchestrating your user interfaces is segregating the possible from the probable.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 30
