Tuesday, May 7, 2019

interaction design - Undo History - Why limit it?



Why do most applications have fairly limited 'undo' history functionality?


I've been caught out on multiple occasions (granted its technically my fault) where I've needed to undo a number of changes (be it in photoshop or whatever else) to be hit by a greyed out undo button - no further history available. I don't know about you, but potentially losing a lot of work because of this limitation results in a terrible user experience.


Is there a reason why applications can't just hold at least a full-session history? Surely a temporary file is all that's needed to store changes and said temporary file could be configured to the user's preferences (in terms of max size, etc)?



Answer



Trust me when I say this - undo/redo is one of the biggest implementation, testing and maintenance headaches in any significantly sized application.



Granted, it is a wonderful thing to be able to undo/redo something as it relaxes the user and lets them test and explore their environment without worry. However, the usefulness of an undo history starts to diminish right after the first undo. Slowly, mind - but surely.


Full kudos to those that do provide a full undo history, but it is almost certainly as a result of a well planned, well executed approach with a supporting frame work, implemented from day 1, and around which all functionality revolves.


If that framework is not introduced first, it's a major challenge to bolt it on afterwards, and it's easy to get bogged down in it.


The problems lie with:



  • The rapidly escalating complexity of testing undo/redo with any possible action in any possible sequence of changes of any size.

  • Ensuring that the state of the system after the undo of each step is the same as it was before it was originally done, - e.g. ready for the next undo, or the next redo

  • Correct consideration of what is an undoable action


In addition, it is almost universal that if you undo a string of actions and then make another change, you cannot redo all the steps you just undid, because the system has changed state and the redo may well not be valid.



Now one popular use of long undo/redo history is to go back and look at something how it was, and then to go forward again.


I would suggest that the annoyance of not being able to undo more than say 10 steps is not nearly as annoying as undoing 50 steps and then accidentally pressing a keyboard button which throws away the redo history so that you can't redo all that work you just did. I for one get very nervous when I've undone something over a lot of steps, and tend to save first as a fall back, and maybe therein lies the lesson: save often and save versions.


I totally agree that a full undo history is highly desirable - it's just not simple, and that's why it gets dropped down the feature list when tight time and budgetary constraints come into play.


No comments:

Post a Comment

technique - How credible is wikipedia?

I understand that this question relates more to wikipedia than it does writing but... If I was going to use wikipedia for a source for a res...