I met Paul Campbell for a coffee on Monday. I ordered an Americano, he ordered a Latte. But the “barista” asked Paul if he’d have a Cappuccino instead because he already had the foam ready! In the same way, web developers often make design choices that make their lives easier and this is the source, I believe, of 37signals‘ biggest flaw.
Note: There is no undo
In general, consumer software is designed to facilitate the user’s life, to obey their every command and to be their most loyal servant. And so, when I deliver my wish to my serving software, I expect it to be carried out immediately and completely.
Bad software does not obey as it should and causes frustration. When I say “delete this item now”, bad software insults me to the highest degree and asks “are you sure you want to delete this item”? Bad software second-guesses its master.
Because of the great volume of bad software out there, 37signals’ apps could never be labelled so. I use, and enjoy paying for, three of their products. But unfortunately, they are all riddled with confirm dialogue boxes. This is their biggest flaw.
These dialogue boxes are bad not only because they insult their master, but because they interrupt my workflow and are presented in a way that makes me hit “OK” so instinctively that I never get a chance to consider what they’re asking me.
But there should be
I believe in 37signals’ mantra: Half, Not Half-Assed. But undo is not one of these non-essential features that can be “pared” away. There should be an undo and no (or very few) confirm dialogue boxes in sight. And I’d be surprised if 37signals disagreed with this. I think the only reason we still suffer these annoyances in Highrise, Basecamp and Backpack is that undo is difficult to implement; and that’s not a very good excuse, is it?
Further reading
- Never Use a Warning When you Mean Undo at A List Apart.
- Better Web apps: add an Undo button.
- Having an UNDO when deleting stuff; Backpack customers crying out for undo.
- Undo Made Easy with Ajax.
9 Comments
Hey Eoghan great article on undo.
You’re right, it’s a hard problem to solve when you’re not dealing with the trivial like in “Undo Made Easy with AJAX” that’s just not going to work, there are a lot of flaws with it like say I never leave the page.
So yes the only real undo can come from a mix of server side and session state. I think that the period a user should be allowed to undo is until they close the browser, otherwise we end up keeping all their previous actions for ages (although that could be an interesting paradigm shift).
Posted by David Rice at 3:13 pm on 8 February, 2008.
Bit of a moot post in my opinion since you can’t CTRL + Z on a webpage.
Would you be happy with accidentally deleting a load of entries from a web app?
Posted by Cormac at 4:12 pm on 8 February, 2008.
Cormac, I’m not talking about text editing. I’m talking about application-specific functions, like deleting an item in a list on Backpack. Try CTRL + Z that.
Posted by Eoghan McCabe at 4:14 pm on 8 February, 2008.
We need a universal ‘Undo’ button framework, i.e. defined conventions for integration, placement, session storage etc. I’m probably the last person that would know how to make it work, but wouldn’t an undo feature produce massive overheads on the client side? In which case, should we be looking at the apps makers, or the browser vendors for this?
Presuming we eventually get there; as soon as the Undo feature makes it in to one app/browser, everyone will want (or need) it. That means you’ll kiss goodbye to your favourite notification type, Eoghan! Obviously, you’ll be sad to see it go.
Posted by Neil at 7:02 am on 9 February, 2008.
Very interesting post. Something i had never considered but seems obvious now you say it.
Posted by Alan O'Rourke at 1:49 pm on 9 February, 2008.
Cormac, just realised I misread your comment. But you seem to have misread my post! I’m saying people need to implement undo features in their apps.
Posted by Eoghan McCabe at 4:29 pm on 10 February, 2008.
@Neil There would be no significant over head to the end user to create a good undo system.
Just means when you create a task like delete or add you also create undo version of this each time (in programming this can be accomplished as a method in a class and using temporary mysql tables to store data that has been removed or reference to data that has been updated or added.)
In a development framework it is possible to build in some fundamentals that would mean it isn’t twice as much work to create your application but just a few extra bits here and there.
Undo in a webapp is great but not easy especially if you already build an application without catering for this type of core transaction tracking functionality. If you are starting out an application design, then now is the time to think about this.
So in PHP we need to be looking at the ZEND or CodeIgniter frameworks and in Ruby the ROR framework and see how this can be extended to do transaction tracking. I know for example ZEND has what is called RollBack function in the database layer which can give you that effect.
I wish i had implemented it in our 1time application for example. The reality is it would be a signification upgrade to the system at this point. Hopefully in the future we can.
Posted by Derek Organ at 4:24 pm on 12 February, 2008.
UMM, never saw it that way. Doesn’t double checking is good.. at least to prevent a fast typer from deleting something they didn’t mean to?
Posted by Hoperman at 2:29 am on 17 February, 2008.
I’d say at some stage in the future they may add in a soft undo, but the issue isn’t a design short-sight, it’s an engineering issue.
Adding a soft undo from the beginning would be easier, but to add it in later is harder. Indeed, many of the innovations of 37signals are what lead to the thinking that this type of undo is even possible.
I’m sure they’ve considered it, and may add it at a future date when the cost of implementing it makes more sense.
Posted by Kevin Cannon at 11:35 am on 18 February, 2008.