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