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 ArticleRuss 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.