Alan Cooper, Robert Reinmann, David Cronin - About Face 3- The Essentials of Interaction Design (pdf)
Page 47
This facility is very effective because it is so simple to operate. The user interface is simple and clear, easy to describe and remember. A user gets precisely one free lunch. This is by far the most frequently implemented Undo, and it is certainly adequate, if not optimal, for many programs. For some users, the absence of this simple Undo is sufficient grounds to abandon a product entirely.
A user generally notices most of his command mistakes right away: Something about what he did doesn’t feel or look right, so he pauses to evaluate the situation.
If the representation is clear, he sees his mistake and selects the Undo function to set things back to the previously correct state; then he proceeds.
Multiple Undo can be performed repeatedly in succession — it can reverse more than one previous operation, in reverse temporal order. Any program with simple Undo must remember the user’s last operation and, if applicable, cache any changed data. If the program implements multiple Undo, it must maintain a stack of operations, the depth of which may be set by the user as an advanced preference.
Each time Undo is invoked, it performs an incremental Undo; it reverses the most recent operation, replacing or removing data as necessary and discarding the restored operation from the stack.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 340
340
Part III: Designing Interaction Details
Limitations of single Undo
The biggest limitation of single-level, functional Undo occurs when a user accidentally short-circuits the capability of the Undo facility to rescue him. This problem crops up when a user doesn’t notice his mistake immediately. For example, assume he deletes six paragraphs of text, then deletes one word, and then decides that the six paragraphs were erroneously deleted and should be replaced. Unfortunately, performing Undo now merely brings back the one word, and the six paragraphs are lost forever. The Undo function has failed him by behaving literally rather than practically. Anybody can clearly see that the six paragraphs are more important than the single word, yet the program freely discarded those paragraphs in favor of the one word. The program’s blindness caused it to keep a quarter and throw away a fifty-dollar bill, simply because the quarter was offered last.
In some applications, any click of the mouse, however innocent of function it might be, causes the single Undo function to forget the last meaningful thing the user did. Although multiple Undo solves these problems, it introduces some significant problems of its own.
Limitations of multiple Undo
The response to the weaknesses of single-level Undo has been to create a multiple-level implementation of the same, incremental Undo. The program saves each action a user takes. By selecting Undo repeatedly, each action can be undone in the reverse order of its original invocation. In the previous scenario, a user can restore the deleted word with the first invocation of Undo and restore the precious six paragraphs with a second invocation. Having to redundantly redelete the single word is a small price to pay for being able to recover those six valuable paragraphs.
The excise of the one-word redeletion tends to not be noticed, just as we don’t notice the cost of ambulance trips: Don’t quibble over the little stuff when lives are at stake. But this doesn’t change the fact that the Undo mechanism is built on a faulty model, and in other circumstances, undoing functions in a strict LIFO (last in, first out) order can make the cure as painful as the disease.
Imagine again our user deleting six paragraphs of text, then calling up another document and performing a global find-and-replace function. In order to retrieve the missing six paragraphs, the user must first unnecessarily Undo the rather complex global find-and-replace operation. This time, the intervening operation was not the insignificant single-word deletion of the earlier example. The intervening operation was complex and difficult and having to Undo it is clearly an unpleasant, excise effort. It would sure be nice to be able to choose which operation in the queue to Undo and to be able to leave intervening — but valid — operations untouched.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 341
Chapter 16: Understanding Undo
341
The model problems of multiple Undo
The problems with multiple Undo are not due to its behavior as much as they are due to its manifest model. Most Undo facilities are constructed in an unrelentingly function-centric manner. They remember what a user does function by function and separate her actions by individual function. In the time-honored way of creating manifest models that follow implementation models, Undo systems tend to model code and data structures instead of user goals. Each click of the Undo button reverses precisely one function-sized bite of behavior. Reversing on a function-by-function basis is a very appropriate mental model for solving most simple problems that arise when a user makes an erroneous entry. The mistake is noticed right away and the user takes action to fix it right away, usually by the time he’s taken two or three actions. However, when the problem grows more convoluted, the incremental, multiple-step Undo model doesn’t scale very well.
You bet your LIFO
When a user goes down a logical dead end (rather than merely mistyping data), he can often proceed several complex steps into the unknown before realizing that he is lost and needs to get a bearing on known territory. At this point, however, he may have performed several interlaced functions, only some of which are undesirable.
He may well want to keep some actions and nullify others, not necessarily in strict reverse order. What if he entered some text, edited it, and then decided to Undo the entry of that text but not Undo the editing of it? Such an operation is problematic to implement and explain. Neil Rubenking offers this pernicious example: Suppose that a user did a global replace changing tragedy to catastrophe and then another changing cat to dog. To Undo the first without undoing the second, can the program reliably fix all the dogastrophes?
In this more complex situation, the simplistic representation of the Undo as a single, straight-line, LIFO stack doesn’t satisfy the way it does in simpler situations.
The user may be interested in studying his actions as a menu and choosing a dis-continuous subset of them for reversion, while keeping some others. This demands an explanatory Undo with a more robust presentation than might otherwise be necessary for a normal, blind, multiple Undo. Additionally, the means for selecting from that presentation must be more sophisticated. Representing the operation in the queue to show the user what he is actually undoing is a more difficult problem.
Redo
The Redo function came into being as the result of the implementation model for Undo, wherein operations must be undone in reverse sequence, and in which no
22_084113 ch16.qxp 4/3/07 6:08 PM Page 342
342
Part III: Designing Interaction Details
operation may be undone without first undoing all of the valid intervening operations. Redo essentially undoes the Undo and is easy to implement if the programmer has already gone to the effort to implement Undo.
Redo prevents a diabolical situation in multiple Undo. If a user wants to back out of a half-dozen or so operations, he clicks the Undo control a few times, waiting to see things return to the desired state. It is very easy in this situation to press Undo one time too many. He immediately sees that he has undone something desirable.
Redo solves this problem by allowing him to Undo the Undo, putting back the last good action.
Many programs that implement single Undo treat the last undone action as an undoable action. In effect, this makes a second invocation of the Undo function a minimal Redo function.
Group multiple Undo
Microsoft Word has what has unfortunately become a somewhat typical facility —
a variation of multiple Undo we will call group multiple Undo. It is multiple level, showing a textual description of each operation in the Undo stack. You can examine the list of past operations and select some operation in the list to Undo; however, you are not undoing that o
ne operation, but rather all operations back to that point, inclusive (see Figure 16-1). This style of multiple Undo is also employed by many Adobe products.
Figure 16-1 With Microsoft Office’s Undo/Redo facility, you can Undo multiple actions, but only as a group; you can’t choose to Undo only the thing you did three actions ago. Redo works in the same manner.
As a result, you cannot recover your six missing paragraphs without first reversing all the intervening operations. After you select one or more operations to Undo, the list of undone operations becomes available in reverse order in the Redo control.
Redo works exactly the same way as Undo works. You can select as many operations to redo as desired and all operations up to that specific one will be redone.
The program offers two visual cues to this fact. If the user selects the fifth item in the list, that item and all four items before it in the list are selected. Also, the text
22_084113 ch16.qxp 4/3/07 6:08 PM Page 343
Chapter 16: Understanding Undo
343
legend says “Undo 5 actions.” The fact that the designers had to add that text legend tells me that, regardless of how the programmers constructed it, the users were applying a different mental model. The users imagined that they could go down the list and select a single action from the past to Undo. The program didn’t offer that option, so the signs were posted. This is like a door with a pull handle that has been pasted with Push signs — which everybody still pulls on anyway. While multiple Undo is certainly a very useful mechanism, there’s no reason not to finish the job and use our ample computing resources to allow users to Undo just the undesirable actions, instead of everything that has happened since them.
Other Models for Undo-Like Behavior
The manifest model of Undo in its simplest form — single Undo — conforms to the user’s mental model: “I just did something I now wish I hadn’t done. I want to click a button and Undo that last thing I did . ” Unfortunately, this manifest model rapidly diverges from the user’s mental model as the complexity of the situation grows. In this section, we discuss models of Undo-like behavior that work a bit differently from the more standard Undo and Redo idioms.
Comparison: What would this look like?
Besides providing robust support for the terminally indecisive, the paired Undo-Redo function is a convenient comparison tool. Say that you’d like to compare the visual effect of ragged-right margins against justified right margins. Beginning with ragged-right, you invoke Justification. Now you click Undo to see ragged-right and now you press Redo to see justified margins again. In effect, toggling between Undo and Redo implements a comparison or what-if? function; it just happens to be represented in the form of its implementation model. If this same function were to be added to the interface following a user’s mental model, it might be manifested as a comparison control. This function would let you repeatedly take one step forward or backward to compare two states.
Some TV remote controls include a function labeled Jump, which switches between the current channel and the previous channel — very convenient for viewing two programs concurrently. The jump function provides the same utility as the Undo-Redo function pair with a single command — a 50% reduction in excise for the same functionality.
When used as comparison functions, Undo and Redo are really one function and not two. One says “Apply this change,” and the other says “Don’t apply this change.”
A single Compare button might more accurately represent the action to users.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 344
344
Part III: Designing Interaction Details
Although we have been describing this tool in the context of a text-oriented word processing program, a compare function might be most useful in a graphic manipulation or drawing program, where users are applying successive visual transformations on images. The ability to see the image with the transformation and quickly and easily compare it to the image without the transformation would be a great help to the digital artist. Many products address this with small thumbnail
“preview” images.
Doubtlessly, the Compare function would remain an advanced function. Just as the jump function is probably not used by a majority of TV users, the Compare button would remain one of those niceties for frequent users. This shouldn’t detract from its usefulness, however, because drawing programs tend to be used very frequently by those who use them. For programs like this, catering to the frequent user is a reasonable design choice.
Category-specific Undo
The Backspace key is really an Undo function, albeit a special one. When a user mistypes, the Backspace key “undoes” the erroneous characters. If a user mistypes something, then enters an unrelated function such as paragraph reformatting, then presses the Backspace key repeatedly, the mistyped characters are erased and the reformatting operation is ignored. Depending on how you look at it, this can be a great flexible advantage giving users the ability to Undo discontiguously at any selected location. You could also see it as a trap for users because they can move the cursor and inadvertently backspace away characters that were not the last ones keyed in.
Logic says that this latter case is a problem. Empirical observation says that it is rarely a problem for users. Such discontiguous, incremental Undo — so hard to explain in words — is so natural and easy to use because everything is visible: Users can clearly see what will be backspaced away. Backspace is a classic example of an incremental Undo, reversing only some data while ignoring other, intervening actions. Yet if you imagined an Undo facility that had a pointer that could be moved and that could Undo the last function that occurred where the pointer points, you’d probably think that such a feature would be patently unmanageable and would confuse a typical user. Experience tells us that Backspace does nothing of the sort.
It works as well as it does because its behavior is consistent with a user’s mental model of the cursor: Because it is the source of added characters, it can also reasonably be the locus of deleted characters.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 345
Chapter 16: Understanding Undo
345
Using this same knowledge, we could create different categories of incremental Undo, like a format-Undo function that would Undo only preceding format commands and other types of category-specific Undo actions. If a user entered some text, changed it to italic, entered some more text, increased the paragraph indentation, entered some more text, and then clicked the Format-Undo button, only the indentation increase would be undone. A second click of the Format-Undo button would reverse the italicize operation. Neither invocation of the format-Undo would affect the content.
What are the implications of category-specific Undo in a nontext program? In a drawing program, for example, there could be separate Undo commands for pigment application tools, transformations, and cut-and-paste. There is really no reason that we couldn’t have independent Undo functions for each particular class of operation in a program.
Pigment application tools include all drawing implements — pencils, pens, fills, sprayers, brushes — and all shape tools — rectangles, lines, ellipses, arrows. Transformations include all image-manipulation tools — shear, sharpness, hue, rotate, contrast, and line weight. Cut-and-paste tools include all lassos, marquees, clones, drags, and other repositioning tools. Unlike the Backspace function in the word processor, undoing a pigment application in a draw program would be temporal and would work independently of selection. That is, the pigment that is removed first would be the last pigment applied, regardless of the current selection. In text, there is an implied order from the upper left to the lower right. Deleting from the lower right to the upper left maps to a strong, intrinsic mental model, so it seems natural. In a drawing, no such conventional order exists so any deletion order other than one based on entry sequence would be disconcerting to users.
A better alternative might be to Undo within the
current selection only. A user selects a graphic object, for example, and requests a transformation-Undo. The last transformation to have been applied to that selected object would be reversed.
Most software users are familiar with the incremental Undo and would find a category-specific Undo novel and possibly disturbing. However, the ubiquity of the Backspace key shows that incremental Undo is a learned behavior that users find to be helpful. If more programs had modal Undo tools, users would soon adapt to them. They would even come to expect them the way they expect to find the Backspace key on word processors.
22_084113 ch16.qxp 4/3/07 6:08 PM Page 346
346
Part III: Designing Interaction Details
Deleted data buffers
As a user works on a document for an extended time, she may desire a repository of deleted text. Take for example, the six missing paragraphs. If they are separated from her by a couple of complex search-and-replaces, they can be as difficult to reclaim by Undo as they are to rekey. Our user is thinking, “If the program would just remember the stuff I deleted and keep it in a special place, I could go get what I want directly.”
What the user is imagining is a repository of the data components of her actions, rather than merely a LIFO stack of procedurals — a deleted data buffer. The user wants the missing text without regard to which function elided it. The usual manifest model forces her not only to be aware of every intermediate step but to reverse each of them, in turn. To create a facility more amenable to our user, we can create, in addition to the normal Undo stack, an independent buffer that collects all deleted text or data. At any time, she can open this buffer as a document and use standard cut-and-paste or click-and-drag idioms to examine and recover the desired text. If the entries in this deletion buffer are headed with simple date stamps and document names, navigation would be very simple and visual.