I’ve developed a strange habit over the years of obsessively pressing “CTRL-A, CTRL-C” whenever I’m typing – be it MS Word or WordPress. My own little personal “undo”. Well, I’ve had this problem with my mouse lately where it loves to register a double click when clicked once. For some reason this makes Firefox upset, and as I’m typing in a textarea (such as this one), it will occassionally turn the textarea completely white. The only way to recover is to refresh the page, and in most cases I lose whatever I was typing. Ironically enough, as I was wrapping up this post, guess what happened? I lost everything. Strange habits can be useful.
A List Apart commented on this subject in Never Use a Warning When you Mean Undo, an interesting article with no real solutions offered, but sparking some great conversation. It seems like everyone is seeking the “One Way” to appropriate oopsie handling, but the reality of the situation requires a much more complicated policy. The title of this blog may suggest disagreement, but in fact I only suggest that undo is only part of a complete policy.
The most important concept I take from this article is the necessity we face as developers to create apps for humans. Humans are imperfect, and the more robust an app the better it should be able to handle that fact. Humans make mistakes, and most Web apps currently do a flimsy job at best of helping a user recover from those mistakes. Sometimes the mistake isn’t even a result of human error, but technological deficiency in other systems and software.
However, I do not believe that we want apps which condone or promote stupidity. I do believe that we want apps which manage stupidity, and help create better users.
When it comes to managing data, especially in volume, a quick transparent undo could be extremely helpful. But a picture comes to mind, of one particular e-Commerce app I built which allowed the admin to edit an unlimited number of product records all on one screen. In addition to 20+ fields of data per record, a number of child records were editable for each product on this same screen. Handling and validating all that data was a party unto itself. Products had groups, groups had categories, categories were recursive… recording each and every change would have been insane, and the maintenance and development requirements would be unreasonable. Revisions and rollbacks were important on this project however, since multiple users were managing multiple records for a high volume production cart. We deployed two databases and users could play in the sandbox and rollback edits, deletes and creates from the last published revision if needed, and publish their completed work to the production server.
A bunch of solutions have been presented to the oopsie: better confirmation boxes, status flags, logging all changes, etc. And these are all appropriate solutions (or at least part of an appropriate solution) for the right application. For example, I would not allow a transparent undo on data that was part of a collaborative effort, as in the example above. However I would allow a change request or published revision since that undo could affect everyone else’s workflow. A confirmation box is an important element in preventing the cascading effects of human error, and in an enterprise scenario a verbose confirmation process might be your best friend. Another seemingly more intelligent policy would allow transparent undo’s until the data was committed in another process for the first time, but then we have to ask if the policy is still understandable and managable.
Single user scenarios are the most appropriate place, but most Web apps probably lie somewhere in between. For example in most popular forum software users manage their own posts, however a thread is a collaborative effort. Does a post reply “depend” on it’s parent, and on what attributes of the parent? The rather simple solution to oopsies in vBulletin or phpBB is an edit button that lets you change your post. In some cases there is a time limit on the edit, much in the case of Digg as mentioned in the above article. In general it’s a pretty effective solution for a collaborative forum/blog type situation where the dependencies are low, but this still isn’t a single-user scenario, and we could do better.
This is a pretty unorganized post, but overall I think confirmation boxes are perfectly acceptable given the state of the Internet. My best advice to a developer is to consider the needs of your user before diving into an overly-complex solution, but I urge anyone to experiment. I am personally trying to improve the usability of my apps every day, and believe that a great spec will identify the right combination of AJAX methodologies, confirmations, clear user messages, logging, states and sessions for the particular project.
Just my ideas – I could probably while away on this for a while. Eheh.
