UI Patterns and Techniques

Multi-Level Undo


From Photoshop 7

Use when:

You're building a highly interactive UI that is more complex than simple navigation or form fill-in -- mail readers, database software, authoring tools, graphics software, etc.

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." (And this is true for users of all levels of skill, not just beginners.) Alan Cooper devotes the better part of a chapter to this concept in his classic book About Face.

Once the user knows the interface well, they can move through it with the confidence that mistakes aren't permanent. If their finger slips and they hit the wrong menu item, no complicated and stressful recovery is necessary; the user 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 users stress and wasted time.

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 they like it, and then undo back to their starting point. Then they might try out another series of filters, maybe save it, and undo again. This can be done without multi-level undo, but it would take a lot more time (for closing and reloading the image) -- when a user is working creatively, speed and ease-of-use are important for maintaining the experience of "flow."

How:

1. First, decide which operations need to be undoable. Any action that might change a file or similar thing -- anything that could be permanent -- should be undoable, while transient or view-related states often are not. To be more specific, 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, grouping, etc. -- in graphic applications,
  • file operations,
  • creation, deletion or rearrangement of objects such as email messages or spreadsheet columns,
  • any cut, copy, or paste operation.
The following kinds of changes are generally not undoable. Even if you think it would be going above and beyond the call of duty to 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.
Some operations are on the borderline. Form fill-in, for instance, is sometimes undoable and sometimes not. But 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 it obvious to users with any experience at all, such as 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 that to be undoable!)

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. Undoing a bunch of typed text, for instance, should be done in chunks of words, not letter-by-letter.


2. Second, create an "undo stack." Each operation goes on the top of the stack as it is performed; each Undo reverses the operation at the top, then the next, then the next. Redo works its way back up the stack in likewise manner.

The stack should be at least 10-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.)


3. Third, decide how to present the undo stack to the user. Most desktop applications put Undo/Redo items on the Edit menu. Undo is usually hooked up to Ctrl-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 above for a different, more visual presentation. Photoshop shows a scrolling list of the undoable operations -- including ones that have already been undone (in gray). It lets the user pick the point in the stack where they want to go next. A visual command history like this can be quite useful, even simply as a reminder of what you've recently done.

Examples:


From Illustrator 10

A more typical presentation of Multi-Level Undo, this one using smart menu items to show exactly what's going to be undone or redone.