In usability we trust

UX and all things web

No undo? Redo!

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:

Are you sure you want to delete this note?

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.


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


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.


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.


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 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?


  1. I find it kind of redundant to soap box on about it but essentially your point, that it’s superior to provide undo or multistep undo over a confirmation dialog can be pretty much taken for granted.

    What would have been of more value would be suggestions on how to implement mutli step undo given a website’s potential for actions to be affecting disparate datasources where transaction boundaries may not be defined or able to be rolled back. Distributed systems can make undo functionality very difficult, for example undoing making an airline ticket booking or an online purchase may require distributed transaction coordination between many independent systems, e.g. the financial system, fulfilment system, the website itself (shopping cart), etc.

  2. Simon: Well, although it might seem granted that having an undo is a superior solution to just have alerts, I find it odd that it’s so rare in web applications. Yes, there are circumstances when there’s really hard to implement an undo, like many of the examples you bring up, but there’s also a lot of circumstances when it’s really easy to implement it. I think the main problem is that it’s often is not taken into consideration at all when building a

    It’s quite possible to have undo in airline ticket booking systems but the underlying systems need to support this. Right now the bookings systems out there are archaic and does not, so right now it’s probably really hard to do. But if this had been taken into consideration while designing these systems, it’s really shouldn’t be any problem to implement.

    You’re absolutely right that we need more patterns on how to implement undo in web applications. I think I will do my part and write an article about one way to implement it.

  3. Shut the fuck up simon

  4. Damn I wish I had an undo

Leave a Reply

Your email address will not be published.