Databases do provide us with retrieval tools with a bit more flexibility than matching simple record types. They allow us to find and fetch a record by examining its contents and matching them against search criteria. For example, we search for invoice number “77329” or for the customer with the identifying string “Goodyear Tire and Rubber.” Yet, this still fails for our e-mail problem. If we allow users to enter the keywords “Jerry,” “Sally,” “Ajax,” “Jones Consulting,” and “Board Meeting”
into the message record, we must define such fields in advance. But as we’ve said, defining things in advance doesn’t guarantee that a user will follow that definition later. He may now be looking for messages about the company picnic, for example.
Besides, adding a series of keyword fields leads you into one of the most fundamental and universal conundrums of data processing: If you give users 10 fields, someone is bound to want 11.
The attribute-based alternative
So, if relational database technology isn’t right, what is? If users find it hard to define their information in advance as databases require, is there an alternative storage and retrieval system that might work well for them?
Once again, the key is separating the storage and retrieval systems. If an index were used as the retrieval system, the storage technique could still remain a database. We can imagine the storage facility as a sort of digital soup where we could put our records. This soup would accept any record we dumped into it, regardless of its size, length, type, or contents. Whenever a record was entered, the program would return a token that could be used to retrieve the record. All we have to do is give it back that token, and the soup instantly returns our record. This is just our storage system, however; we still need a retrieval system that manages all those tokens for us.
Attribute-based retrieval thus comes to our rescue: We can create an index that stores a key value along with a copy of the token. The real magic, though, is that we can create an infinite number of indices, each one representing its own key and containing a copy of the token. For example, if our digital soup contained all our e-mail messages, we could establish an index for each of our old friends, “Jerry,”
“Sally,” “Ajax,” “Jones Consulting,” and “Board Meeting.” Now, when we need to find e-mail pertinent to the board meeting, we don’t have to paw manually and tediously through dozens of folders. Instead, a single query brings us everything we are looking for.
Of course, someone or something must fill those indices, but that is a more mun-dane exercise in interaction design. There are two components to consider. First, the system must be able to read e-mail messages and automatically extract and
21_084113 ch15.qxp 4/3/07 6:07 PM Page 333
Chapter 15: Searching and Finding: Improving Data Retrieval
333
index information such as proper names, Internet addresses, street addresses, phone numbers, and other significant data. Second, the system must make it very easy for a user to add ad hoc pointers to messages. He should be able to explicitly specify that a given e-mail message pertains to a specific value, whether or not that value is quoted verbatim in the message. Typing is okay, but selecting from picklists, clicking-and-dragging, and other more advanced user interface idioms can make the task almost painless.
Significant advantages arise when the storage system is reduced in importance and the retrieval system is separated from it and significantly enhanced. Some form of digital soup will help us to get control of the unpredictable information that is beginning to make up more and more of our everyday information universe. We can offer users powerful information-management tools without demanding that they configure their information in advance or that they conform to that configuration in the future. After all, they can’t do it. So why insist?
Natural Language Output: An Ideal
Interface for Attribute-Based Retrieval
In the previous sections of this chapter, we discussed the merits of attribute-based retrieval. This kind of a system, to be truly successful, requires a front end that allows users to very easily make sense of what could be quite complex and interre-lated sets of attributes.
One alternative is to use natural language processing, where a user can key in his request in English. The problem with this method is that it is not possible for today’s run-of-the-mill computers to effectively understand natural language queries in most commercial situations. It might work reasonably in the laboratory under tightly controlled conditions, but not in the real world, where it is subject to whim, dialect, colloquialism, and misunderstanding. In any case, the programming of a natural language recognition engine is beyond the capabilities and budget of your average programming team.
A better approach, which we’ve used successfully on numerous projects, is a technique we refer to as natural language output. Using this technique, the program provides an array of bounded controls for users to choose from. The controls line up so that they can be read like an English sentence. The user chooses from a grammar of valid alternatives, so the design is in essence a self-documenting, bounded query facility. Figure 15-3 shows how it works.
21_084113 ch15.qxp 4/3/07 6:07 PM Page 334
334
Part III: Designing Interaction Details
Figure 15-3 An example of a natural language output interface to an attribute-based retrieval engine, part of a Cooper design created for Softek’s Storage Manager. These controls produce natural language as output, rather than attempting to accept natural language as input, for database queries. Each underlined phrase, when clicked, provides a drop-down menu with a list of selectable options. The user constructs a sentence from a dynamic series of choices that always guarantees a valid result.
A natural language output interface is also a natural for expressing everything from queries to plain old relational databases. Querying a database in the usual fashion is very hard for most people because it calls for Boolean notation and arcane database syntax, à la SQL. We discussed the problems with Boolean notation in Chapter 2. We determined that just because the program needs to understand Boolean queries, users shouldn’t be forced to as well.
English isn’t Boolean, so the English clauses aren’t joined with AND and OR, but rather with English phrases like “all of the following apply” or “not all of the following apply.” Users find that choosing among these phrases is easy because they are very clear and bounded, and they can read it like a sentence to check its validity.
The trickiest part of natural language output from a programming perspective is that choosing from controls on the left may, in many circumstances, change the content of the choices in controls to the right of them, in a cascading fashion. This means that in order to effectively implement natural language output, the grammars of the choices need to be well mapped out in advance, and that the controls need to be dynamically changeable or hideable, depending on what is selected in other controls. It also means the controls themselves must be able to display or, at least, load data dynamically.
The other concern is localization. If you are designing for multiple languages, those with very different word orders (for example, German and English) may require different grammar mappings.
Both attribute-based retrieval engines and natural language output interfaces require a significant design and programming effort, but users will reap tremendous benefits in terms of the power and flexibility in managing their data. Because the amount of data we all must manage is growing at an exponential rate, it makes sense to invest now in these more powerful, Goal-Directed tools wherever data must be managed.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 335
16
Understanding Undo
Undo is the remarkable facility that lets us reverse a previous action. Simple and elegant, the feature is of obvious value. Yet, when we examine current implementations and uses of Undo from a Goal-Directed point of view, we see considerable variation in purpose and method. Undo is critically importa
nt for users, and it’s not quite as simple as it may appear at first glance. In this chapter, we explore different ways that users think about Undo and the different uses for such a facility.
Users and Undo
Undo is the facility traditionally thought of as the rescuer of users in distress; the knight in shining armor; the cavalry galloping over the ridge; the superhero swoop-ing in at the last second.
As a computational facility, Undo has no merit. Mistake-free as they are, computers have no need for Undo. Human beings, on the other hand, make mistakes all the time, and Undo is a facility that exists for their exclusive use. This singular observation should immediately tell us that of all the facilities in a program, Undo should be modeled the least like its construction methods — its implementation model —
and the most like the user’s mental model.
Not only do humans make mistakes, they make mistakes as part of their everyday behavior. From the standpoint of a computer, a false start, a misdirected glance, a
22_084113 ch16.qxp 4/3/07 6:08 PM Page 336
336
Part III: Designing Interaction Details
pause, a sneeze, some experimentation, an “uh,” and a “you know” are all errors. But from the standpoint of a person, they are perfectly normal. Human “mistakes” are so commonplace that if you think of them as “errors” or even as abnormal behavior, you will adversely affect the design of your software.
User mental models of mistakes
Users generally don’t believe, or at least don’t want to believe, that they make mistakes. This is another way of saying that the persona’s mental model typically doesn’t include error on his part. Following a persona’s mental model means absolving him of blame. The implementation model, however, is based on an error-free CPU. Following the implementation model means proposing that all culpability must rest with the user. Thus, most software assumes that it is blameless, and any problems are purely the fault of the user.
The solution is for the user-interface designer to completely abandon the idea that the user can make a mistake — meaning that everything the user does is something he or she considers to be valid and reasonable. Most people don’t like to admit to mistakes in their own minds, so the program shouldn’t contradict this mindset in its interactions with users.
Undo enables exploration
If we design software from the point of view that nothing users do should constitute a mistake, we immediately begin to see things differently. We cease to imagine the user as a module of code or a peripheral that drives the computer, and we begin to imagine him as an explorer, probing the unknown. We understand that exploration involves inevitable forays into blind alleys and down dead ends. It is natural for humans to experiment, to vary their actions, to probe gently against the veil of the unknown to see where their boundaries lie. How can they know what they can do with a tool unless they experiment with it? Of course, the degree of willingness to experiment varies widely from person to person, but most people experiment at least a little bit.
Programmers, who are highly paid to think like computers, view such behavior only as errors that must be handled by the code. From the implementation model —
necessarily the programmer’s point of view — such gentle, innocent probing represents a continuous series of “mistakes.” From a humanistic perspective based on our users’ mental models, these actions are natural and normal. An application has the choice of either rebuffing those perceived mistakes or assisting users in their explorations. Undo is thus a primary tool for supporting exploration in software user
22_084113 ch16.qxp 4/3/07 6:08 PM Page 337
Chapter 16: Understanding Undo
337
interfaces. It allows users to reverse one or more previous actions if they decide to change their mind.
A significant benefit of Undo is purely psychological: It reassures users. It is much easier to enter a cave if you are confident that you can get back out of it at any time.
The Undo function is that comforting rope ladder to the surface, supporting a user’s willingness to explore further by assuring him that he can back out of any dead-end caverns.
Curiously, users often don’t think about Undo until they need it, in much the same way that homeowners don’t think about their insurance policies until a disaster strikes. Users frequently charge into the cave half prepared, and only start looking for the rope ladder — for Undo — after they have encountered trouble.
Designing an Undo Facility
Although users need Undo, it doesn’t directly support any particular goal that underlies their tasks. Rather, it supports a necessary condition — trustworthiness — on the way to a real goal. It doesn’t contribute positively to attaining users’ goals, but keeps negative occurrences from spoiling the effort.
Users visualize the Undo facility in different ways, depending on the situation and their expectations. If a user is very computer-naive, he might see it as an unconditional panic button for extricating himself from a hopelessly tangled misadventure.
A more experienced computer user might visualize Undo as a storage facility for deleted data. A really computer-sympathetic user with a logical mind might see it as a stack of procedures that can be undone one at a time in reverse order. To create an effective Undo facility, we must satisfy as many of these mental models as we expect our personas will bring to bear.
The secret to designing a successful Undo system is to make sure that it supports typically used tools and avoids any hint that Undo signals (whether visually, audibly, or textually) a failure by a user. It should be less a tool for reversing errors and more one for supporting exploration. Errors are generally single, incorrect actions.
Exploration, by contrast, is a long series of probes and steps, some of which are keepers and others that must be abandoned.
Undo works best as a global, programwide function that undoes the last action regardless of whether it was done by direct manipulation or through a dialog box.
One of the biggest problems in current implementations of Undo functionality is when users lose the ability to reverse their actions after they save the document (in Excel, for example). Just because a user has saved her work to avoid losing it in a
22_084113 ch16.qxp 4/3/07 6:08 PM Page 338
338
Part III: Designing Interaction Details
crash doesn’t necessarily mean that she wants to commit to all the changes she has made. Furthermore, with our large disk drives, there is no reason not to save the Undo buffer with the document.
Undo can also be problematic for documents with embedded objects. If a user makes changes to a spreadsheet embedded in a Word document, clicks on the Word document, and then invokes Undo, then the most recent Word action is undone instead of the most recent spreadsheet action. Users have a difficult time with this.
It forces them to abandon their mental model of a single unified document and forces them to think in terms of the implementation model — that there is one document embedded within another, and each has a separate editor with a separate Undo buffer.
Types and Variants of Undo
As is so common in the world of software, there is no adequate terminology to describe the different types of Undo that exist — they are uniformly referred to as
“Undo” and left at that. This language gap contributes to the lack of innovation to produce new and better variants of Undo. In this section, we define several Undo variants and explain their differences.
Incremental and procedural actions
Undo operates on a user’s actions. A typical user action in a typical application has a procedure component — what the user did — and often a data component — what information was affected. When the user requests an Undo function, the procedure component of the action is reversed, and if the action had a data component —
resulting in the addition, modification, or deletion of data — that data will be modified appropriately. Cutting, past
ing, drawing, typing, and deleting are all actions that have a data component, so undoing them involves removing or replacing the affected text or image parts. Those actions that include a data component are called incremental actions.
Many undoable actions are data-free transformations such as a paragraph reformatting operation in a word processor or a rotation in a drawing program. Both of these operations act on data but neither of them add, modify, or delete data (from the perspective of the database, though a user may not share this view). Actions like these (with only a procedure component) are procedural actions . Most existing Undo functions don’t discriminate between procedural and incremental actions but simply reverse the most recent action.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 339
Chapter 16: Understanding Undo
339
Blind and explanatory Undo
Normally, Undo is invoked by a menu item or toolbar control with an unchanging label or icon. Users know that triggering the idiom undoes the last operation, but there is no indication of what that operation is. This is called a blind Undo. On the other hand, if the idiom includes a textual or visual description of the particular operation that will be undone, it is an explanatory Undo.
If, for example, a user’s last operation was to type in the word design, the Undo function on the menu says Undo Typing design. Explanatory Undo is, generally, a much more pleasant feature than blind Undo. It is fairly easy to put on a menu item, but more difficult to put on a toolbar control, although putting the explanation in a ToolTip is a good compromise (see Chapter 23 for more about toolbars and ToolTips).
Single and multiple Undo
The two most familiar types of Undo in common use today are single Undo and multiple Undo. Single Undo is the most basic variant, reversing the effects of the most recent user action, whether procedural or incremental. Performing a single Undo twice usually undoes the Undo and brings the system back to the state it was in before the first Undo was activated.
Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf) Page 46