Instead, the application could write the undo stack to a file. When the user reopens
17_084113 ch12.qxp 4/3/07 6:06 PM Page 266
266
Part II: Designing Behavior and Form
the file, the application could reload its undo stack with the actions the user performed the last time the application was run — even if that was a week ago!
Past data entries
An application with a better memory can reduce the number of errors users make.
This is simply because users have to enter less information. More of it will be entered automatically from the application’s memory. In an invoicing application, for example, if the software enters the date, department number, and other standard fields from memory, the invoicing clerk has fewer opportunities to make typing errors in these fields.
If the application remembers what the user enters and uses that information for future reasonableness checks, the application can work to keep erroneous data from being entered. Contemporary Web browsers such as Internet Explorer and Firefox provide this facility: Named data entry fields remember what has been entered into them before, and allow users to pick those values from a combo box.
For security-minded individuals, this feature can be turned off, but for the rest of us, it saves time and prevents errors.
Foreign application activities on application files
Applications might also leave a small thread running between invocations. This little application can keep an eye on the files it worked on. It can track where they go and who reads and writes to them. This information might be helpful to a user when he next runs the application. When he tries to open a particular file, the application can help him find it, even if it has been moved. The application can keep the user informed about what other functions were performed on his file, such as whether or not it was printed or faxed to someone. Sure, this information might not be needed, but the computer can easily spare the time, and it’s only bits that have to be thrown away, after all.
Applying memory to your applications
A remarkable thing happens to the software design process when developers accept the power of task coherence. Designers find that their thinking takes on a whole new quality. The normally unquestioned recourse of popping up a dialog box gets replaced with a more studied process, where the designer asks questions of much greater subtlety. Questions like: How much should the application remember?
Which aspects should be remembered? Should the application remember more than just the last setting? What constitutes a change in pattern? Designers start to imagine situations like this: The user accepts the same date format 50 times in a row, and then manually enters a different format once. The next time the user
17_084113 ch12.qxp 4/3/07 6:06 PM Page 267
Chapter 12: Designing Good Behavior
267
enters a date, which format should the application use? The format used 50 times or the more recent one-time format? How many times must the new format be specified before it becomes the default? Just because there is ambiguity here, the application still shouldn’t ask the user. It must use its initiative to make a reasonable decision. The user is free to override the application’s decision if it is the wrong one.
The following sections explain some characteristic patterns in the ways people make choices that can help us resolve these more complex questions about task coherence.
Decision-set reduction
People tend to reduce an infinite set of choices down to a small, finite set of choices.
Even when you don’t do the exact same thing each time, you will tend to choose your actions from a small, repetitive set of options. People unconsciously perform this decision-set reduction, but software can take notice and act upon it.
For example, just because you went shopping at Safeway yesterday doesn’t necessarily mean that you will be shopping at Safeway exclusively. However, the next time you need groceries, you will probably shop at Safeway again. Similarly, even though your favorite Chinese restaurant has 250 items on the menu, chances are that you will usually choose from your own personal subset of five or six favorites.
When people drive to and from work, they usually choose from a small number of favorite routes, depending on traffic conditions. Computers, of course, can remember four or five things without breaking a sweat.
Although simply remembering the last action is better than not remembering anything, it can lead to a peculiar pathology if the decision set consists of precisely two elements. If, for example, you alternately read files from one directory and store them in another, each time the application offers you the last directory, it will be guaranteed to be wrong. The solution is to remember more than just one previous choice.
Decision-set reduction guides us to the idea that pieces of information the application must remember about the user’s choices tend to come in groups. Instead of one right way, several options are all correct. The application should look for more subtle clues to differentiate which one of the small set is correct. For example, if you use a check-writing application to pay your bills, the application may very quickly learn that only two or three accounts are used regularly. But how can it determine from a given check which of the three accounts is the most likely to be appropriate? If the application remembered the payees and amounts on an account-by-account basis, that decision would be easy. Every time you pay the rent, it is the exact same amount!
It’s the same with a car payment. The amount paid to the electric company might
17_084113 ch12.qxp 4/3/07 6:06 PM Page 268
268
Part II: Designing Behavior and Form
vary from check to check, but it probably stays within 10 or 20% of the last check written to them. All this information can be used to help the application recognize what is going on, and use that information to help the user.
Preference thresholds
The decisions people make tend to fall into two primary categories: important and unimportant. Any given activity may involve hundreds of decisions, but only a few of them are important. All the rest are insignificant. Software interfaces can use this idea of preference thresholds to simplify tasks for users .
After you decide to buy that car, you don’t really care who finances it as long as the terms are competitive. After you decide to buy groceries, the particular check-out aisle you select may not be important. After you decide to ride the Matterhorn at Disneyland, you don’t really care which toboggan they seat you in.
Preference thresholds guide us in our user interface design by demonstrating that asking users for successively detailed decisions about a procedure is unnecessary.
After a user asks to print, we don’t have to ask him how many copies he wants or whether the image is landscape or portrait. We can make an assumption about these things the first time out, and then remember them for all subsequent invocations. If the user wants to change them, he can always request the Printer Options dialog box.
Using preference thresholds, we can easily track which facilities of the application each user likes to adjust and which are set once and ignored. With this knowledge, the application can offer choices where it has an expectation that a user will want to take control, not bothering him with decisions he won’t care about.
Mostly right, most of the time
Task coherence predicts what users will do in the future with reasonable, but not absolute, certainty. If our application relies on this principle, it’s natural to wonder about the uncertainty of our predictions. If we can reliably predict what the user will do 80% of the time, it means that 20% of the time we will be wrong. It might seem that the proper step to take here is to offer users a choice, but this means that they will be bothered by an unnecessary dialog 80% of the time. Rather than offering a choice, the application should go ahead and do what it thinks is most appropriate and allow users to override or undo it. If the undo facility is sufficiently easy to use and understand, users won’t
be bothered by it. After all, they will have to use undo only two times out of ten instead of having to deal with a redundant dialog box eight times out of ten. This is a much better deal for humans.
18_084113 ch13.qxp 4/3/07 6:06 PM Page 269
13
Metaphors, Idioms,
and Affordances
Some interface designers speak of finding the right metaphor upon which to base their interface designs. They imagine that filling their interface with images of familiar objects from the real world will give their users a pipeline to easy learning.
So, they create an interface masquerading as an office filled with desks, file cabinets, telephones, and address books, or as a pad of paper or a street of buildings. If you, too, search for that magic metaphor, you will be in august company. Some of the best and brightest designers in the interface world consider metaphor selection as one of their first and most important tasks.
We find this very literal approach to be limiting and potentially problematic. Strict adherence to metaphors ties interfaces unnecessarily to the workings of the physical world. One of the most fantastic things about digital products is that the working model presented to users need not be bound by the limitations of physics and the inherent messiness of real three-dimensional space.
User interfaces based on metaphors have a host of other problems as well: There aren’t enough good metaphors to go around, they don’t scale well, and the ability of users to recognize them is often questionable, especially across cultural boundaries.
Metaphors, especially physical and spatial metaphors, have an extremely limited place in the design of most Information-Age, software-enabled products. In this
18_084113 ch13.qxp 4/3/07 6:06 PM Page 270
270
Part II: Designing Behavior and Form
chapter, we discuss the reasons for this, as well as the alternatives to design based on metaphors.
Interface Paradigms
There are three dominant paradigms in the conceptual and visual design of user interfaces: implementation-centric, metaphoric, and idiomatic. The implementation-centric interfaces are based on understanding how things actually work under the hood — a difficult proposition. Metaphoric interfaces are based on intuiting how things work — a risky method. Idiomatic interfaces, however, are based on learning how to accomplish things — a natural, human process.
The field of user-interface design progressed from a heavy focus on technology (implementation) to an equally heavy focus on metaphor. There is ample evidence of all three paradigms in contemporary software design, even though the metaphoric paradigm is the only one that has been named and described. Although metaphors are great tools for humans to communicate with each other (this book is filled with them), they are weak tools for the design of software, and all too often they hamper the creation of truly superior interfaces.
Implementation-centric interfaces
Implementation-centric user interfaces are widespread in the computer industry.
These interfaces are expressed in terms of their construction, of how they are built.
In order to successfully use them, users must understand how the software works internally. Following the implementation-centric paradigm means user-interface design based exclusively on the implementation model.
The overwhelming majority of software programs today are implementation centric in that they show us, without any hint of shame, precisely how they are built.
There is one button per function, one dialog per module of code, and the commands and processes precisely echo the internal data structures and algorithms.
We can see how an implementation model interface ticks by learning how to run its program. The problem is that the reverse is also true: We must learn how the program works in order to successfully use the interface.
DESIGN
Most people would rather be successful than knowledgeable.
principle
18_084113 ch13.qxp 4/3/07 6:06 PM Page 271
Chapter 13: Metaphors, Idioms, and Affordances
271
Clearly, implementation-centric interfaces are the easiest to build — every time a programmer writes a function he slaps on a bit of user interface to test that function. It’s easy to debug, and when something doesn’t behave properly, it’s easy to troubleshoot. Further, engineers like to know how things work, so the implementation-centric paradigm is very satisfying to them. Engineers prefer to see the gears and levers and valves because it helps them understand what is going on inside the machine. That those artifacts needlessly complicate things for users seems a small price to pay. Engineers may want to understand the inner workings, but most users don’t have either the time or desire. They’d much rather be successful than be knowledgeable, a preference that is often hard for engineers to understand.
A close relative of the implementation-centric interface worth mentioning is the
“org-chart centric” interface. This is the common situation where a product, or most typically, a Web site, is organized, not according to how users are likely to think about information, but by how the company the site represents is structured.
On such as site, there is typically a tab or area for each division and a lack of cohesion between these areas. Similar to the implementation-centric product interface, an org-chart-centric Web site requires users to have an intimate understanding of how a corporation is structured to find the information they are interested in.
Metaphoric interfaces
Metaphoric interfaces rely on intuitive connections that users makes between the visual cues in an interface and its function. There is no need to understand the mechanics of the software, so it is a step forward from implementation-centric interfaces, but its power and usefulness has been inflated to unrealistic proportions.
When we talk about metaphors in the context of user interface and interaction design, we really mean visual metaphors: a picture used to represent the purpose or attributes of a thing. Users recognize the imagery of the metaphor and, by extension, can presumably understand the purpose of the thing. Metaphors can range from the tiny images on toolbar buttons to the entire screen on some programs —
from a tiny pair of scissors on a button indicating Cut to a full-size checkbook in Quicken. We understand metaphors intuitively, but what does that really mean?
Webster’s Dictionary defines intuition like this:
in·tu·i·tion in-’tu-wi-shen n 1 : quick and ready insight 2 a : immediate apprehension or cognition b : knowledge or conviction gained by intuition c : the power or faculty of attaining to direct knowledge or cognition without evident rational thought and inference
18_084113 ch13.qxp 4/3/07 6:06 PM Page 272
272
Part II: Designing Behavior and Form
This definition highlights the magical quality of intuition, but it doesn’t say how we intuit something. Intuition works by inference, where we see connections between disparate subjects and learn from these similarities, while not being distracted by their differences. We grasp the meaning of the metaphoric controls in an interface because we mentally connect them with other things we have already learned. This is an efficient way to take advantage of the awesome power of the human mind to make inferences. However, this method also depends on the idiosyncratic human minds of users, which may not have the requisite language, knowledge, or inferential power necessary to make those connections.
Limitations of metaphors
The idea that metaphors are a firm foundation for user-interface design is mislead-ing. It’s like worshipping floppy disks because so much good software once came on them. Metaphors have many limitations when applied to modern, information-age systems.
For one thing, metaphors don’t scale very well. A metaphor that works well for a simple process in a simple program will often fail to work well as that process grows in size or complexity. Large file icons were a good idea when computers had floppies or 10 MB hard disks with only a couple of h
undred files, but in these days of 250 GB hard disks and tens of thousands of files, file icons become too clumsy to use effectively.
Metaphors also rely on associations perceived in similar ways by both the designer and the user. If the user doesn’t have the same cultural background as the designer, it is easy for metaphors to fail. Even in the same or similar cultures, there can be significant misunderstandings. Does a picture of an airplane mean “check flight arrival information” or “make airline reservations?”
Finally, although a metaphor offers a small boost in learnability to first-time users, it exacts a tremendous cost after they become intermediates. By reflecting the physical world of mechanisms, most metaphors firmly nail our conceptual feet to the ground, forever limiting the power of our software. We’ll discuss this issue with metaphors later in this chapter.
Our definition of intuition indicates that rational thought is not required in the process of intuiting. In the computer industry, and particularly in the user-interface design community, the word intuitive is often used to mean easy-to-use or easy-to-understand. Ease-of-use is obviously important, but it doesn’t promote our craft to attribute its success to metaphysics. Nor does it help us to devalue the
18_084113 ch13.qxp 4/3/07 6:06 PM Page 273
Chapter 13: Metaphors, Idioms, and Affordances
273
precise meaning of the word. There are very real reasons why people understand certain interfaces and not others.
Intuition, instinct, and learning
There are certain sounds, smells, and images that make us respond without any previous conscious learning. When a small child encounters an angry dog, she instinctively knows that bared fangs signal great danger even without any previous learning. The encoding for such recognition goes deep. Instinct is a hard-wired response that involves no conscious thought. Intuition is one step above instinct because, although it also requires no conscious thought, it is based on a web of knowledge learned consciously.
Examples of instinct in human-computer interaction include the way we are startled and made apprehensive by gross changes in the image on the screen, find our eyes drawn inexorably to the flashing advertisement on a Web page, or react to sudden noises from the computer or the smell of smoke rising from the CPU.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 38