1 Easier said than done

I think that the undo option is much easier said than done when it comes to web based applications.

posted at 08:43 am on July 17, 2007 by Abu Aaminah

2 Business case for Undo vs. Confirmation box

Great article right on the spot. Undo vs confirmation has been on my mind lately in a recent project I was working on.

Traditional desktop applications have followed this tendency for ages now, and you almost never see obtrusive warnings anymore (like “this cannot be undone. Continue?”).

The “business case” for undo gets better in the scenario where the user must delete multiple objects. The obtrusive confirmation box gets so annoying if, say, you have to delete 20 rows.

Once again, thanks for writing this article: It’s really useful in everyday web development.

PS. The name is Raskin , right? Or did you change it to Raszin?

posted at 08:53 am on July 17, 2007 by Jesper Rønn-Jensen

3 Good points

Yeah, those “this cannot be undone” warnings are really annoying and cause the user to keep things he doesn’t want to keep just for the matter that he’s afraid of making a irreversable mistake. But implementing an undo functionality is really harder than implementing a warning. The undo must be implemented all the way down to your persistence layer while the warning can be a simple JavaScript confirm.

posted at 08:57 am on July 17, 2007 by Brain Lambert

4 Undo ads another requirement

In addition to what Brain (or Brian – typo?) said: if you implement an undo function for a delete functionality you also have to implement a “empty trash” kind of functionality. Sometimes you have to delete something and you don’t want it to be undone. Adds up some extra effort.

posted at 09:14 am on July 17, 2007 by Calvin Larson

5 A possible implementation solution

I would use a ‘last operation’ table in the database to record what the user did last, together with a serialised version of the record that has just been deleted.

If the user clicks undo, it will read the details of the last operation, extract the serialised record and re-enter it into the database.

Obviously this can run into complications if someone adds the same record afterwards. Also, what if the operation affects multiple tables?

I think an article outlining possible solution for implementing this would be most useful.

posted at 09:15 am on July 17, 2007 by Dan Herd

6 Untitled

How do you undo program closing?

(One possible answer: save the work anyway, but in a special location that allows restoration on the next launch.)

posted at 09:59 am on July 17, 2007 by Sebastian Redl

7 Google Mail and Undo

Do you think they explicitly designed the undo functionality for the purposes of undoing a delete? I don’t.

Since they were keeping all mail items in the trash for a certain amount of time, the item wasn’t really being “deleted” until the trash was emptied. Can they undo the emptying of their trash?

Tin-Foil-Hat says: Isn’t it in Google’s interest to make their mail users retain their mail anyway?

I wager the intention was never to provide an undo function, rather store all e-mails anyway, and hey look – we can provide an undo action, since we do that already.

posted at 10:12 am on July 17, 2007 by Shaun O'Connell

8 Untitled

I think it’s important to make the distinction between two different situations which necessitate the option to undo:

• “Oh shit, I didn’t mean to do that!”

• “I deleted that the other day, now I need to get it back”

I have a feeling this article is implying that we should try to cater for the former, which perhaps means that using Gmail’s trash functionality as an example may confuse things.

In terms of implementation, a completely client-side approach would be to hold-off on informing the server that a mutable action has taken place until an unrelated action has taken place. For instance, if the user clicks “Delete item”, you can safely assume that they haven’t had an “oh shit” moment if they perform another of unrelated actions elsewhere. Another method might be to hold-off for a period of time – either will work. Server side would require short-term persistence of actions such that they can be rolled back when the user wants to undo. Sessions or cookies spring to mind, in this case.

posted at 11:10 am on July 17, 2007 by Nathan de Vries

9 tags and lables

Well, probably the approach of gmail is another. Since they have lables, they simply apply a label “trash”, and for the starred items they apply a label “starred”, and for the read items they apply “read”, and so on. So the “undo” is simply a “take-away-label-trash-from-item”.
Which is, in my opinion, the best solution.

posted at 11:30 am on July 17, 2007 by Stefan Insam

10 Oh no second

The “Oops!” moment is also called the Oh no second.
http://en.wiktionary.org/wiki/Transwiki:Ohnosecond

posted at 12:50 pm on July 17, 2007 by Monkey Get

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)