For a single user app this may work, for a multi-user app this has real problems. I think I have deleted something, and open another window only to find it is still in the database because the first window has not unloaded. I call a friend to collaborate and they still see the old version of an item because it has not updated yet, but is sitting in the event queue.

I agree UNDO is important even in web apps, but since web apps are generally multi-user the implementation needs to be in the server not the client.

Alas, neither of the above work in Safari uder Mac OS X. :-(

The perils of web development..

Not very bullet proof.

@ Michael: Agreed. I think I say as much in the caveats section. This is a light-weight undo. If you know you are working in a single user situation, you can use this kind of solution. For instance, this undo would be great for making your web-based RSS feed manager a lot nicer. Or it might make removing spam from your Wordpress installation more forgiving. There are slightly heavier weight solutions (like to one proposed by Alexander) that do solve multi-user problems. If you need that, then go the extra implementation mile.

@ Bryan: Storing an undo queue on the server is definitely a more robust approach. However, losing a connection does not necessarily mean the data would be lost. A simple cookie storage method is enough to solve the problem. But even without that, your argument is for designing to the lowest common denominator. Were the web still following that approach we’d never use AJAX or flash. My answer is degrade nicely (if you are worried about the mobile market force degradation based on user agents) and design for usability.

@ Reid: Thanks for finding that. It is fixed now.

@ Ryan: This is a proof of concept. You may have to do something more clever that simply hiding a to-do item. But we are software engineers, we’re smart enough to tackle this kind of problem.

And now to integrate this with everyone’s favorite undo button for the web, the Back button.

erm s/FIFO/LIFO/
Sorry about the extra post i couldn’t find an edit…

Users DO care when they delete an item, to later learn that it wasn’t actually deleted. With that in mind the visible bit is one of the better solutions to this problem. Entirely client-side is going to cause issues even in a single user situation:

[user opens new tab] “Hmm.. why is that TODO item still there, I just removed it…”

The issue raised by Alexander is an important one. While you may be designing a single user environment, on the web there is no way to guarantee that they will not have opened another tab. It seems people frequently have dozens of tabs open, and so will often create a new tab to go to a site because they have forgotten that it is already open and any visual indication of such is lost amongst all the other tabs. Once that happens you then get the “What? I thought I deleted that” situation in the new tab. While it is a good simple example, I think it has little practice use as it stands in this post (though I look forward to the rest of the series).

I’m probably going to regret this, but I’ve thrown together an example of a server backed undo-todo list. It would be mixed in with some daemon that periodically removes entries if their timestamp is older than some point. The other thing that’s not visible here, but if you’re logged in as a different user it won’t show deleted items, and if you try to request an item by url, it’ll 404 on you. It’s probably still horribly buggy, and wsgiref’s WSGIServer is really slow, but you can check it out at http://www.geekfire.com:8888/todo. I’m happy to share the code if anyone is interested.

An elegant and robust way to handle undo is the Command pattern (see “Multi-level undo”). You can even implement the command pattern client-side, and have the undo/redo methods in the Javascript classes perform the asynchronous requests we’re used to writing (especially for a “rich client” type application), although you might want to consider implementing it server-side and persisting the command queue at a session level if you’re interested in graceful degradation.

You said it was easy, but the caveats point out that it’s actually not. For ‘real’ undo, you need to implement functionality at the server.

Interesting article. The only thing I’ll say at this point is the argument that a confirmation box is not “humane”. Granted, the standard javascript browser confirm() is not optimal. That’s why I never use them. Instead I use something like Prototype-Window (http://prototype-window.xilinus.com/index.html) to display alerts and confirmations. This way, I am allowed to switch tabs, etc with no problems.

Since this article did contain caveats I’ll keep my other comments at bay until I see the other solutions to come.

disclaimer : offtopic
in your blog if i click ” Add yours below.” for comments.
- i jump to “comments” (same line as link -optically) and not to the comment-form
- the link is not understandable in it self (accessibility), consider adding a title.

furthermore
the submit-button has a accesskey of “s”
- as far as i remember “s” should be used for “Skip-navigation”
…by the way accesskey of “9″ is for feedback/comments-forms

…. i love the articles of this blog, but i wouldn’t expect this tiny flaws here – so i couldn’t resists… ;-)

My proposed solution:

User Clicks Delete
- Item is deleted ( the item’s ‘deleted’ property in DB is toggled to true)
- Item removed from UI
- Undo button appears

User clicks Undo
- Item is ‘undeleted’ ( the item’s ‘deleted’ property in DB is toggled to false)
- Item added back to UI

Summary:
Rather than queueing actions for execution you execute on demand. In the undo queue you add a query that will undo the last action.

This pattern would work in more complex cases as well. For example, user edit’s the name and description of an item and clicks save. You grab the previous values and build a query that will reset the item’s name and description and store it in the undo queue.

-Lokesh

Hi Aza, I really like this idea. I talked to you at the Rich web experience conference in San Jose. Wanted to share my opinion on some issues people shared:

1. first of all it is about giving the users a great experience. We are trying to make the webapp as versatile as a desktop app in some sense.

2. I like the server side solution. Yes it is more robust, but If we have that we are basically killing the servers. The back and forth using XHR can swamp the server. Also since each request is independant, the overhead on the backend will be high

3. About the undo in a LIFO, we dont have to worry about it too much. Just in MS word, we only undo the last action, not something that was done before that. Once that is undone, we undo the one before that.. it is quiet simple.

4. finally I would suggest something like auto-save. This way the onus is not on the user to “commit” all actions.

Finally, I think this “undo” maynot apply to every webapp out there, so we as s/w developers should pick and choose wisely.

Of the critical comments, most relate to the technique shown here whereas I’d like to focus a little on the interface and how this works against, not for, this technique.

Firstly, I know it’s just an example/proof of concept, however I find the interface shown here to be misleading enough that a little something needs saying. And some people will use the given example too directly (“I like it, I’ll use it”) without thinking things through fully.

For me, I have a slight problem with ‘delete’ next to each list item and a ‘Done’ button. I think more accurate terms need to be used so as to avoid user confusion.

Through the client interface we’re modifying the list contents and, when happy, making the changes permanent.

We’re not deleting items from the list and then being ‘done’ with what we’ve accomplished.

So let’s rename the per-item ‘delete’ to ‘remove’ and the ‘Done’ button to ‘Save’ (or ‘Store’).

This relates to what we’re actually doing, as opposed to describing what we’re sort-of pretending to be doing.

The difference?

‘Done’ means what? So I’ve deleted some items from the list. Why do I need to be ‘done’? I’ve deleted them – that’s it – I’m already done.

Less expectation will be put on changes being real. At present, users could easily expect the deletion of an item to propagate across tabs and so on, as mentioned by others. This can be dealt with, but in dealing with it we’re merely covering our tracks from having partially deceived the user.

So with ‘remove’ and ‘Save’ what do we have? A more exact representation of what we’re doing. I remove items from the list at will and don’t necessarily feel it’s a permanent change.

With a ‘Save’ button, it is more clear still that I have to perform an action to make my changes permanent – with a ‘Done’ button, the user has to make the connection – and I’d not really be expecting unsaved changes to propagate across to anything else.

Example relating to how the current list behaviour can be confusing:

Two users both viewing the same shared nework folder. User A deletes a file and expects it to be no longer present in user B’s view without needing to further commit the action. User A gets confused when user B’s view remains unchanged.

Example relating to how ‘remove’ doesn’t include the expectations of ‘delete’:

Two users again viewing a shared network folder. User A begins renaming a file. User A doesn’t expect these changes to propagate across to user B’s view until committing the changes – clicking away from the file name, pressing ‘enter’ etc. User A realises their change to be non-permanent and expects the need to commit before seeing the change reflected elsewhere.

And to make this criticism constructive: use the correct terms for what is happening, give the user the correct expectations (relating to what the technique is actually doing, not pretending to be doing) and we no longer face some of the problems with this technique upon which people have commented.

This is a very good script.

can you please put the source code of the first example that “Try out the to-do list with the standard warning dialog box solution.”

i have a example on my site:

http://scripts.ajaxflakes.com/category/accordion/

I see a lot of “workaround” ideas for Undo, but haven’t seen a true (desktop equivalent) design pattern emerge yet. I really hope we don’t get to the point where users on the Web have to think about what “kind” of Undo an application implements (flushing a queue like a Save, or only commiting on UnLoad), because there’s already a universally understood version of Undo on the desktop: your document state is reverted to exactly what it was before you did the action, but yet, your actions are still committed immediately.

Client/server development and multi-user issues certainly make Undo implementation a lot more complex, but I think the only TRUE Undo is one that keeps copies of data state after each action (at least until the end of the session, when the intermediate states can be flushed), similar to version control, that can be rolled back and forward.

Any workaround Undo I’ve seen so far severely limits the wonderful collaborative nature of the Web, especially even for some of the example applications, where we could be talking over Skype while both looking at a to-do list and seeing each other’s changes as we do them by refreshing our browser.

I really don’t think there’s a quick fix for this important problem. Versioning the data’s state as people perform actions is the only way to go.

For a single user app this may work, for a multi-user app this has real problems. I think I have deleted something, and open another window only to find it is still in the database because the first window has not unloaded. I call a friend to collaborate and they still see the old version of an item because it has not updated yet, but is sitting in the event queue.

Those ‘are you sure’ boxes have always bugged me. I am generally not ‘sure’ about anything; it just seemed like the thing to do. So to get things done, I have to lie and say that I am sure. Therefore if things go wrong I’m really set up to take the fall. Not only was I warned, but I lied about being sure.