Why is it that web apps very often lack something that we take for granted in most window applications, namely the undo function? Is it because it’s not needed? Is it too hard to implement or is it simply just because it’s something that developers don’t think is needed?

The most common solution to prevent user errors is to simply throw an alertbox warning about potential damage or loss of data that the action might cause. Even otherwise awesome web applications often resorts to this behavior. Take for example Backpack from 37 signals, which I regard a very usable and overall great product. When you try to delete a note they throw this alert in your face:

This is, from the developers point of view, the easiest way to handle it. It’s almost too easy to implement an alert and many developers habitually do it without giving it a second thought.

A far better solution is to use an undo function. Although harder to implement it maps so much better to the users mental model and behavior patterns. As Alan Cooper puts it in About Face 3:

Users generally don’t believe, or at least don’t want to believe, that they make mistakes. This is another way of saying that the persona’s mental model typically doesn’t include error on his part. Following a persona’s mental model means absolving him of blame. The implementation model, however, is based on an error-free CPU. Following the implementation model means proposing that all culpability must rest with the user. Thus, most software assumes that it is blameless, and any problems are purely the fault of the user.
Alan Cooper, Aboute Face 3

An undo function enables the user to easily recover from mistakes and also encourage him to explore the interface without fear of doing irreversible damage. It transfers the responsibility of handling errors from the user to the system, where it righteously belongs.

Problems with alerts

Alerts seems to be the dominant solution to handle potentially “harmful” action but there are several problems with them.

1. Interrupts workflow
   It makes the user have to stop and consider what it says or just ignore it and dismiss it as fast as possible.
2. Locks up the whole browser
   Alerts that are application modal, locks the whole browser, preventing the user from doing anything before he dismisses the alert. This is plain rude behavior! Sure there are times when it’s motivated but often it’s not. As a developer you have to ask yourself: “Is this action so serious that I have to give the user the strongest possible warning. Maybe there’s other ways of doing it?
3. Users tend to just click “OK”
   If the system throws alerts all the time during normal tasks, the user eventually tends to ignore them and just habitually click “OK”. When he realizes that he’s deleted the wrong document, it’s already too late.

Document modal alerts

Document modal alerts has gained popularity on the web but are little better than application modal dialogs. It’s the kind of alert that looks like lightbox showing an image (Click one of the images below to see what I mean). The only difference from application modal alerts is that they don’t lock up the whole browser but only the page you currently at. They do however share the same problems.

Examples

Here are some examples of web sites that have implemented different variations of an undo function.

Flickr

Flickr has a nice way of showing important messages. The message is a link that takes you to the important information and in the right part of the message box there’s a close button.

When you click the close button the content of the message box changes into a short note that the message will disappear the next time the page loads. But there’s also an undo-link that gives the user the opportunity to change his mind.

This design pattern encourages the user to click things and explore the interface. The ignorant user is not punished for clicking the “x” not knowing what it will do. If it didn’t have the desired effect he can very easily recover from his mistake and still be able to read the important message. If it did what he thought it would he can just carry going about his business.

Gmail

I think Gmail was the first web app that I seen using this design pattern. Their implementation gives the user the chance to undo the latest performed action.

Google Docs

In Google Docs there’s a similar solution. Whenever you perform an action such as moving or deleting a document. You have the opportunity to undo it until you perform another action.

Writeboard

37Signals Writeboard facilitates a different kind of undo. When a Writeboard is deleted the following message appears enabling the user to, for a pretty long time, undo the deletion.

Mixx

Mixx takes on a different approach with a time-limited undo. When you submit a new story, you have 15 minutes to edit or delete it. After that you can no longer do anything with it.

Final thoughts

Although some web apps implements an undo function it’s still very simple ones, enabling the user to undo only the last action performed. The next logical step should be to implement a multi step undo, giving the user real confidence in exploring the application.

Aza Raskin has in his blogpost Undo made easy with Ajax (Part 1) and (Part 2) made an attempt to implement an undo function. He have, with the help of jQuery, made a simple one. It’s not without flaws but is still a good example of one way to implement it. He has also written an article on the subject, published on A list apart called Never Use a Warning When you Mean Undo.

Paul Boag over at Boagworld also have some interesting thoughts around undo.

What do you think about the undo function?

About the author

Gabriel Svennerberg is an independent Interaction/UI Designer and Web Developer living in Sweden. When he's not busy building web application designed for humans, he writes about all things web on his site In usability we trust. Gabriel is the author of the book Beginning Google Maps API 3 published by Apress.