Undo — Not Confirmation — End of Discussion

Asa Raskin has made a really useful example of how to implement undo easily in user interfaces. Here’s the example file (linked directly to a page at his company Humanized). Try deleting some items and then press undo.

Note how there is no confirmation when you delete and the items can come back pressing undo.

I really like this approach, and have long been pushing for a similar approach in projects I have worked with recently.

Now, there is a constant resistance (usually from a technical perspective), when discussing undo. And in the project I have worked in, none of them eventually decided to have undo. Here are the reasons I have heard from customers deciding not to implement undo:

  1. Afraid of high technical costs
  2. Prioritized new functionality higher than undo
  3. Did not acknowledge the importance of undo from a user perspective
  4. Did not acknowledge the annoyance of having to confirm the action over and over

In case you missed the A List Apart article by Asa, go read his brilliant “Never use a warning when you mean undo”. I could not agree more.

More info:
Alistapart: Never Use a Warning When You Mean Undo
Humanized: Undo Made Easy with Ajax (Part 1) and part 1.5

[tags]asa raskin, usability, undo, confirmation[tags]

5 Responses to “Undo — Not Confirmation — End of Discussion”

  1. Thomas Baekdal Says:

    Interesting – nice find.

    May I add a 5th point: Problems with handling Undo in the browsers memory.

    Sure you can use AJAX to store previous “states”, but that implementation is also slow because it requires a roundtrip to the server. The browser should be able to store the previous states in memory – which the browser does very poorly.

    Also, how do you undo writing something, and then accidently hitting some key that either reloads the page or move to a different page altogether (in a web application).

    Undo is extremely important, but damn the browser is annoying :)

  2. Hannes Says:

    As Aza mentions in Part 1, the elements do not actually get deleted in the moment when the user clicks on the delete link but in an onUnload hook. IMHO the UX is even better when the elements do not get removed from the page, but grayed out/disabled and the delete link gets renamed to undelete. This enables the user to undo an arbitrary deletion instead of being forced to their inverse order.

  3. pik Says:

    Graphics are nice but isn’t this a stateful utopia ? isn’t the back button supposed to do the same work ?

  4. Mike Says:

    I agree with you 95% of the way, but there are cases where undo is not good enough.

    Here at felspar.com we’ve implemented a bulk emailer service, which we integrate with our bespoke system. One of our clients can potentially email around 150K customers with the click of a button. At that point, undo is not possible, as, once the email has been sent and received, it cannot be sucked out of the recipient machine by an undo operation. So, we have various test and preview screens before a final confirmation to send.

    In a perfect world, perhaps email could be un-sent or corrected… and network connections would never go down after sending.. and people could un-read emails. etc. Unfortunately, we don’t live there.

    Moral of the story: you often can’t undo changes that have escaped into the big wide world. In thoses cases, make sure the users know exactly what they are doing.

  5. Peter Bachmann Says:

    “Now, there is a constant resistance (usually from a technical perspective), when discussing undo. And in the project I have worked in, none of them eventually decided to have undo. Here are the reasons I have heard from customers deciding not to implement undo:

    Did not acknowledge the importance of undo from a user perspective”

    As a user who knows really next to nothing about technology and creating user interfaces (and here I am trying to learn for our next website rebuild…) having an easy to understand and run an “undo” function is critical.

    Make it work!

    How many times have I needed this? How many times would I have appreciated this? It runs into 3 or 4 times a day. Multiply that by usage online and the programming convenience of having multiple “are you sure” nag screens vs. the
    technical cost of having an oh so easy undo action – and of course it has to be action dependent, I think people understand that even just intuitively – well, clearly the cost benefit is not even debatable. A pox on your clients who wussed out.

    I think people would take to this like ducks to water. This is proper user interface thinking. Speaking as a user we need much more of this going forward; rather than convenience and the fastest cheapest way to get it done in technology!