Saving & restoring undo stack -- good or bad?

Question

In a sovereign desktop app with multi-level undo/redo (ie Photoshop, Word, etc), would being able to save and restore the undo history of a file with the file itself be a good thing or a bad thing? My initial reaction is "good", however I've found I occasionally hold Control+Z until it stops working to revert to a previous version. Any studies or experience with this?

Answer 1

One example of such an application is IntelliJ IDEA (and some other programming environments). In addition to the usual project-specific external revision control, IDEA has a user-specific local history which saves a revision of every file on every save (the history is stored inside the user's home directory). The old revisions are stored by default for 3 active work days, after which the old revisions are removed. Coupled with the feature of automatically saving all files every few seconds (my preference is after being idle for 5 seconds), this means that you will never need to think about saving files, and you can always get back the old data. It's a real lifesaver when programming. (Sometimes I also use it to find out how many hours I've worked on a project, to record my work hours, because the local history shows the date and time of every change.)

An external revision control is still needed, but for other needs - there you will commit changes typically when you get some consistent piece of work done, at least once every 1-2 hours, and it's also a way to distribute your changes to other team members and to make backups. The local history on the other hand is for recovering from mishaps a few seconds or minutes after it happened.

I think that many other programs would benefit from a similar local history. I would love it if my Office Suite would have it, because a undo/redo stack and manually saving the files are very primitive ways of recovering lost data (they don't allow selective recovery and they don't survive restarting the program). I also remember seeing an image editing application (I don't remember the name - I think it was only for Mac), where all edits were done as transformations of the original picture, and you could at any time go back to change any of the previous edits. So such an history is possible even with image editing.

I don't think that I would want the history to be stored inside the file being edited - otherwise it would get very big (a revision every couple of seconds; my local history for programming projects I've worked on within one year is 370 MB) and it could cause a security problem by leaking data which you thought you removed - but a per-user history would be great.

Answer 2

every once in a while I wish photoshop or word had such functionality, On the other hand like you said I often press control-z until it stops.

Another issue is performance. Think a draft word document being passed around and edited for weeks. It would be huge! and take forever to load.

Yet another issue is privacy. I don't want people to see what steps I took to paint the picture in Photoshop, or what my previous proposal to the board was.

In conclusion, I think it can be nice but you would have to have a way to purge the history for performance sake and for privacy and also perhaps if a person presses ctrl-z you should stop when you hit the state the doc was when it was last opened and ask if he is sure he wants to continue.

Answer 3

It seems to me that you don't want undo/redo, but file versioning, or revision control. (I don't know about Photoshop, but Word has this feature, disabled by default).

Answer 4

Perhaps a timeout on undo that defaults to 5 minutes (and may or may not be an editable timeout length)? It would address the very valid concerns that people have here about the value of undo data days/weeks/months later. And it would address the issue brought up here of accidentally closing an application and losing the undo data. And would maintain the value of holding down Ctrl+Z to clear out all changes during the "session" (where now a "session" means any usage that has inactivity less than 5 minutes at a time)

Answer 5

Personally I think it is bad. A Version control system would be better for this. I don't think users expect undo to work this way. I don't see how they can remember what is in their undo stack back several days. And potentially this can eat up a lot of disk space and memory in your app. I mean users essentially never get rid of data. How do you deal with use cases where users want to free space on their hard disk because they are running low?

Answer 6

I like this a lot, for small and larger projects.

Google Chrome when you restore a tab you accidentally closed, will come with full back history - which is awesome in its own right.

Some productive applications build their artifacts from a stack of actions, like 3D modelling where you apply operations in an endless stack and can then go in and change earlier operations and have that change propagate through the stack to the current modifier. The file format is then based upon the flow of actions, not on an end result.

Any application where it's not obvious to "publish" a final or public version of an artifact however would incur a lot of risk. Like if you send a word document with complete history of changes that would offend the receiver (like an offer where you've changed the client name from another client or whatnot).

Answer 7

My feeling is that this is the wrong tool for the job. Undo and Redo is about the actions within this process, so that I can undo/redo an action before I save and move on. Saving across sessions seems to me to be a different requirement, versioning is more the style. I can see there is a place for keeping the redo stack with a saved version of a file/application, meaning that you could open a version and immediately undo the previous actions, but when you start do more actions, you lose this - the stack is restarted.

I can see that it would be useful - I can see some times that I would like it - but I still think that it is not the right useage of this facility.