8 ms·

Never Use a Warning When you Mean Undo

121 points by jayliew 16y ago

taylorbuley 16y ago
This article spends way too much time clearing throat with an explanation of why we need to make our interfaces usable.
- metageek 16y ago
  I think I have to disagree. The habit he's pointing out is so deeply ingrained that we need to pull it to the surface and examine it for a bit before we can talk about it coherently.
  - taylorbuley 16y ago
    Agreed, but I don't think those are necessarily the kind of people in his audience -- reading Hacker News and articles on A List Apart, I feel like one can assume "make things usable" is a principle on which we can all agree.
pan69 16y ago
"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." A typical designer point of view on the world. Has the author any idea of how much time (therefore money) it can take to implement Undo features across the board? I don't think so. Successfully implementing Undo functionality can be a daunting task. The question simply comes down to; is it worth the money investing in this feature? For most applications it simply isn't, no matter what mister visual UX dude thinks or says.
- redcap 16y ago
  Implementing an undo feature is certainly harder than just providing a popup, but I think at least for me using a popup is a reflex and we should at least think about using an undo feature. I agree with the author that habitual responses to dialogue buttons can be dangerous, so I suggest considering this on a case-by-case basis - not just as to whether it's worth the money, but whether it will significantly reduce user distress.
- ubershmekel 16y ago
  It's all about software development and usage norms. Yes, it's difficult to bootstrap undo functionality. But look at mobile apps, they never ask "are you sure you want to leave?", they just make sure that whenever you come back - everything is exactly like it was before. Users EXPECT this behavior and developers feel obligated to implement it. Concerning deleting by accident - I think it's just that we have bad software usage/development norms. Who knows, maybe this will improve with time.
  - wallflower 16y ago
    > But look at mobile apps, they never ask "are you sure you want to leave?" I know your context was about something a little different but just to be nitpicky, most iOS apps we develop prompt the user if they want to leave the app and launch Google Maps to get directions and/or thank them for wanting to donate - Safari will be launching shortly and/or tell them to wait while we launch the e-commerce page.
  - jerf 16y ago
    Some things really have to be in the lowest possible level of your code to work, to come back later and bolt them on is incredibly difficult. Correctness of encoding, localization, and good unit testing are some of my usual examples; start with them from day one and they don't cost you that much, add them into a project that has gone for 10 man years without thought and you're in for some pain. Undo functionality is like that. You have to start with some sort of ability to make it easy to create your "actions" in some way where every one of them can be reversed, and in some cases the OS itself makes that very hard. How do you undo "close program"? Like you said, but didn't quite spell out, with a fundamentally different OS where suddenly it's easy. You can make a Microsoft Windows program that will automatically open in the same state you left it in, but first of all, it's much harder than it is on a phone, and second, I very much hope that you thought of that from day one because otherwise you're probably in for some pain just refactoring your program to the point where it is possible.... Ideally you would work in some language that makes undo that easy, but it's really hard because so much of the system is fighting you. I've toyed with this but UIs themselves are fundamentally not undoable so you burn a lot of time just telling the UI how to roll back. It really needs to be fundamentally woven into the entire system and that will probably be decades, if ever.
- deleted 16y ago
  [deleted]
- ugh 16y ago
  I’m not following you there, what has the difficulty of implementing undo to do with whether or not it should always be at least suggested as a clearly superior solution? I’m not seeing any assumptions about the difficulty of implementing an undo feature in that sentence (except that it’s not impossible and that some companies have been capable of implementing it). Where do you find those? I think your prejudices got the better of you.
  - damoncali 16y ago
    I can undo the shit out of Adobe Illustrator, and I still wind up losing work from time to time. How is that clearly superior to accidentally clicking "OK"?
    - ugh 16y ago
      I’m not claiming that undo will protect you from everything. (It doesn’t.) I’m merely claiming that undo is preferable (“clearly superior”) to no undo. Are you saying that Illustrator would be just as good without undo?
      - damoncali 16y ago
        That's where we disagree. Sometimes an alert is just what you need, and can be better than an undo function (which can get rather complex as your ui gets more sophistiated - hence my illustrator issues). Illustrator is clearly better with undo, but I don't think basecamp, for example, would be.
        ugh 16y ago
        I’m honestly not following you. I have trouble understanding in what way a warning could ever be better than the ability to undo. Why would it be?
        damoncali 16y ago
        There are some things that you change or delete frequently, and that have little value - the points in my illustrator file, for example. I might want to move one a bit, delete it, and then put it back. This is when you want an undo, and are willing to pay its price, both in ui complexity and implementation cost. Other things, you want to delete only occasionally, and may be of high importance, like a character in a video game. this is when you want an alert. If it's not something you do all the time, it's not habit forming ( in the context of this particular game). It adds no complexity to the ui and has nearly no implementation cost, yet it helps protect your important data.
- jayliew 16y ago
  This is a legitimate point of view, that perhaps developers don't want to hear. Disclaimer: I'm a developer, so I understand the challenge to undo. However, I also realize that I'm building for normal people (i.e. not myself). There is no need to be defensive, nobody is attacking anybody. This is just another "best practices" thing. update: just to add one more note: end-users don't care if the person who built the product like/dislike implementing an undo feature, end-users care if it's easy for them or not.
  - lukeschlather 16y ago
    The biggest problem with undo is that sometimes allowing the user to recover from a particular action is also undesirable behavior. If I accidentally typed my username and password into a file, I want it to go away, right now. There's a somewhat worrying trend with applications such as Facebook and Google Apps where software is more concerned with making users believe it's doing what they need it to do, and less concerned with doing what users need. I'm not saying this necessarily crosses the line - if I have the space on my server I'm storing lots of incremental backups. But there's always a trade-off. And some people might rather be assured that when they hit delete that it goes away forever than that they never lose anything they meant to keep.
  - pan69 16y ago
    What I was trying to get at is that this is often not a "Best Practice" decision. As if the developers didn't think of implementing undo functionality... Implementing such a complex feature such as undo if often a business decision, if anything else.
    - jasonlotito 16y ago
      Maybe it's the belief that it's a complex feature that hinders them? Implementing an undo feature isn't really complex for most things a user does. Outside of anything real time, most things have the capability of having an undo element added to them to some degree. Even then, real time actions can still be undone (credit card transactions, for example).
- rbranson 16y ago
  Agreed. It becomes especially complex in a distributed system with multiple users having access to the same data. For instance, even a simple message exchange, which has no data interdependency issues, an undo feature requires some kind of design trade-off. Either the application lies to the user and delays the sending of the message to allow for an undo period, or it allows the message to be delivered to the other user, but then allows the delivery to be un-done. However, in the later scenario, if the receiver reads the message before it is "unsent," then you aren't really providing a reliable undo facility.
- irondavycole 16y ago
  You're suggesting that "mister visual UX dudes" (like me, for example) don't take complexity of implementation into account when making design decisions. We do. It's part of the process. Note that he said to send the designer the e-mail, not the developer. The designer on a project should always know where the current UX problems in the product are, even if they are too expensive to fix at the time.
  - kelnos 16y ago
    Then I applaud you for having awareness of issues outside your immediate domain. I know quite a few UX people who know nothing about implementation and think everything is easy to do.
    - irondavycole 16y ago
      I don't even think it takes knowledge of implementation, just respect for it. I've had engineers ask me to fix certain design problems that would take weeks of prototyping and user testing to actually nail down in a meaningful way. Good devs appreciate the difficulty and we find a solution that fits the schedule, bad devs think design is easy to do. It runs both ways. Let's avoid making needless blanket statements and concentrate on working together.
- Jach 16y ago
  There's a lazy solution: do what Gmail does. Rather than have an actual undo stack, especially for those pesky things like removing information from the database, just delay action for 5-30 seconds and offer an undo button until the time expires.
  - d0mine 16y ago
    It is not a real undo it is a warning with timeout.
    - phillco 16y ago
      "LAUNCHING MISSILES (click here very quickly to undo)..."
      - d0mine 16y ago
        "cancel" and "undo" is not the same thing. You can cancel the launch. But you can't undo it. It is thermodynamically impossible.
        phillco 16y ago
        Right. But that's how Gmail is marketing it. "Undo send" gives you the impression that Gmail is reaching through the tubes and yanking your message back for you, but in reality it's just cancelling a launch that didn't happen yet.
        jpitz 16y ago
        Yes, but there's a compensating transaction you can apply to the missile up until the time it reaches the target.
    - blahedo 16y ago
      You're right that it's not a "real" undo, but it is better than a warning with timeout; on a warning, it demands that you click (habitual action) after which there's no going back, but with this system it demands nothing, the message stays up, and you click (non-habitual action) only when you want to cancel.
- zem 16y ago
  the partition magic guys didn't seem too receptive to the suggestion. bunch of stick-in-the-muds.
  - Hemlockz 16y ago
    Ha ha.... Undo repartition. At what point should users be responsible for their own clickings?
vietor 16y ago
How exactly does he propose to undo the closing of an application, as the application developer? It was his canonical example for the entire first half of the post, and then he jumped to trivially undo-able actions within an application when it came time for examples. How does he feel about the UX tradeoffs of blocking state synchronization to non-volatile storage for every user action? Better or worse then usually not losing data on an unsaved close? How about the UX of restoring state when you re-open the application? Should the user see the last state every time? The last manually saved state with an option to roll-forward? A huge obnoxious recovery dialog box like OpenOffice when you kill it without saving? These are the questions the first half of the article setup, not trivially reversible actions within an application.
- ubershmekel 16y ago
  E.g. mobile apps just save their state all the time and revert when you reopen them. Imagine if MS Word didn't ask you before it exits, but instead it asks you when you open it if you want to restore previous state.
  - barkmadley 16y ago
    MS Word does ask me all the time to restore previous state. Usually because it crashes more often than I close it.
  - vietor 16y ago
    Right, and both of those involve UX tradeoffs. Which was my point and why I gave them both as options in my initial comment. Having read the first half of the article, I was expecting the second half to address the issues which these various options raise. Sure you can "Just save state all the time", but doing so involves tradeoffs. Tradeoffs which were not addressed at all in the article. Your MS Word example is exactly what OpenOffice does when it's been closed without saving. It's really obnoxious. I was hoping to read some UX insight into how to make those kinds of actions less obnoxious without losing their helpful functionality when it's needed. In general I agree with the core idea of the article. But it lacked useful discussion about the hard UX problems involved, opting instead for some easy in-application examples.
trustfundbaby 16y ago
I don't think he's thought through the difficulty of implementing something like this in a non trivial situation ... or at least he doesn't dwell on it in a way that suggests that he has. I mean, what happens if you delete 3 things, and realize that you want to undo the 1st one? What happens if the action you take, changes the state of the user's data in a way that is unrecoverable? I like where he's going, but I'd love to see a more rigorous treatment of the idea.
- munificent 16y ago
  > I mean, what happens if you delete 3 things, and realize that you want to undo the 1st one? Just drag the first one out of the trash and leave the other two there. > What happens if the action you take, changes the state of the user's data in a way that is unrecoverable? Store the previous state.
  - shaggyfrog 16y ago
    "Store the previous state" sounds great in theory. Doesn't always work in practice. Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion. pan69 really said it all: these ideas sound great to designers, but cause nightmares for the programmer that actually has to implement it.
    - jasonlotito 16y ago
      > Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion. That sounds like an excuse. The problem isn't with the undo. It's with the rest of the system, so clearly their are other problems to address first.
      - shaggyfrog 16y ago
        To put it bluntly, this is an ignorant response. Many systems have constraints beyond the control of the developer. It isn't an excuse to say, for example, that doing save/load from a PS2 memcard is slow and non-trivial; that's just the way it is. A good designer will have a deep understanding of the capabilities and limitations of the medium they are working with. (Think Jonathan Ive and the countless testing they do using all sorts of different construction materials.) A poor designer will come up with a grand idea, but no idea how to implement it, and then blame the programmer if it's impossible to do.
acabal 16y ago
In my perfect world, all software, from nuclear reactor software to Angry Birds, would be powered by a learning neural net that dynamically reshapes the interface as it learns my most common actions and foibles. It would interface directly with my brain so that there would be no chance of my mouse slipping and clicking 'OK' when I meant 'Cancel'. Oh wait... that would be incredibly time-consuming to implement, would very likely only marginally improve the experience for the majority of users, and would be plagued by edge-case pitfalls.
weixiyen 16y ago
The fundamental problem with this article is that the author brings up a problem, but does not offer a practical real-world solution. The article only pretends to offer a solution. A List Apart is well known for helpful and practical solutions, down to detailed implementations. This does not introduce anything helpful or practical. All I got from this article was that undo is better than a confirmation modal. Thanks for stating the obvious.
rst 16y ago
"Undo" is one alternative to warning dialogs that users learn to click through mechanically. There's at least one other: if you're going to implement some irreversible action, find a way to delay it --- like in email programs or file managers where the button labeled "delete" moves things to a trash folder, and the real deletion operation is separately labeled "expunge". Implementing this sort of thing is usually easier than keeping the "real" delete operation, and then implementing a separate "undelete" which works in full generality.
- Waywocket 16y ago
  That's even worse. Users habituate themselves to the two-step process in exactly the same way, only now they're annoyed because you're forcing them to do extra unnecessary work.
GeneralMaximus 16y ago
(This post turned into a rant. Sorry about that.) The OS X shortcut for quitting an application is Cmd+Q. The shortcut for closing a window/tab is Cmd+W. Q and W are adjacent on a standard QWERTY keyboard, which means you sometimes hit Cmd+Q when you meant to hit Cmd+W. Now hitting Cmd+Q accidentally doesn't matter most of the time. Most applications will ask you if you want to save your changes before you quit. Web browsers will offer to save your session. Also, most applications save their state anyway, so you can relaunch them and continue working. So not a problem, right? There is one piece of software, though, that refuses to follow this convention. A program that has ignored every HIG and UI convention in the history of all known universes in the name of creating a "better" user experience: Google Chrome. I didn't complain when they hacked the window system to put tabs on the top of the window. I didn't complain when their shitty multi-process model brought my aging MacBook to its arthritic knees. I didn't complain when they opened PDFs in the browser without asking me first, or when they used filetype associations from my OS instead of letting me redefine them. But this just takes the cake: Google Chrome will quit without a confirmation if you accidentally hit Cmd+Q when you meant Cmd+W. In the last month I've accidentally quit the browser twice, and lost about 50 tabs every time. Surprisingly enough, there is no extension that will fix this behavior. Yes, a couple of hacks exist, but they only work half the time. I don't expect Google to fix this, though. There are gaping holes in Android that Google has simply ignored or outright refused to fix. I don't expect them to treat Chrome differently.
- aapl 16y ago
  You can remap the keyboard shortcut to something harder to accidentally hit in System Preferences > Keyboard > Keyboard Shortcuts > Applications. Then click the plus icon. I used this trick back when Safari didn't ask before quitting with multiple tabs and just confirmed it works in Chrome too.
- desigooner 16y ago
  ever tried enabling the "Confirm to Quit" setting in the about:flags page in chrome?! A little search before ranting would have certainly helped.
  - 16y ago
joh6nn 16y ago
it's surprising to me that so far, no one has pointed out that this sort of user behaviour is A Bad Thing. while Undo is definitely important and desirable, a user base that ignores attempts to communicate with them is not. i don't know if the issue is that warnings are the wrong way to communicate, or if it's that we haven't done our jobs on user education, but the fact that we have somehow trained the average Joe to just click "ok" without reading is indicative of a larger problem than irreversible actions.
- BenSS 16y ago
  Dialogs like that should be reserved for important, irreversible changes but instead are used everywhere. They're no longer read and solely seen as an interruption to the program flow. Always providing undo, or a delayed action without interrupting what the user is doing eliminates the need to retrain users.
stoney 16y ago
But when I close a program, most of the time I want it to go away and go away quickly. If the program hangs for a few seconds while it saves data that I've already told it I don't want on the off chance that I decide I really do want to restore it later, then I am likely to get annoyed with it to an extent that I'll stop using that program and never find out what a useful feature that undo functionality was.
Groxx 16y ago
If your software tries to anticipate that you might want to not-close when you told it to close, you end up with the opposite complaint: it takes too long for anything to happen. I'd be willing to bet that there would be far more complaints that your program takes a minute longer to shut down than that they told it to quit when they didn't want it to quit. I'm a huge believer in software that people can use, and love trying to make things totally foolproof for as many people as possible, but I also believe that to truly be useful on a computer you must learn some of the ground rules. Like anywhere else in life. The trick then becomes teaching your users without them realizing or fighting it, not trying to predict the inherently un-predictable (ie, the immediate whims of anyone and everyone).
smosher 16y ago
Generally, adding "undo" of some kind doesn't seem like a great idea. Too much complexity to solve a simple problem which virtually never arises in my experience. I've always found the "«save» «discard changes» «cancel»" dialog to be effective. The outer (easy) "save/cancel" choices are non-destructive. The save dialog is a file selector which can be easily canceled and "cancel" brings you right back into the program which you are free to try quitting again. And face it, when we form habits like this (which, I agree, are natural and to be accepted) we tend not to form them around the longer options. I always scan the "discard..." button semi-consciously before clicking it because the information is long, and specific to the operation (i.e. throwing everything away) so if you do manage to form a habit around "discard changes" it will apply only when that is what you want to do. (You probably won't form a habit about generally clicking the largest button regardless of the situation.) A solution I do not like is using "clever" dialog window placement or mixing up button orderings. These are just frustrating and do little to solve the problem.
csomar 16y ago
There is a technique that is used in some applications (Windows) that worked really well, at least with my mind. Most of the time, the "Yes" button is in the left. I have the habit to click on the left. Some application inverse the position. When the position is inversed, my mind stops, because something is wrong. And yes, I read the message and select the appropriate button.
agentultra 16y ago
Predicting user behavior is a fruitless time-consuming task. I get the gmail example... but the quitting example? How are you supposed to know that this time they really meant to quit and didn't just slip and click the wrong button? This is why I hate GUIs. I'm too clumsy with a mouse to trust it. How many times have I opened the wrong application from an applications menu and had to wait for it to startup only to shut it down right away? How many times did I close the application I was using by accident and have to open it again? I get a lower error rate on a keyboard using a tiled window manager. So... should I code a new feature, fix a broken one, or spend time trying to predict what mistake (or intentional action) you are going to make next? Priorities...
lhorie 16y ago
Similar to keyboard accessibility, undo is one of those things you should only consider if you don't have any less time consuming features that you should implement. The easier workaround to the "oops, I didn't mean to do that" problem is to make it harder or awkward to do it in the first place - e.g. turn reset buttons into smaller, less prominent links, don't put delete buttons right next to edit buttons, don't cram unrelated next-step actions together (e.g. "send email" and "add attachment" shouldn't be right beside each other), etc

121 points by jayliew 16y ago

taylorbuley 16y ago

This article spends way too much time clearing throat with an explanation of why we need to make our interfaces usable.

metageek 16y ago
I think I have to disagree. The habit he's pointing out is so deeply ingrained that we need to pull it to the surface and examine it for a bit before we can talk about it coherently.
- taylorbuley 16y ago
  Agreed, but I don't think those are necessarily the kind of people in his audience -- reading Hacker News and articles on A List Apart, I feel like one can assume "make things usable" is a principle on which we can all agree.

pan69 16y ago

"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." A typical designer point of view on the world. Has the author any idea of how much time (therefore money) it can take to implement Undo features across the board? I don't think so. Successfully implementing Undo functionality can be a daunting task. The question simply comes down to; is it worth the money investing in this feature? For most applications it simply isn't, no matter what mister visual UX dude thinks or says.

redcap 16y ago
Implementing an undo feature is certainly harder than just providing a popup, but I think at least for me using a popup is a reflex and we should at least think about using an undo feature. I agree with the author that habitual responses to dialogue buttons can be dangerous, so I suggest considering this on a case-by-case basis - not just as to whether it's worth the money, but whether it will significantly reduce user distress.
ubershmekel 16y ago
It's all about software development and usage norms. Yes, it's difficult to bootstrap undo functionality. But look at mobile apps, they never ask "are you sure you want to leave?", they just make sure that whenever you come back - everything is exactly like it was before. Users EXPECT this behavior and developers feel obligated to implement it. Concerning deleting by accident - I think it's just that we have bad software usage/development norms. Who knows, maybe this will improve with time.
- wallflower 16y ago
  > But look at mobile apps, they never ask "are you sure you want to leave?" I know your context was about something a little different but just to be nitpicky, most iOS apps we develop prompt the user if they want to leave the app and launch Google Maps to get directions and/or thank them for wanting to donate - Safari will be launching shortly and/or tell them to wait while we launch the e-commerce page.
- jerf 16y ago
  Some things really have to be in the lowest possible level of your code to work, to come back later and bolt them on is incredibly difficult. Correctness of encoding, localization, and good unit testing are some of my usual examples; start with them from day one and they don't cost you that much, add them into a project that has gone for 10 man years without thought and you're in for some pain. Undo functionality is like that. You have to start with some sort of ability to make it easy to create your "actions" in some way where every one of them can be reversed, and in some cases the OS itself makes that very hard. How do you undo "close program"? Like you said, but didn't quite spell out, with a fundamentally different OS where suddenly it's easy. You can make a Microsoft Windows program that will automatically open in the same state you left it in, but first of all, it's much harder than it is on a phone, and second, I very much hope that you thought of that from day one because otherwise you're probably in for some pain just refactoring your program to the point where it is possible.... Ideally you would work in some language that makes undo that easy, but it's really hard because so much of the system is fighting you. I've toyed with this but UIs themselves are fundamentally not undoable so you burn a lot of time just telling the UI how to roll back. It really needs to be fundamentally woven into the entire system and that will probably be decades, if ever.
deleted 16y ago
[deleted]
ugh 16y ago
I’m not following you there, what has the difficulty of implementing undo to do with whether or not it should always be at least suggested as a clearly superior solution? I’m not seeing any assumptions about the difficulty of implementing an undo feature in that sentence (except that it’s not impossible and that some companies have been capable of implementing it). Where do you find those? I think your prejudices got the better of you.
- damoncali 16y ago
  I can undo the shit out of Adobe Illustrator, and I still wind up losing work from time to time. How is that clearly superior to accidentally clicking "OK"?
  - ugh 16y ago
    I’m not claiming that undo will protect you from everything. (It doesn’t.) I’m merely claiming that undo is preferable (“clearly superior”) to no undo. Are you saying that Illustrator would be just as good without undo?
    - damoncali 16y ago
      That's where we disagree. Sometimes an alert is just what you need, and can be better than an undo function (which can get rather complex as your ui gets more sophistiated - hence my illustrator issues). Illustrator is clearly better with undo, but I don't think basecamp, for example, would be.
      - ugh 16y ago
        I’m honestly not following you. I have trouble understanding in what way a warning could ever be better than the ability to undo. Why would it be?
        damoncali 16y ago
        There are some things that you change or delete frequently, and that have little value - the points in my illustrator file, for example. I might want to move one a bit, delete it, and then put it back. This is when you want an undo, and are willing to pay its price, both in ui complexity and implementation cost. Other things, you want to delete only occasionally, and may be of high importance, like a character in a video game. this is when you want an alert. If it's not something you do all the time, it's not habit forming ( in the context of this particular game). It adds no complexity to the ui and has nearly no implementation cost, yet it helps protect your important data.
jayliew 16y ago
This is a legitimate point of view, that perhaps developers don't want to hear. Disclaimer: I'm a developer, so I understand the challenge to undo. However, I also realize that I'm building for normal people (i.e. not myself). There is no need to be defensive, nobody is attacking anybody. This is just another "best practices" thing. update: just to add one more note: end-users don't care if the person who built the product like/dislike implementing an undo feature, end-users care if it's easy for them or not.
- lukeschlather 16y ago
  The biggest problem with undo is that sometimes allowing the user to recover from a particular action is also undesirable behavior. If I accidentally typed my username and password into a file, I want it to go away, right now. There's a somewhat worrying trend with applications such as Facebook and Google Apps where software is more concerned with making users believe it's doing what they need it to do, and less concerned with doing what users need. I'm not saying this necessarily crosses the line - if I have the space on my server I'm storing lots of incremental backups. But there's always a trade-off. And some people might rather be assured that when they hit delete that it goes away forever than that they never lose anything they meant to keep.
- pan69 16y ago
  What I was trying to get at is that this is often not a "Best Practice" decision. As if the developers didn't think of implementing undo functionality... Implementing such a complex feature such as undo if often a business decision, if anything else.
  - jasonlotito 16y ago
    Maybe it's the belief that it's a complex feature that hinders them? Implementing an undo feature isn't really complex for most things a user does. Outside of anything real time, most things have the capability of having an undo element added to them to some degree. Even then, real time actions can still be undone (credit card transactions, for example).
rbranson 16y ago
Agreed. It becomes especially complex in a distributed system with multiple users having access to the same data. For instance, even a simple message exchange, which has no data interdependency issues, an undo feature requires some kind of design trade-off. Either the application lies to the user and delays the sending of the message to allow for an undo period, or it allows the message to be delivered to the other user, but then allows the delivery to be un-done. However, in the later scenario, if the receiver reads the message before it is "unsent," then you aren't really providing a reliable undo facility.
irondavycole 16y ago
You're suggesting that "mister visual UX dudes" (like me, for example) don't take complexity of implementation into account when making design decisions. We do. It's part of the process. Note that he said to send the designer the e-mail, not the developer. The designer on a project should always know where the current UX problems in the product are, even if they are too expensive to fix at the time.
- kelnos 16y ago
  Then I applaud you for having awareness of issues outside your immediate domain. I know quite a few UX people who know nothing about implementation and think everything is easy to do.
  - irondavycole 16y ago
    I don't even think it takes knowledge of implementation, just respect for it. I've had engineers ask me to fix certain design problems that would take weeks of prototyping and user testing to actually nail down in a meaningful way. Good devs appreciate the difficulty and we find a solution that fits the schedule, bad devs think design is easy to do. It runs both ways. Let's avoid making needless blanket statements and concentrate on working together.
Jach 16y ago
There's a lazy solution: do what Gmail does. Rather than have an actual undo stack, especially for those pesky things like removing information from the database, just delay action for 5-30 seconds and offer an undo button until the time expires.
- d0mine 16y ago
  It is not a real undo it is a warning with timeout.
  - phillco 16y ago
    "LAUNCHING MISSILES (click here very quickly to undo)..."
    - d0mine 16y ago
      "cancel" and "undo" is not the same thing. You can cancel the launch. But you can't undo it. It is thermodynamically impossible.
      - phillco 16y ago
        Right. But that's how Gmail is marketing it. "Undo send" gives you the impression that Gmail is reaching through the tubes and yanking your message back for you, but in reality it's just cancelling a launch that didn't happen yet.
      - jpitz 16y ago
        Yes, but there's a compensating transaction you can apply to the missile up until the time it reaches the target.
  - blahedo 16y ago
    You're right that it's not a "real" undo, but it is better than a warning with timeout; on a warning, it demands that you click (habitual action) after which there's no going back, but with this system it demands nothing, the message stays up, and you click (non-habitual action) only when you want to cancel.
zem 16y ago
the partition magic guys didn't seem too receptive to the suggestion. bunch of stick-in-the-muds.
- Hemlockz 16y ago
  Ha ha.... Undo repartition. At what point should users be responsible for their own clickings?

vietor 16y ago

How exactly does he propose to undo the closing of an application, as the application developer? It was his canonical example for the entire first half of the post, and then he jumped to trivially undo-able actions within an application when it came time for examples. How does he feel about the UX tradeoffs of blocking state synchronization to non-volatile storage for every user action? Better or worse then usually not losing data on an unsaved close? How about the UX of restoring state when you re-open the application? Should the user see the last state every time? The last manually saved state with an option to roll-forward? A huge obnoxious recovery dialog box like OpenOffice when you kill it without saving? These are the questions the first half of the article setup, not trivially reversible actions within an application.

ubershmekel 16y ago
E.g. mobile apps just save their state all the time and revert when you reopen them. Imagine if MS Word didn't ask you before it exits, but instead it asks you when you open it if you want to restore previous state.
- barkmadley 16y ago
  MS Word does ask me all the time to restore previous state. Usually because it crashes more often than I close it.
- vietor 16y ago
  Right, and both of those involve UX tradeoffs. Which was my point and why I gave them both as options in my initial comment. Having read the first half of the article, I was expecting the second half to address the issues which these various options raise. Sure you can "Just save state all the time", but doing so involves tradeoffs. Tradeoffs which were not addressed at all in the article. Your MS Word example is exactly what OpenOffice does when it's been closed without saving. It's really obnoxious. I was hoping to read some UX insight into how to make those kinds of actions less obnoxious without losing their helpful functionality when it's needed. In general I agree with the core idea of the article. But it lacked useful discussion about the hard UX problems involved, opting instead for some easy in-application examples.

trustfundbaby 16y ago

I don't think he's thought through the difficulty of implementing something like this in a non trivial situation ... or at least he doesn't dwell on it in a way that suggests that he has. I mean, what happens if you delete 3 things, and realize that you want to undo the 1st one? What happens if the action you take, changes the state of the user's data in a way that is unrecoverable? I like where he's going, but I'd love to see a more rigorous treatment of the idea.

munificent 16y ago
> I mean, what happens if you delete 3 things, and realize that you want to undo the 1st one? Just drag the first one out of the trash and leave the other two there. > What happens if the action you take, changes the state of the user's data in a way that is unrecoverable? Store the previous state.
- shaggyfrog 16y ago
  "Store the previous state" sounds great in theory. Doesn't always work in practice. Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion. pan69 really said it all: these ideas sound great to designers, but cause nightmares for the programmer that actually has to implement it.
  - jasonlotito 16y ago
    > Storing the state of the system may involve a non-trivial amount of both storage and/or time. Or the backing store may not allow for reversing a deletion. That sounds like an excuse. The problem isn't with the undo. It's with the rest of the system, so clearly their are other problems to address first.
    - shaggyfrog 16y ago
      To put it bluntly, this is an ignorant response. Many systems have constraints beyond the control of the developer. It isn't an excuse to say, for example, that doing save/load from a PS2 memcard is slow and non-trivial; that's just the way it is. A good designer will have a deep understanding of the capabilities and limitations of the medium they are working with. (Think Jonathan Ive and the countless testing they do using all sorts of different construction materials.) A poor designer will come up with a grand idea, but no idea how to implement it, and then blame the programmer if it's impossible to do.

acabal 16y ago

In my perfect world, all software, from nuclear reactor software to Angry Birds, would be powered by a learning neural net that dynamically reshapes the interface as it learns my most common actions and foibles. It would interface directly with my brain so that there would be no chance of my mouse slipping and clicking 'OK' when I meant 'Cancel'. Oh wait... that would be incredibly time-consuming to implement, would very likely only marginally improve the experience for the majority of users, and would be plagued by edge-case pitfalls.

weixiyen 16y ago

The fundamental problem with this article is that the author brings up a problem, but does not offer a practical real-world solution. The article only pretends to offer a solution. A List Apart is well known for helpful and practical solutions, down to detailed implementations. This does not introduce anything helpful or practical. All I got from this article was that undo is better than a confirmation modal. Thanks for stating the obvious.

rst 16y ago

"Undo" is one alternative to warning dialogs that users learn to click through mechanically. There's at least one other: if you're going to implement some irreversible action, find a way to delay it --- like in email programs or file managers where the button labeled "delete" moves things to a trash folder, and the real deletion operation is separately labeled "expunge". Implementing this sort of thing is usually easier than keeping the "real" delete operation, and then implementing a separate "undelete" which works in full generality.

Waywocket 16y ago
That's even worse. Users habituate themselves to the two-step process in exactly the same way, only now they're annoyed because you're forcing them to do extra unnecessary work.

GeneralMaximus 16y ago

(This post turned into a rant. Sorry about that.) The OS X shortcut for quitting an application is Cmd+Q. The shortcut for closing a window/tab is Cmd+W. Q and W are adjacent on a standard QWERTY keyboard, which means you sometimes hit Cmd+Q when you meant to hit Cmd+W. Now hitting Cmd+Q accidentally doesn't matter most of the time. Most applications will ask you if you want to save your changes before you quit. Web browsers will offer to save your session. Also, most applications save their state anyway, so you can relaunch them and continue working. So not a problem, right? There is one piece of software, though, that refuses to follow this convention. A program that has ignored every HIG and UI convention in the history of all known universes in the name of creating a "better" user experience: Google Chrome. I didn't complain when they hacked the window system to put tabs on the top of the window. I didn't complain when their shitty multi-process model brought my aging MacBook to its arthritic knees. I didn't complain when they opened PDFs in the browser without asking me first, or when they used filetype associations from my OS instead of letting me redefine them. But this just takes the cake: Google Chrome will quit without a confirmation if you accidentally hit Cmd+Q when you meant Cmd+W. In the last month I've accidentally quit the browser twice, and lost about 50 tabs every time. Surprisingly enough, there is no extension that will fix this behavior. Yes, a couple of hacks exist, but they only work half the time. I don't expect Google to fix this, though. There are gaping holes in Android that Google has simply ignored or outright refused to fix. I don't expect them to treat Chrome differently.

aapl 16y ago
You can remap the keyboard shortcut to something harder to accidentally hit in System Preferences > Keyboard > Keyboard Shortcuts > Applications. Then click the plus icon. I used this trick back when Safari didn't ask before quitting with multiple tabs and just confirmed it works in Chrome too.
desigooner 16y ago
ever tried enabling the "Confirm to Quit" setting in the about:flags page in chrome?! A little search before ranting would have certainly helped.
- 16y ago

joh6nn 16y ago

it's surprising to me that so far, no one has pointed out that this sort of user behaviour is A Bad Thing. while Undo is definitely important and desirable, a user base that ignores attempts to communicate with them is not. i don't know if the issue is that warnings are the wrong way to communicate, or if it's that we haven't done our jobs on user education, but the fact that we have somehow trained the average Joe to just click "ok" without reading is indicative of a larger problem than irreversible actions.

BenSS 16y ago
Dialogs like that should be reserved for important, irreversible changes but instead are used everywhere. They're no longer read and solely seen as an interruption to the program flow. Always providing undo, or a delayed action without interrupting what the user is doing eliminates the need to retrain users.

stoney 16y ago

But when I close a program, most of the time I want it to go away and go away quickly. If the program hangs for a few seconds while it saves data that I've already told it I don't want on the off chance that I decide I really do want to restore it later, then I am likely to get annoyed with it to an extent that I'll stop using that program and never find out what a useful feature that undo functionality was.

Groxx 16y ago

If your software tries to anticipate that you might want to not-close when you told it to close, you end up with the opposite complaint: it takes too long for anything to happen. I'd be willing to bet that there would be far more complaints that your program takes a minute longer to shut down than that they told it to quit when they didn't want it to quit. I'm a huge believer in software that people can use, and love trying to make things totally foolproof for as many people as possible, but I also believe that to truly be useful on a computer you must learn some of the ground rules. Like anywhere else in life. The trick then becomes teaching your users without them realizing or fighting it, not trying to predict the inherently un-predictable (ie, the immediate whims of anyone and everyone).

smosher 16y ago

Generally, adding "undo" of some kind doesn't seem like a great idea. Too much complexity to solve a simple problem which virtually never arises in my experience. I've always found the "«save» «discard changes» «cancel»" dialog to be effective. The outer (easy) "save/cancel" choices are non-destructive. The save dialog is a file selector which can be easily canceled and "cancel" brings you right back into the program which you are free to try quitting again. And face it, when we form habits like this (which, I agree, are natural and to be accepted) we tend not to form them around the longer options. I always scan the "discard..." button semi-consciously before clicking it because the information is long, and specific to the operation (i.e. throwing everything away) so if you do manage to form a habit around "discard changes" it will apply only when that is what you want to do. (You probably won't form a habit about generally clicking the largest button regardless of the situation.) A solution I do not like is using "clever" dialog window placement or mixing up button orderings. These are just frustrating and do little to solve the problem.

csomar 16y ago

There is a technique that is used in some applications (Windows) that worked really well, at least with my mind. Most of the time, the "Yes" button is in the left. I have the habit to click on the left. Some application inverse the position. When the position is inversed, my mind stops, because something is wrong. And yes, I read the message and select the appropriate button.

agentultra 16y ago

Predicting user behavior is a fruitless time-consuming task. I get the gmail example... but the quitting example? How are you supposed to know that this time they really meant to quit and didn't just slip and click the wrong button? This is why I hate GUIs. I'm too clumsy with a mouse to trust it. How many times have I opened the wrong application from an applications menu and had to wait for it to startup only to shut it down right away? How many times did I close the application I was using by accident and have to open it again? I get a lower error rate on a keyboard using a tiled window manager. So... should I code a new feature, fix a broken one, or spend time trying to predict what mistake (or intentional action) you are going to make next? Priorities...

lhorie 16y ago

Similar to keyboard accessibility, undo is one of those things you should only consider if you don't have any less time consuming features that you should implement. The easier workaround to the "oops, I didn't mean to do that" problem is to make it harder or awkward to do it in the first place - e.g. turn reset buttons into smaller, less prominent links, don't put delete buttons right next to edit buttons, don't cram unrelated next-step actions together (e.g. "send email" and "add attachment" shouldn't be right beside each other), etc