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:
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 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
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.
- 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 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.
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.)
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
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
pattern for more information.