Multi-Level Undo

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.

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

• 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

(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.

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.