Have you ever had that sinking feeling when you realize—just a split second too late—that you shouldn’t have clicked “Okay” in the “Are you sure you want to quit?” dialog?
Yes? Well, you’re in good company—everybody has had a similar experience, so there’s no need to feel ashamed about it. It’s not your fault: it’s your software’s fault.
Why? Because software should “know” that we form habits. Software should know that after clicking “Okay” countless times in response to the question, we’ll probably click “Okay” this time too, even if we don’t mean to. Software should know that we won’t have a chance to think before accidentally throwing our work away.
Why should it know these things? Because software designers should know that we form habits, whether we want to or not.
Habit formation is actually good thing: it saves us the trouble of having to think when confronted with interface banalities and it lessens the probability that our train of thought will get derailed. In the case of the “Are you sure you want to quit?” dialog, our hands have memorized close-and-click as a single continuous gesture. That’s good, because most of the time we don’t want to think about the question—we just do the right thing. Unfortunately, our habits sometimes make us do the wrong thing: we don’t even have time to realize our mistake until after we’ve made it.
So, as designers we are led to a general interface principle: If an interface is to be humane, it must respect habituation.
Possible solutions#section2
What about making the warning harder to ignore? A subtle warning will get passed by, so let’s pull out all the stops: we’ll blink the screen and play a loud stretching noise to ensure that the user is paying attention. Try as we might, it still won’t work. The more in-your-face the warning is, the faster we’ll want to get away from it (by clicking “Okay”) and the more mistakes we’ll make. The thing is, no matter how fully in-your-face the computer presents the warning, we’ll still make the same mistake—clicking “Okay” when we don’t mean to. But it’s still not our fault: as long as it’s possible to habituate to dismissing the message, we’ll habituate, and then we’ll make mistakes.
What about making the warning impossible to ignore? If it’s habituation on the human side that is causing the problem, why not design the interface such that we cannot form a habit. That way we’ll always be forced to stop and think before answering the question, so we’ll always choose the answer we mean. That’ll solve the problem, right?
This type of thinking is not new: It’s the type-the-nth-word-of-this-sentence-to-continue approach. In the game Guild Wars, for example, deleting a character requires first clicking a “delete” button and then typing the name of the character as confirmation. Unfortunately, it doesn’t always work. In particular:
- It causes us to concentrate on the unhabitual-task at hand and not on whether we want to be throwing away our work. Thus, the impossible-to-ignore warning is little better than a normal warning: We end up losing our work either way. This (losing our work) is the worst software sin possible.
- It is remarkably annoying, and because it always requires our attention, it necessarily distracts us from our work (which is the second worst software sin).
- It is always slower and more work-intensive than a standard warning. Thus, it commits the third worst sin—requiring more work from us than is necessary.
In the Guild Wars example, points two and three aren’t particularly apropos because deleting a character is an infrequent action. However, if we had to type the name of a document before being allowed to exit it without saving, we would find it very burdensome.
What have we learned? That interfaces that don’t respect habituation are very bad. Making the warning bigger, louder, and impossible-to-ignore doesn’t seem to work; any way we look at it, warnings lead us into a big black interface pit. So let’s get rid of the warning altogether.
Undo to the rescue#section3
Merely removing warnings doesn’t save our work from peril, but using an “undo” function does. Let me say that again: The solution to our warning woes is undo. 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. With undo, we can make that horrible “oops!” feeling go away by getting our work back.1
Because we form habits, we’ll never be able to guarantee that we won’t have an “oops!” moment. Instead, designers must accept that it will happen and design for it. Whenever we have the opportunity to throw away work, the computer must allow us to undo our actions.
This leads to one of the most basic and important mantras of interface design: Never use a warning when you mean undo.
Google Mail is a outstanding example of this mantra. When you delete an e-mail, it immediately gives you an option to undo that action. How humane! This neatly sidesteps the issue of warnings (as well as the visibility issue of undo). When we make a mistake (which we are bound to do) it isn’t very costly because we can just undo it. With undo, we spend less time worrying and more time doing work.
Of course this is only one layer of undo—and Gmail goes even further. After you delete a message, it isn’t gone forever… it sits in the trash so that you can retrieve it if you decide later that you didn’t actually want to delete it.
Alas, this is a lesson that Google Calendar hasn’t learned yet. And, as predicted, I’ve deleted events that I didn’t mean to. Sometimes I’ve deleted the wrong event, which is particularly bad because then I’m not even sure what I’ve deleted. Without undo, there is no way to find out.
Actually, even Google Mail hasn’t fully embraced the lesson. When you remove a label from Gmail, up comes one of those wretched warnings. Why is it that Google can get it so right in one place, and mere clicks away get it so wrong? Perhaps because “warn-think” is so ingrained that it takes a heroic effort to break free. Even companies which are generally bastions of good design, like 37Signals, get this one dead wrong.
Using a warning instead of an undo is the path of least resistance from a programmer’s standpoint, and it doesn’t require any new thinking from a design standpoint. But that isn’t an excuse for our computers to be inhumane.
Conclusion#section4
Warnings cause us to lose our work, to mistrust our computers, and to blame ourselves. A simple but foolproof design methodology solves the problem: “Never use a warning when you mean undo.” And when a user is deleting their work, you always mean undo.
Oh, and the next time you see a warning used instead of undo, send the designer of the application/website a nice e-mail suggesting that they implement an “undo” feature instead. Send them a link to this article. Let’s see if we can’t change the way people design on the web—and in the process make everyone’s computing life more humane and less frustrating in one little way. Let the war on warnings begin!
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.
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.
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!
I really hate the warning message, “undo” is much more friendly and useful. And I will follow this suggestion in my design.
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.
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!
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).
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.
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 😉
Follow the link to find out the article’s Russian version:
http://makskomaju.wordpress.com/2007/09/21/oy-a-kak-vernut-nazad/
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.
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.
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.
But what about the previous undo? Shouldn’t we give a warning that we’re about to overwrite the old Undo?
@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.
@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
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
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.
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.
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.
Ryan bates posts a screencast demonstrating infrastructure for undo/redo-based website CUD operations in Rails at railscasts.com.