I oversimplified Aza’s idea. It’s actually two sentences. (The first is “don’t use alerts.”) The second is “use undo instead.” He argues that warnings are bad, because they are habitual. He points to the example of Gmail’s undo as an alternative.
Some posters suggest rewording alerts, but fortunately “Mike”:http://alistapart.com/comments/neveruseawarning?page=2#12 points out early on that it’s still ultimately an alert.
Well…
Gmail’s undo is ultimately an alert.
The real confusion with popup warnings are their numerous options. You get an “OK,” a “Cancel,” and occasionally an “X” in the upper right to further complicate things.
Gmail’s undo, in contrast, has only one option. The undo has no close button. It sits on the screen until you take some other action, at which point it disappears.
The author would have done us a better service to distinguish an “undo” from an “warning” rather simply defining them as unrelated things.
Copy & paste the code below to embed this comment.
Everett Lindsay
Not that anyone asked, but in my opinion “Robert”:http://alistapart.com/comments/neveruseawarning?page=2#16 and “Marc”:http://alistapart.com/comments/neveruseawarning?page=3#25 and “Nathan”:http://alistapart.com/comments/neveruseawarning?page=3#28 present the best building blocks toward constructing an “undo methodology.”
Instead of asking “Do you want to quit”? perhaps we should ask “Would you like to Save before you quit?”? and then label the buttons “Save”? and “Don’t Save”?. This way the user can’t just press OK or Yes by habit. At least for me it’s harder to accidentally press “Don’t save”? than “Yes”?.
Even though this is already explained in the article (when deleting the wrong event in Google calendar), I’ll give another example: In Photoshop, I often create, or open and modify, an image that I never want to save—usually when I want part of it for the file I’m really working on, so I often blindly click buttons even though they are quite clearly labeled with their intention, and not just “OK” or “Cancel”. Sometimes I’ll even open a previous version of a file (with a similar filename and data), then tweak something to see what it looks like, but not want to save it, while still wanting to save the latest one. So even if it was really clear about what was going to happen, a mistake is still possible. I’m sure there are many other examples of similar situations.
As for the people saying that this simply isn’t possible in many cases, I think they are overlooking the many times where this is possible, but hasn’t been done because it’s easier not to. Then there is also the argument that immediate action with an undo option is simply better than a confirmation box, from a usability angle.
Even if a proper undo is not possible, sometimes data recovery would be nice, so that people can tell what has happened, and recover any important bits of data, even if it means jumping through hoops to get it back where it should be.
Sooner or later people will experience the “oops!”? after having deleted the already deleted mail from their google trash. And after that comes the “trash-trash”? that holds items that were deleted from the trash. People will accidentally delete things there, too.
You’re forgetting something here (aside from something addressed at the beginning of the article): As these mistakes are from habituation, we can assume that they are generally something that is less likely to happen from a statistical point of view. Therefore, adding the trash layer isn’t just another layer to make mistakes that also need to be addressed, but a way of reducing the consequences exponentially (for lack of a better word). It’s about reducing the margin of error to a more acceptable level.
I realize a good number of the pieces on this site are more theory than technique. But this particular article does little more than tell you “don’t use alerts.”? Aza, I’m not trashing your idea, but explain, dude.
Heh….In which language? In order for more technical things to happen, people first need to be made aware and convinced of the issue. This is what this article is doing.
I think that one of the best functions google ever implemented was the “get my email back” function. If it was sent by gmail to gmail (ie it still resides on Google’s server) you can get it back if you hit send instead of “no, i don’t really mean to send this un-pc rant to my boss”
Wish there was a way to do that across the board.
Way to go google.
Designing the Obvious: A Commonsense Approach to Web Application Design by Robert Hoekman (an excellent book) will find this article awfully familiar. [ “Example”:http://safari.peachpit.com/0321453476/ch06lev1sec2?imagepage=168 ]
Not that there’s anything wrong with preaching good gospel, but it’s a bit cheap essentially regurgitating a partial chapter from someone’s book. In my humble opinion.
Copy & paste the code below to embed this comment.
Andy Lee
I like the concise rule of thumb: “Never use a warning when you mean undo.” It’s been said before, but it definitely bears repeating.
However, I think the article uses a bad example in making its case. I can’t recall a single application I’ve used recently that asked “Are you sure you want to quit?”? The applications I use assume I do mean “Quit” when I say “Quit”; what they want to know is what to do about unsaved data, which is an entirely different question. I want to be asked for confirmation in this case, because there’s no way the computer can know the right thing to do—whether to always save the changes (and allow me to undo them later by reopening the document), or always not save the changes (and remember them when I reopen the document so I can pick up where I left off). It shouldn’t automatically save my changes, because I might not realize or remember that I changed something. It shouldn’t always not save my changes, because I might not realize they’re unsaved—so I send my boss a spreadsheet that I thought I’d updated, but I was wrong, because the application exited with unsaved documents in exactly the same way as it exits when I’ve saved all my documents.
For the above reasons, I disagree with the statement that “With a robust undo, we can close our work with reckless abandon and be secure in the knowledge that we can always get it back.” (Also, if you know your work is recoverable, you aren’t being “reckless,” but that’s semantic quibbling.)
By the way, there’s another issue that I think has been glossed over, unless I missed it in the comments, and that is the issue of multiple levels of undo. Multiple undo is extremely valuable, but adds conceptual complexity.
I think the undo function would be a neat inclusion in web applications. I believe that this is easier to implement than I thought.
However, if we are to have a history of things we have done in the application (multiple undo), it would seem like way harder to create. Is the multiple undo really necessary?
Lets see the 1 layer of undo that is meant for the ohnosecond mistakes be integrated into web applications first.
Copy & paste the code below to embed this comment.
Mike Watson
One option could be to track users changes using a mechanism similar to the shopping basket concept. Changes are requested but not implemented until the user proceeds through a ‘checkout’ function to commit them. This would roll the undo and confirmation functions into one mechanism, which could be tracked client-side or server-side.
This whole concept becomes tricky very quickly when you’re working on shared data that multiple users can update though.
Copy & paste the code below to embed this comment.
Andy Lee
Multiple undo might not be so necessary in web applications. Handling the ohnosecond case gracefully is already a big step, and the cases where I mostly rely on multiple undo—mainly during text editing—would be handled by my browser’s text editing support. At the very least, though, I would consider the possibility.
Even single-undo needs thinking through. Should there be a “Redo” option, or should “Undo” mean “completely forget that last thing I did”? If you provide several web apps, should they be consistent in their Undo policy, or should each one use a policy appropriate for that application?
I would like to see an article, if there is one, that analyzes the undo approach for a variety of web apps, real or fictional. I’d like to see examples of thought processes that lead to good decisions.
There is one particularly nasty use case when undo just doesn’t work the way it was intended, or rather where it’s hard to come up with a working undo strategy: it’s when there are multiple people working on the same thing.
I often have the “oops moment” when using Gobby, a collaborative editor. Sometimes I will accidentally delete text that was written by different users. I immediately hit the ^Z, but in vain: Gobby doesn’t have undo, and even if it had, how would it be supposed to work? Should it be global, so that others can undo my editing, like in wiki? Or should it be local, so that only I have the power to put that accidentally deleted text back? What happens if someone already typed something in that place? What if the operation was something different than just deleting the text? Moving text around can be a tricky case, especially when someone else already modified it at its new location.
I think that dividing the document into smaller parts that can be acted upon (and reverted) independently is one possible solution (not unlike the section editing in Wikipedia), but there is a lot of room for improvement.
Great point! In real life practice this has been really useful too. Blender (a 3d modeling app) saves the file you’re working on whenever you quit in a special quit.blend file, and it’s saved me many, many times. It seems that maybe implementing that idea in desktop apps might be even easier than in web apps, at least in the closing-when-you-don’t-want-to sense.
Copy & paste the code below to embed this comment.
Everett Lindsay
How about English?
My “title”:http://alistapart.com/comments/neveruseawarning?page=4#40 notwithstanding, I think you may have missed some of the subtleties of my criticism, “Justin”:http://alistapart.com/comments/neveruseawarning?page=5#43 . Notice that I went on to point out several posts that “inform without getting overly technical?”
Another way to state my view is: solid concept, but it doesn’t warrant an entire article. We can agree to disagree on that.
I think Aza’s point could have been made in one or two paragraphs, as an introduction. He then could have spent the rest of the article preparing us to think in this “undo paradigm.”
“Example”:http://alistapart.com/comments/neveruseawarning/?page=3#22 : in a world of undo, your database will need an audit table. (See, that’s not overly technical. I don’t tell you which database, or what fields. Programming language never enters the conversation. It’s in English.)
Great points all round, I would just add that for significant business benefits, carrying out user testing, especially as a user is negotiating their way through a checkout process, can really add weight to all the intellectual thoughts of any in-house or external people involved in optimising the user experience of a given site with warnings and undo’s featured.
I’m a new reader of ALA and by simple reading this article I’m very inspired. I’ll be sure to check back to what’s new on the site, after I dive into the archives for awhile. Thanks for your amazing content ALA, keep it up!
Copy & paste the code below to embed this comment.
David Chong
I think the talk about ways to make email undoable is missing part of the picture. Although the protocol itself is asynchronous, the preponderance of blackberrys suggests that people are increasingly using it for business-y things that are time sensitive. Any delay mechanism is just going to tick off anyone that does time sensitive stuff over email.
I remember first being turned onto the idea of handling an ‘infinite’ undo stack in Jeff Cooper’s book About Face (1995), then I recall hearing Apple brag about Undo stacks in Cocoa in 1997 and several books since have cited the idea as the ‘right’ solution.
It’s often talked about in the same conversation about making people click ‘Save’ and even having the concepts of applications being bad examples of ‘exposing the implementation’.
So, where is it? I suspect it’s hard, expensive, and doesn’t sell well on boxes. Folks who love applications that do it probably don’t even realize it’s a reason they think ‘X is so easy to use’. I’ve asked people who use FileMaker whether they appreciate not having to save files, and none of them have noticed (aside from the occasional novice who feels really uneasy about the app if there’s no Save button).
In short, it’s the right thing for the user, but we need better metrics to justify taking care of the user (we used to have terms like ‘quality’ and ‘customer support’) to those calling the business decisions.
Copy & paste the code below to embed this comment.
Bob Prokop
Undo is an ultimate solution here—but what if you could actually customize an actual alert/confirm dialog—and I don’t mean by using your own pop-element, but the actual JavaScript functions? That would go a long way towards curing the OK/Cancel issue. We could use some more flexibility in terms of what can be done with the functions—including content, formatting—at the very least customizing the text for the button elements. And please—I don’t want to hear about Microsoft’s modal windows here ;-)
We cant forget however the original idea of a warning. This just happened to me, I went to text message someone on my phone and scrolled down one option too far, delete. I just sighed in sadness as my phone displayed “contact deleted” No warning, no “are you sure?” No undo. So lets not forget that even a warning is better than nothing at all. Thank god for bluetooth synchronization to address book!
Great article Aza, this makes a lot of sense and I do love how Google does this in Gmail. It’s helpful to know that I can always get something back. I’ll definitely be implementing this in the stuff that I build.
Copy & paste the code below to embed this comment.
Arindam Das
That’s a good article AZA. The points that you have discussed are real for sure. But do you think that the same solution is going to be applicable for all types of applications, be it web based or standalone? I mean to say, is it all right for all the instances of deleting anything, from any kind of digital repository?
I understood the humane factor, the tendency of the human beings to get habituated. Google has done an excellent job on Gmail. But why didn’t they apply the same for the calender? Should we conclude that they did not give it a thought for the same? And yet, they came up with such a good solution for the mails, when they know that the same instances can occur for the calender as well.
But I must admit that, the points are applicable to some extent, and that would be very helpful for the user experience.
Good article, but the discussion assumes undo is the best solution without a viable discussion on the matter. There aren’t any arguments against this or for another solution altogether. Undo is OK, but how about arguments against such as privacy, development time or file space? Warnings are good. Undos are good. Neither are perfect, so just remember to choose what is best for the particular application – because in the real world, developers create apps for real users, within budgets. Develop accordingly.
Copy & paste the code below to embed this comment.
longin kandinsky
we also can make habit of being cautious of what we are doing. And eg. data loss is such a great thing to doing so. And this can result only in faster development and “smarter” users and then even faster working with the program when it doesnt bother you with confirmation about everything you are going to do.
@Louisa: Undo is ALWAYS better than warn. Let’s take your objections one by one:
If privacy is important, then the existance of the data matters to the user. If it’s important to delete it when it’s not necessary, it’s important to keep it even in the face of user error. To make them comfortable that their deletion of sensitive data will actually occur, you say “This action is undo-able for the next ten minutes.”
Jef’s point (and his son Aza’s point) is that Warnings Do Not Work. If development time is important, then don’t waste time writing code to warn the user. Just do the action.
File space is always cheap relative to a user’s work output, and it’s becoming cheaper and cheaper by the day. Remember that when someone wrongly destroys their work, they almost always realize it within a second or two. You don’t need to keep a forever undo; being able to undo the last action is sufficient. So … you defer the actual action until the next command is entered. And if it’s “undo” then you just saved somebody’s bacon.
I never said undos are better than warnings, so please read the comment over again. Nor am I saying that warnings are terrific, either. I gave a comment on how the article was written definitively without any strong arguments.
I agree that actions taken should have immediate results, ie: click a button and it’s represented action occurs, like delete. That’s good HCI I think. But ours are a matter of opinions here on this case.
The code needed to write either case: A. undo action taken, make sure old data is available for x amount of time, take appropriate file space measures, create interface for undo action or selections or B. warn before doing the action forever – is actually more on the undo side – so arguing for the developers’/tech staff’s/etc sake is a bad argument.
My comment was trying to get at that even though it brought up a nice issue, “why warn at all?”, it doesn’t give any OTHER arguments altogether. How about another solution to interfaces that are prone to be confusing and how easily people delete things without realizing that they were deleting them? Why is it always the person’s fault? Why not better HCI design? Or why not VERSION control in general? Who knows, because the subject matter of the data is up in the air – and that’s key to how it should all work. The type of options would all be different when using Outlook, your computer’s file system, a content management system, Adobe Photoshop, Notepad, Calculator – which all depend on different types or file space amount, memory, hardware, interfaces, target audience, etc. This is quite like how Microsoft develops operating systems for the regular Joe (Are you sure you want to do that?) where as Linux develops operating systems for a developer (…no warning…). Some may say that’s why Linux or OSX is better than Windows, but millions of people prefer Windows over others because of small things like that, warnings which help direct them into good decision-making. There are a lot of factors to consider in any piece of software you’re developing as to what might work the best – and that isn’t ALWAYS undo.
The article ignored the thoughts of also, “well, how many undos do you give?” If space is a non-issue, and so is memory, and so is time, and so are salaries (we’re getting rid of a lot of factors here to make this possible) then you should never limit it – undo should cover every action taken from once the user starting using file/software/OS ___ . Because no amount of undo is ever good enough, once you give a user one, they expect more and that’s why programs now-a-days allow you to put in more and more undos in the history than ever before – users are dependent on not being accountable for data. That being said, I should be able to undo something I deleted 10 years ago, right? Or should I just be done with it after my 1 warning?
When is the user accountable? When are the HCI designers accountable? Can we not think of any other solutions?
Another possibility to prevent the user to click on the OK-button accidentliy might be to poste the question in the warning in the way that the user has to click the NO-button to continue. If he then clicks the OK-button although it wasn’t his intention he will just get one step back in the process. However, sometimes the question doesn’t sound good if you phrase it the other way round. But normally this is a good option.
Copy & paste the code below to embed this comment.
Andreas Ringdal
@Phil Dubai, though your solution will prevent more users from performing operations they did not mean to perform, it will annoy a lot more users that clicks ok and expects their action to be comitted.
Copy & paste the code below to embed this comment.
Andreas Ringdal
A quick fix to this might be to accept the users decission and display a status message with undo option, and a 10 seconds counter.
“Message deleted, Undo (10)”
Copy & paste the code below to embed this comment.
Viktor Varland
One thing I’ve been implementing for a while is flagging content as deleted in the database.
When I feel it’s time to clean it up, I just run a delete function on the database where deleted equals 1.
It would be very easy to implement an “undo” function for users in my current applications, and hell, now I just might do so.
I wrote an article about just this, more from a developer perspective.
http://obsurvey.com/Articles/WhereDidUndoGo.aspx
After I wrote my articel I found this articel, and I agree with what Aza is writing.
And It’s really not that hard to implement…
Email programmes should come standard with an undo send facility. Or a delay send. “are you absolutely sure you want to do this? sure you don’t want to wait till tomorrow when you’re sober/less angry?” Then it sends it round in a loop, which if you’re sober/not angry is easy to override, but otherwise (specially if you’re pissed) moves the send button around in a random kind of way. I just think computers should be more fun.
Copy & paste the code below to embed this comment.
smhart1
Users would be less likely to need to need “undo” if the messages more appropriately matched the answer.
“OK” and “Cancel” are difficult to answer; it’s not always clear thet “Cancel” is the opposite of “OK”. Perhaps users wouldn’t make mistakes as often if they were aked “Are you sure you want to delete foobar.doc?” and the buttons are “Yes” and “No”.
I know that some environments don’t allow you to change the options; I’m constantly challenged with trying to word a message that can easily be answered with “OK” and “Cancel”—it’s very difficult.
One common approach to the undo button is a soft delete, most of the time undo buttons come into play with CRUD operations, particularly the delete action – by giving a table a soft delete column (I like the name is_deleted) you can control the state of a record quite easily, by never actually removing the record the user is attempting to delete.
81 Reader Comments
Back to the ArticleEverett Lindsay
I oversimplified Aza’s idea. It’s actually two sentences. (The first is “don’t use alerts.”) The second is “use undo instead.” He argues that warnings are bad, because they are habitual. He points to the example of Gmail’s undo as an alternative.
Some posters suggest rewording alerts, but fortunately “Mike”:http://alistapart.com/comments/neveruseawarning?page=2#12 points out early on that it’s still ultimately an alert.
Well…
Gmail’s undo is ultimately an alert.
The real confusion with popup warnings are their numerous options. You get an “OK,” a “Cancel,” and occasionally an “X” in the upper right to further complicate things.
Gmail’s undo, in contrast, has only one option. The undo has no close button. It sits on the screen until you take some other action, at which point it disappears.
The author would have done us a better service to distinguish an “undo” from an “warning” rather simply defining them as unrelated things.
Everett Lindsay
Not that anyone asked, but in my opinion “Robert”:http://alistapart.com/comments/neveruseawarning?page=2#16 and “Marc”:http://alistapart.com/comments/neveruseawarning?page=3#25 and “Nathan”:http://alistapart.com/comments/neveruseawarning?page=3#28 present the best building blocks toward constructing an “undo methodology.”
Would that they were all in one place…
Justin Bell
Even though this is already explained in the article (when deleting the wrong event in Google calendar), I’ll give another example: In Photoshop, I often create, or open and modify, an image that I never want to save—usually when I want part of it for the file I’m really working on, so I often blindly click buttons even though they are quite clearly labeled with their intention, and not just “OK” or “Cancel”. Sometimes I’ll even open a previous version of a file (with a similar filename and data), then tweak something to see what it looks like, but not want to save it, while still wanting to save the latest one. So even if it was really clear about what was going to happen, a mistake is still possible. I’m sure there are many other examples of similar situations.
As for the people saying that this simply isn’t possible in many cases, I think they are overlooking the many times where this is possible, but hasn’t been done because it’s easier not to. Then there is also the argument that immediate action with an undo option is simply better than a confirmation box, from a usability angle.
Even if a proper undo is not possible, sometimes data recovery would be nice, so that people can tell what has happened, and recover any important bits of data, even if it means jumping through hoops to get it back where it should be.
Justin Bell
You’re forgetting something here (aside from something addressed at the beginning of the article): As these mistakes are from habituation, we can assume that they are generally something that is less likely to happen from a statistical point of view. Therefore, adding the trash layer isn’t just another layer to make mistakes that also need to be addressed, but a way of reducing the consequences exponentially (for lack of a better word). It’s about reducing the margin of error to a more acceptable level.
Heh….In which language? In order for more technical things to happen, people first need to be made aware and convinced of the issue. This is what this article is doing.
mtm productions
I think that one of the best functions google ever implemented was the “get my email back” function. If it was sent by gmail to gmail (ie it still resides on Google’s server) you can get it back if you hit send instead of “no, i don’t really mean to send this un-pc rant to my boss”
Wish there was a way to do that across the board.
Way to go google.
Jordan Harper
Designing the Obvious: A Commonsense Approach to Web Application Design by Robert Hoekman (an excellent book) will find this article awfully familiar. [ “Example”:http://safari.peachpit.com/0321453476/ch06lev1sec2?imagepage=168 ]
Not that there’s anything wrong with preaching good gospel, but it’s a bit cheap essentially regurgitating a partial chapter from someone’s book. In my humble opinion.
Andy Lee
I like the concise rule of thumb: “Never use a warning when you mean undo.” It’s been said before, but it definitely bears repeating.
However, I think the article uses a bad example in making its case. I can’t recall a single application I’ve used recently that asked “Are you sure you want to quit?”? The applications I use assume I do mean “Quit” when I say “Quit”; what they want to know is what to do about unsaved data, which is an entirely different question. I want to be asked for confirmation in this case, because there’s no way the computer can know the right thing to do—whether to always save the changes (and allow me to undo them later by reopening the document), or always not save the changes (and remember them when I reopen the document so I can pick up where I left off). It shouldn’t automatically save my changes, because I might not realize or remember that I changed something. It shouldn’t always not save my changes, because I might not realize they’re unsaved—so I send my boss a spreadsheet that I thought I’d updated, but I was wrong, because the application exited with unsaved documents in exactly the same way as it exits when I’ve saved all my documents.
For the above reasons, I disagree with the statement that “With a robust undo, we can close our work with reckless abandon and be secure in the knowledge that we can always get it back.” (Also, if you know your work is recoverable, you aren’t being “reckless,” but that’s semantic quibbling.)
By the way, there’s another issue that I think has been glossed over, unless I missed it in the comments, and that is the issue of multiple levels of undo. Multiple undo is extremely valuable, but adds conceptual complexity.
Chris Hester
SmartFTP asks if you really want to quit when you try to close it down.
Richard Daniel Kam
I think the undo function would be a neat inclusion in web applications. I believe that this is easier to implement than I thought.
However, if we are to have a history of things we have done in the application (multiple undo), it would seem like way harder to create. Is the multiple undo really necessary?
Lets see the 1 layer of undo that is meant for the ohnosecond mistakes be integrated into web applications first.
That would be so cool. :)
Mike Hairston
@Jordan: More likely that Aza’s article (and possibly Hoekman’s chapter) stems from The Humane Interface by Jef Raskin.
Mike Watson
One option could be to track users changes using a mechanism similar to the shopping basket concept. Changes are requested but not implemented until the user proceeds through a ‘checkout’ function to commit them. This would roll the undo and confirmation functions into one mechanism, which could be tracked client-side or server-side.
This whole concept becomes tricky very quickly when you’re working on shared data that multiple users can update though.
Andy Lee
Multiple undo might not be so necessary in web applications. Handling the ohnosecond case gracefully is already a big step, and the cases where I mostly rely on multiple undo—mainly during text editing—would be handled by my browser’s text editing support. At the very least, though, I would consider the possibility.
Even single-undo needs thinking through. Should there be a “Redo” option, or should “Undo” mean “completely forget that last thing I did”? If you provide several web apps, should they be consistent in their Undo policy, or should each one use a policy appropriate for that application?
I would like to see an article, if there is one, that analyzes the undo approach for a variety of web apps, real or fictional. I’d like to see examples of thought processes that lead to good decisions.
Radomir Dopieralski
There is one particularly nasty use case when undo just doesn’t work the way it was intended, or rather where it’s hard to come up with a working undo strategy: it’s when there are multiple people working on the same thing.
I often have the “oops moment” when using Gobby, a collaborative editor. Sometimes I will accidentally delete text that was written by different users. I immediately hit the ^Z, but in vain: Gobby doesn’t have undo, and even if it had, how would it be supposed to work? Should it be global, so that others can undo my editing, like in wiki? Or should it be local, so that only I have the power to put that accidentally deleted text back? What happens if someone already typed something in that place? What if the operation was something different than just deleting the text? Moving text around can be a tricky case, especially when someone else already modified it at its new location.
I think that dividing the document into smaller parts that can be acted upon (and reverted) independently is one possible solution (not unlike the section editing in Wikipedia), but there is a lot of room for improvement.
Andrew Gibiansky
Great point! In real life practice this has been really useful too. Blender (a 3d modeling app) saves the file you’re working on whenever you quit in a special quit.blend file, and it’s saved me many, many times. It seems that maybe implementing that idea in desktop apps might be even easier than in web apps, at least in the closing-when-you-don’t-want-to sense.
Everett Lindsay
How about English?
My “title”:http://alistapart.com/comments/neveruseawarning?page=4#40 notwithstanding, I think you may have missed some of the subtleties of my criticism, “Justin”:http://alistapart.com/comments/neveruseawarning?page=5#43 . Notice that I went on to point out several posts that “inform without getting overly technical?”
Another way to state my view is: solid concept, but it doesn’t warrant an entire article. We can agree to disagree on that.
I think Aza’s point could have been made in one or two paragraphs, as an introduction. He then could have spent the rest of the article preparing us to think in this “undo paradigm.”
“Example”:http://alistapart.com/comments/neveruseawarning/?page=3#22 : in a world of undo, your database will need an audit table. (See, that’s not overly technical. I don’t tell you which database, or what fields. Programming language never enters the conversation. It’s in English.)
Paul Rouke
Great points all round, I would just add that for significant business benefits, carrying out user testing, especially as a user is negotiating their way through a checkout process, can really add weight to all the intellectual thoughts of any in-house or external people involved in optimising the user experience of a given site with warnings and undo’s featured.
Elliott Cost
I’m a new reader of ALA and by simple reading this article I’m very inspired. I’ll be sure to check back to what’s new on the site, after I dive into the archives for awhile. Thanks for your amazing content ALA, keep it up!
Nina Ye
I really hate the warning message, “undo” is much more friendly and useful. And I will follow this suggestion in my design.
David Chong
I think the talk about ways to make email undoable is missing part of the picture. Although the protocol itself is asynchronous, the preponderance of blackberrys suggests that people are increasingly using it for business-y things that are time sensitive. Any delay mechanism is just going to tick off anyone that does time sensitive stuff over email.
D Chmieliauskas
undo concept is very good idea and it does work. i even use that idea for new CMS, it will extend usabilitty a bit more!
Russ Nelson
I’ve been whinging at the Nokia folks for exactly this reason: http://blog.russnelson.com/770/connection-manager.html
Warnings are useless. Actually, they’re worse than useless, because they take the place of something which would be useful (undo).
Bill McGonigle
I remember first being turned onto the idea of handling an ‘infinite’ undo stack in Jeff Cooper’s book About Face (1995), then I recall hearing Apple brag about Undo stacks in Cocoa in 1997 and several books since have cited the idea as the ‘right’ solution.
It’s often talked about in the same conversation about making people click ‘Save’ and even having the concepts of applications being bad examples of ‘exposing the implementation’.
So, where is it? I suspect it’s hard, expensive, and doesn’t sell well on boxes. Folks who love applications that do it probably don’t even realize it’s a reason they think ‘X is so easy to use’. I’ve asked people who use FileMaker whether they appreciate not having to save files, and none of them have noticed (aside from the occasional novice who feels really uneasy about the app if there’s no Save button).
In short, it’s the right thing for the user, but we need better metrics to justify taking care of the user (we used to have terms like ‘quality’ and ‘customer support’) to those calling the business decisions.
Bob Prokop
Undo is an ultimate solution here—but what if you could actually customize an actual alert/confirm dialog—and I don’t mean by using your own pop-element, but the actual JavaScript functions? That would go a long way towards curing the OK/Cancel issue. We could use some more flexibility in terms of what can be done with the functions—including content, formatting—at the very least customizing the text for the button elements. And please—I don’t want to hear about Microsoft’s modal windows here ;-)
Maks Komaju
Follow the link to find out the article’s Russian version:
http://makskomaju.wordpress.com/2007/09/21/oy-a-kak-vernut-nazad/
Josh Guffey
We cant forget however the original idea of a warning. This just happened to me, I went to text message someone on my phone and scrolled down one option too far, delete. I just sighed in sadness as my phone displayed “contact deleted” No warning, no “are you sure?” No undo. So lets not forget that even a warning is better than nothing at all. Thank god for bluetooth synchronization to address book!
Jeff Judge
Great article Aza, this makes a lot of sense and I do love how Google does this in Gmail. It’s helpful to know that I can always get something back. I’ll definitely be implementing this in the stuff that I build.
Arindam Das
That’s a good article AZA. The points that you have discussed are real for sure. But do you think that the same solution is going to be applicable for all types of applications, be it web based or standalone? I mean to say, is it all right for all the instances of deleting anything, from any kind of digital repository?
I understood the humane factor, the tendency of the human beings to get habituated. Google has done an excellent job on Gmail. But why didn’t they apply the same for the calender? Should we conclude that they did not give it a thought for the same? And yet, they came up with such a good solution for the mails, when they know that the same instances can occur for the calender as well.
But I must admit that, the points are applicable to some extent, and that would be very helpful for the user experience.
Louisa Nicholson
Good article, but the discussion assumes undo is the best solution without a viable discussion on the matter. There aren’t any arguments against this or for another solution altogether. Undo is OK, but how about arguments against such as privacy, development time or file space? Warnings are good. Undos are good. Neither are perfect, so just remember to choose what is best for the particular application – because in the real world, developers create apps for real users, within budgets. Develop accordingly.
longin kandinsky
we also can make habit of being cautious of what we are doing. And eg. data loss is such a great thing to doing so. And this can result only in faster development and “smarter” users and then even faster working with the program when it doesnt bother you with confirmation about everything you are going to do.
Russ Nelson
But what about the previous undo? Shouldn’t we give a warning that we’re about to overwrite the old Undo?
Russ Nelson
@Louisa: Undo is ALWAYS better than warn. Let’s take your objections one by one:
If privacy is important, then the existance of the data matters to the user. If it’s important to delete it when it’s not necessary, it’s important to keep it even in the face of user error. To make them comfortable that their deletion of sensitive data will actually occur, you say “This action is undo-able for the next ten minutes.”
Jef’s point (and his son Aza’s point) is that Warnings Do Not Work. If development time is important, then don’t waste time writing code to warn the user. Just do the action.
File space is always cheap relative to a user’s work output, and it’s becoming cheaper and cheaper by the day. Remember that when someone wrongly destroys their work, they almost always realize it within a second or two. You don’t need to keep a forever undo; being able to undo the last action is sufficient. So … you defer the actual action until the next command is entered. And if it’s “undo” then you just saved somebody’s bacon.
Louisa Nicholson
I never said undos are better than warnings, so please read the comment over again. Nor am I saying that warnings are terrific, either. I gave a comment on how the article was written definitively without any strong arguments.
I agree that actions taken should have immediate results, ie: click a button and it’s represented action occurs, like delete. That’s good HCI I think. But ours are a matter of opinions here on this case.
The code needed to write either case: A. undo action taken, make sure old data is available for x amount of time, take appropriate file space measures, create interface for undo action or selections or B. warn before doing the action forever – is actually more on the undo side – so arguing for the developers’/tech staff’s/etc sake is a bad argument.
My comment was trying to get at that even though it brought up a nice issue, “why warn at all?”, it doesn’t give any OTHER arguments altogether. How about another solution to interfaces that are prone to be confusing and how easily people delete things without realizing that they were deleting them? Why is it always the person’s fault? Why not better HCI design? Or why not VERSION control in general? Who knows, because the subject matter of the data is up in the air – and that’s key to how it should all work. The type of options would all be different when using Outlook, your computer’s file system, a content management system, Adobe Photoshop, Notepad, Calculator – which all depend on different types or file space amount, memory, hardware, interfaces, target audience, etc. This is quite like how Microsoft develops operating systems for the regular Joe (Are you sure you want to do that?) where as Linux develops operating systems for a developer (…no warning…). Some may say that’s why Linux or OSX is better than Windows, but millions of people prefer Windows over others because of small things like that, warnings which help direct them into good decision-making. There are a lot of factors to consider in any piece of software you’re developing as to what might work the best – and that isn’t ALWAYS undo.
The article ignored the thoughts of also, “well, how many undos do you give?” If space is a non-issue, and so is memory, and so is time, and so are salaries (we’re getting rid of a lot of factors here to make this possible) then you should never limit it – undo should cover every action taken from once the user starting using file/software/OS ___ . Because no amount of undo is ever good enough, once you give a user one, they expect more and that’s why programs now-a-days allow you to put in more and more undos in the history than ever before – users are dependent on not being accountable for data. That being said, I should be able to undo something I deleted 10 years ago, right? Or should I just be done with it after my 1 warning?
When is the user accountable? When are the HCI designers accountable? Can we not think of any other solutions?
Phil Dubai
Another possibility to prevent the user to click on the OK-button accidentliy might be to poste the question in the warning in the way that the user has to click the NO-button to continue. If he then clicks the OK-button although it wasn’t his intention he will just get one step back in the process. However, sometimes the question doesn’t sound good if you phrase it the other way round. But normally this is a good option.
Andreas Ringdal
@Phil Dubai, though your solution will prevent more users from performing operations they did not mean to perform, it will annoy a lot more users that clicks ok and expects their action to be comitted.
Andreas
Andreas Ringdal
A quick fix to this might be to accept the users decission and display a status message with undo option, and a 10 seconds counter.
“Message deleted, Undo (10)”
Andreas
Viktor Varland
One thing I’ve been implementing for a while is flagging content as deleted in the database.
When I feel it’s time to clean it up, I just run a delete function on the database where deleted equals 1.
It would be very easy to implement an “undo” function for users in my current applications, and hell, now I just might do so.
Great article.
Allan Ebdrup
I wrote an article about just this, more from a developer perspective.
http://obsurvey.com/Articles/WhereDidUndoGo.aspx
After I wrote my articel I found this articel, and I agree with what Aza is writing.
And It’s really not that hard to implement…
galen777
Email programmes should come standard with an undo send facility. Or a delay send. “are you absolutely sure you want to do this? sure you don’t want to wait till tomorrow when you’re sober/less angry?” Then it sends it round in a loop, which if you’re sober/not angry is easy to override, but otherwise (specially if you’re pissed) moves the send button around in a random kind of way. I just think computers should be more fun.
smhart1
Users would be less likely to need to need “undo” if the messages more appropriately matched the answer.
“OK” and “Cancel” are difficult to answer; it’s not always clear thet “Cancel” is the opposite of “OK”. Perhaps users wouldn’t make mistakes as often if they were aked “Are you sure you want to delete foobar.doc?” and the buttons are “Yes” and “No”.
I know that some environments don’t allow you to change the options; I’m constantly challenged with trying to word a message that can easily be answered with “OK” and “Cancel”—it’s very difficult.
cpmaynard
One common approach to the undo button is a soft delete, most of the time undo buttons come into play with CRUD operations, particularly the delete action – by giving a table a soft delete column (I like the name is_deleted) you can control the state of a record quite easily, by never actually removing the record the user is attempting to delete.
Wiz
Ryan bates posts a screencast demonstrating infrastructure for undo/redo-based website CUD operations in Rails at railscasts.com.