Wandering Thoughts archives

2009-01-25

Thinking about what you do with undo

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:

  • fix an immediate mistake (the classical reason for simple undo).

  • go back to how things were at some point in the past, either to look at it and then go back to 'now' or to restart work from that point.

    (In a time-based view of undo, restarting from a point in the past should not overwrite everything after that; the past should be immutable because it is, after all, the past. This creates a very basic version of branching.)

  • experiment with something, then revert to a previous version if it doesn't work out.

  • fix a mistake that you didn't notice until some time later. I don't think that this is as simple as rewinding time and starting again, because you probably have work done since the mistake that you want to keep.

    (In software where you already view things as a sequence of edits, for example a non-destructive photo editor, this is a relatively natural and hopefully simple thing. Otherwise, not so much.)

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

UndoOperations written at 02:09:32; Add Comment

2009-01-24

Towards a better undo

Here is my growing theory: current versions of 'undo' functionality generally aren't all that good. Having any undo is a lot better than none, and having multi-level undo is a lot better than only a single level of it (to the point where it's hard for me to consider single level undo as 'undo' any more), but this is a long way from being really useful.

(The problem with single-level undo are hopefully obvious: it's only useful if you immediately realize your mistake. In practice this is unlikely to be the case, especially if the user is an expert with your program who is thus not constantly checking their work.)

The problem with multi-level undo for me is that it doesn't really do what I want to do. If I am going back more than a little bit, I generally don't want to actually reverse my changes; instead, what I want is to go back to look at an old version and maybe cherry-pick some things that I like from it. At the extreme, I want to branch my work in order to experiment with several alternatives. This is especially common with code, where I can often wind up doing experimental rewrites of routines or interfaces or the like (and sometimes the rewrites don't work out and I revert them).

Partly I think that this is an issue of bad interfaces; even with a 'redo', action by action undo makes moving back and forth significantly awkward, for example. I would probably be better served by an interface that has a time based slider (or just an older/newer slider in general). The ability to set marker points and jump back to them would be nice, too, as would the ability to see an old version and the current version at once (to make for easy cherry-picking and the like).

(You need a slider because I am only somewhat more likely to remember how many minutes ago the program looked right as I am to remember how many operations ago that was. A slider gives you a way to directly and rapidly manipulate things to zero in on where you want to be.)

BetterUndo written at 02:18:50; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.