Time based undo/redo?

Question

A friend of mine works on a tool allowing visually presenting ideas and she asked me how it should let users go back to any changes made previously. Firstly, I told her to just provide History and Undo/Redo options, but in fact it does not do the trick.

The way edit history is commonly used does not allow users to go back to all the changes - the sole process of undoing seals the way to some of the steps whenever the new branch of edit appears, so for example in this situation:

from 8 you can go back only like this: 8 > 7 > 5 > 3 > 2 > 1.

As you can see, having rolled back from 4 to 3, user still can redo to 4, but if he does does 5 instead, then the possibility to go back to 4 is lost forever. The same about 6. This is a weak point of the system, especially as the common understanding of "history" (as a word) is "everything that happened in the past".

Thus, I came up with another idea, which is time based and allows the user to go back like this: 8 > 7 > 5 > 6 > 5 > 3 > 4 > 3 > 2 > 1

In this case, history collects all the points on the way, treating the rollbacks as points in history as well. So, rolling back from 8 to 1 user can also visit all the points he rolled back from before. There is a downside of this, as some of the history points are duplicated, because they are passed through multiple times.

And here come my questions:

• What do you think about this attitude?
• Do you know any tools (online systems, OS plugins modifying the original behavior of history management) doing it like this?
• Do you maybe know any other attitude that allows going through the branches that can be presented in a way clear for the user?

Please note that any versioning, revisions, is not the same, as usually versions do not reflect all the changes, only some keypoints when let's say a document is saved/autosaved. There are for example local Time Machine copies that are really helpful, but in general versioning is more output oriented, not the editing process oriented.

Answer 1

I can see situations where your time based approach would work well, but there are also some problems with it (besides any technical challenges).

Most people are used to the standard tree for undo, and with your changing of it, they may become confused as to why it works differently.

Undoing something signifies that it was a mistake. With your time based method, I would essentially be redoing mistakes that I have already made. If I've already marked it as an incorrect path, this would very likely be both frustrating and confusing. On top of that, if one of the paths that I have chosen to undo is very long, then using your time based undo, I would have to cycle through many states before getting back to a state that I am looking for.

Answer 2

There is difference between touching each node in the history VS going back to your previous state. Your logic of 8 > 7 > 5 > 3 > 2 > 1 works perfectly well in both forward and backward directions and it is easy for the mind to understand but if you start following the second model 8 > 7 > 5 > 6 > 5 > 3 > 4 > 3 > 2 > 1 then this model will become proportionally distorted when the chain of history grows. That would also mean

• Less efficient application and huge deal of memory required to keep all history states intact
• Conflicting history states as 5 appeared twice.
• A possibility of confusing the user that weather he was traversing forward or backward in the chain.
• What if while traversing forward and reaching between 5 and 6, user presses few un-do and few-redo. How would you treat that?
• Other than a vague understanding of history, there is no visual clue before the user to realize how history is being developed. In that case any branching of history would be difficult to understand for him.

By UNDO, we do not mean to "go back to every previous state" but rather "go to states which I have been through to reach where I stand today". I am recalling some earlier versions of Coral Draw Version 5 used to follow your second model of history but in every other application, I find Model 1 being used.

Answer 3

I agree that it can be frustrating to undo actions in the editor and then later realize shortly after I start to type something else that I "undid" more than I had realized. I would think good semantics, memory permitting, would be to have an "undo" operation which follows anything other than an "undo" or "redo" make note of the system state; if the next action which isn't an undo or redo is performed while undone actions exist, add that latched state and the after-actions-were-undone state as "undo" points. Beyond implementing that functionality, however, I would suggest providing a "history" view which is actually informative, and also perhaps doing something to make clear what exactly is being undone or redone.