"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.
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.
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
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.
I just checked that. They only let you undo when you delete messages from Inbox, which is trivial because those messages are not deleted but moved to Trash.
When I clicked on "Empty Trash now" all I got was this message: "All messages in the Trash have been deleted forever."
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.
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.
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.
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?
It wasn't simply suggested as a superior solution. The article states that you should "never" use a popup and instead have an undo mechanism. That's a bit absolutist.
It's not hyperbole when it's repeated over and over, and the entire point of the article is to tell everyone that warning dialogs are bad and universal undo is the answer. Did you even read it?
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"?
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?
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.
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.
If you go back to the video game example, you have a list of saved games/characters and you can choose to delete a character. Pretty standard stuff.
Now you add an undo button and you've gone from two actions to three actions. Furthermore, does the undo apply just to when you delete characters, or can you undo the progress you just made with a character? If it's the former, then your undo is inconsistent. If it's the latter, if you accidentally undo, then you want a 'redo' so you can't lose your new changes either. So now you've doubled the number of options the user can take. And how often are you going to delete a character anyway?
Or, you can take the approach games do, which is simply ask you 'are you sure you want to delete this character?' Given this response is distinct from the 'continue game' action, which would display a loading screen, players are likely to notice the prompt. Why complicate things?
Undoing a character delete is fairly trivial. The reason their is a prompt in most games is that their is no universally excepted way to undo something in games. It's become accepted to have a confirmation box.
As for consistency in a game, menus and the games UI rarely share the same structure. It's also generally except that you don't put up a confirmation box for the player to level up.
> The reason their is a prompt in most games is that their is no universally excepted way to undo something in games. It's become accepted to have a confirmation box.
Honestly, how many actions in a game does it make sense to undo, unless you're playing Prince of Persia: Sands of Time? I'm a big proponent of 'make everything undoable' but you are stretching it way beyond its use here.
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.
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.
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.
"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.
> 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.
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.
I said in another comment that certain cases (like games) are the exception of the rule. But in context with the article, what I say stands. Implementing undo for users is fairly trivial. If it's not, their are other problems that need addressing.
I'm coming off that way, and I apologise. I wasn't clear. I believe the original article was mostly discussing these factors within the confines of web based applications, which is what my comments here have assumed. Obviously their are exceptions to the rule, and a true undo is not trivial. However, a true undo, and an undo that meets the users needs are different things entirely. While it's unfair for me to suggest that implementing undo is trivial, it's also unfair to assume that implementing undo has to be difficult.
I think we have common ground, here. If it's reasonable to put in undo (pragmatically speaking, in terms of money, time, technology, etc.) then I agree the user is better off having it than not.
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.
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.
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.
> 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.
An initial ideas I had, fairly trivial in the context of OpenOffice and Word asking to return to your previous state:
If a short period of time has elapsed since closing the application, simply resume state. Short period of time would have to be determine, of course. But it's fair to say that if I close an application and open it again within a minute, I probably want to resume the state. Additional conditions could be added based on testing: didn't save in the last close might be a good indicator.
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.
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.
I'm relatively new to Chrome, and it's still not my default browser, so I hadn't heard of this "about:flags" page before.
I just checked that page out, however, and didn't see this "Confirm to Quit" setting. For someone who has a cat that constantly runs across his laptop, Firefox's warnings have been very handy, and greatly missed in Chrome.
You mean "a little search" to find a tool that's only available in the +1 version of Chrome? I don't think you should have to trade off stability for the ability to get a warning (or save state) before you nuke your browser.
I accidentally closed a tab in chrome one day and all my text I've entered in a form was lost - so I thought. But chrome offered me to restore the tab - including the text in the form! I was very surprised and happy with this behavior. Now I am less afraid to use keyboard shortcuts, because I know that chrome will handle this allright (doesn't work always, I know).
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.
Different target, same problem (but without the undo function that Chrome has):
Windows System Menu. Alt-Space.
Very useful for those of us who use our keyboard shortcuts in preference to pointing devices where possible, but with a bone-headed bit of shortcut choice.
Alt-Space-X maximises a window.
Alt-Space-C closes a window.
The Windows convention is for apps without unsaved changes to quit without confirmation (another silliness IMHO) so a slight finger-slip when trying to maximise a window can close your window and potentially your whole app without confirmation. Very frustrating.
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.
"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.
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.
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.
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.
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).
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?
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
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.
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.
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.
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.
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.