The Second Edition is out!
Visit designinginterfaces.com to read excerpts and learn more.

Multi-Level Undo


Photoshop's visual representation of the "undo stack"

What:

Provide a way to easily reverse a series of actions performed by the user.

Use when:

You've designed a highly interactive UI that is more complex than simple navigation or form fill-in. This includes mail readers, database software, authoring tools, graphics software, and programming environments.

Why:

The ability to undo a long sequence of operations lets users feel that the interface is safe to explore. While they learn the interface, they can experiment with it, confident that they aren't making irrevocable changes -- even if they accidentally do something "bad." This is true for users of all levels of skill, not just beginners. (Alan Cooper and Robert Reimann devote the better part of a chapter to the Undo concept in their book About Face 2.0: The Essentials of Interaction Design (Wiley).)

Once the user knows the interface well, she can move through it with the confidence that mistakes aren't permanent. If her finger slips and she hits the wrong menu item, no complicated and stressful recovery is necessary; she doesn't have to revert to saved files, or shut down and start afresh, or go ask a system administrator to restore a backup file. This spares the user wasted time and occasional mental anguish.

Multi-level undo also lets expert users explore work paths quickly and easily. For instance, a Photoshop user might perform a series of filtering operations on an image, study the result to see if she likes it, and then undo back to her starting point. Then she might try out another series of filters, maybe save it, and undo again. She could do this without multi-level undo, but it would take more time (for closing and reloading the image). When a user works creatively, speed and ease-of-use are important for maintaining focus and the experience of flow. See Chapter 1 for more information, especially the Safe Exploration and Incremental Construction patterns.

How:

Undoable Operations

The software your UI is built on first needs a strong model of what an action is -- what it's called, what object it was associated with, and how to reverse it. Then you can build an undo interface on it.

Decide which operations need to be undoable. Any action that might change a file, or anything that could be permanent, should be undoable, while transient or view-related states often are not. Specifically, these kinds of changes are expected to be undoable in most applications:

  • Text entry for documents or spreadsheets
  • Database transactions
  • Modifications to images or painting canvases
  • Layout changes -- position, size, stacking order, or grouping in graphic applications
  • File operations, such as deleting or modifying files
  • Creation, deletion or rearrangement of objects such as email messages or spreadsheet columns
  • Any cut, copy, or paste operation
The following kinds of changes generally are not undoable. Even if you think you want to go above and beyond the call of duty and make them undoable, consider that you might thoroughly irritate users by cluttering up the "undo stack" with useless undos:
  • Text or object selection
  • Navigation between windows or pages
  • Mouse cursor and text cursor locations
  • Scrollbar position
  • Window or panel positions and sizes
  • Changes made in an uncommitted or modal dialog box
Some operations are on the borderline. Form fill-in, for instance, sometimes is undoable and sometimes is not. However, if tabbing out of a changed field automatically commits that change, it's probably a good idea to make it undoable.

(Certain kinds of operations are impossible to undo. But usually the nature of the application makes that obvious to users with any experience at all. Impossible undos include the purchase step of an ecommerce transaction, posting a message to a bulletin board or chatroom, or sending an email -- much as we'd sometimes like to undo that!)

In any case, make sure the undoable operations make sense to the user. Be sure to define and name them in terms of how the user thinks about the operations, not how the computer thinks about them. You should undo typed text, for instance, in chunks of words, not letter-by-letter.

Design an undo stack

Each operation goes on the top of the stack as it is performed, and each Undo reverses the operation at the top, then the next one down, then the next. Redo similarly works its way back up the stack.

The stack should be at least 10 to 12 items long to be useful, and longer if you can manage it. Long-term observation or usability testing may tell you what your usable limit is. (Constantine and Lockwood assert that more than a dozen items is usually unnecessary, since "users are seldom able to make effective use of more levels." Expert users of high-powered software might tell you differently. As always, know your users.)

Presentation

Finally, decide how to present the undo stack to the user. Most desktop applications put Undo/Redo items on the Edit menu. Also, Undo is usually hooked up to Control-Z or its equivalent. The most well-behaved applications use Smart Menu Items to tell the user exactly which operation is next up on the undo stack.

But see the screenshot at the top of this pattern for a different, more visual presentation. Photoshop shows a scrolling list of the undoable operations -- including ones that were already undone (one is shown, in gray). It lets the user pick the point in the stack that they want to revert to. A visual command history like this can be quite useful, even just as a reminder of what you've recently done. See the Command History pattern for more information.

Examples:


From MS Word

A more typical presentation of Multi-Level Undo. In this case, the user typed some text, and then inserted into a table. The first Undo removes the table. Once that's done, the following Undo -- the next action in the undo stack -- is the typed text, and invoking Undo again removes that text. Meanwhile, the user has the opportunity to "undo the undo" with the Redo menu item. If we're at the top of the stack (as in the first screenshot), then there is no Redo, and that menu item is overloaded with a Repeat action.

Confusing? You bet. Most users never will develop a clear mental picture of the algorithms used here; most people don't know what a "stack" is, let alone how it is used in conjunction with Repeat and Redo. That's why the Smart Menu Items are absolutely critical to usability here. They explain exactly what's going to happen, which reduces the cognitive burden on the user.