Thinking about what you do with undo
January 25, 2009
In thinking more about undo issues, I think that the fundamental misconception of designing an undo system is to think of it as purely operation based, instead of something more complex (I don't think that it's purely time based either). Undo is only operation based over the very short term, where you are undo-ing an immediate mistake.
I've been trying to think about what things you do with undo, in general. So far, what I have come up with is:
One fundamental difference between an operation based view and other views of undo is how you handle changes after a series of undo operations. Such changes effectively create a branch in the history; on one side is all of the changes that were undone, and on the other is your just-made changes. In an operation based view it is sensible to immediately throw away the first branch when the second is created, but it is my strong belief that in practice this is going to be very frustrating for users; among other things, it makes an accidental edit while you are deep down in an undo sequence very damaging, since you just lost a bunch of work.
(If you adopt the principle that undo should never cause users to lose work, you are basically forced to at least a time based view of undo so that the user can always return to any previous state of their work.)
* * *
Atom feeds are available; see the bottom of most pages.