The common technique of confirmation, popping a dialog box into the user's face and asking, "Are you really Really REALLY sure you want to do that?" is evil. It's unfriendly, it's distracting, and it's completely ineffective. Have you ever, even once, said, "Whoa! I didn't want to do that. Thanks," and clicked No? Have you seen anyone do that? Have you even heard of anyone doing it? I haven't. It shouldn't exist. Anywhere. Ever.
Confirmation is so vastly overused that it has become completely useless. Because the box constantly cries "wolf!" like the shepherd boy in Aesop's fable, no one pays attention to it, even when it's warning you of something you really don't want to do. You cruise through it on auto-pilot, clicking Yes without thinking, an action the cognitive scientists call "chaining".
We might just tolerate the annoyance of confirmation if it actually made us safe, but research has shown again and again that it does not. On the contrary, mistakenly believing that a confirmation box will prevent users from making mistakes gives programmers a false sense of security. It keeps programmers from having to clearly explain to the user what he's doing, and providing a way to recover when he does something that he later regrets, despite having originally confirmed it.
No human being is ever 100% certain about anything; just ask anyone who's married. An application with undo capability recognizes and honors a user's humanity. One that lacks Undo is insisting that a user become something other than human to use that application successfully. Which would you rather buy?
Other operations in life don't require confirmation. Your car does not ask, "Do you really want to start the engine?" when you turn the key. The supermarket clerk does not ask, "Do you really want to buy these?" when you place groceries on the register belt. Programmers constantly ask for confirmation because they think users don't understand the consequences of their commands. That may be true, given the poor quality of the user interface. But confirmation doesn't solve this problem. If the user was confused when he first gave whatever command triggered the confirmation box, he'll be even more confused when he sees it.
But what if the user really has made a mistake? If you put a flashlight on the register belt with a package of the wrong size batteries, wouldn't an attentive clerk ask, "Are you sure you want this size and not the one that fits the flashlight you're buying?" A good user interface should and can save us from mistakes like that, but it won't happen by blindly and stupidly asking, "Are you sure?". Instead, a good user interface prevents the problem initially by Just Working. Perhaps the Web page selling flashlights would contain a check box saying "include batteries," checked by default. Better still, the flashlight would come with batteries already inside it, so it'd work the instant you unwrapped it and no one would ever have to worry about buying the correct size. Now that's a design that Just Works.
Another reason that you aren't asked to confirm starting your car or buying groceries is that these operations are easy to undo. You just turn off the key or return the unwanted item. Programmers often put "undo" capability in their programs, where it's the greatest design advance since the mouse. It takes an enormous amount of effort to make this feature work so that users don't even have to think about it ("easy is hard, the saying goes"), but the programmers who implement it are any user's best friends. I buy them beer whenever I meet them.
The worst confirmations are those of undoable actions, such as moving a file to the Recycle Bin, shown below:
Confirmation is so vastly overused that it has become completely useless. Because the box constantly cries "wolf!" like the shepherd boy in Aesop's fable, no one pays attention to it, even when it's warning you of something you really don't want to do. You cruise through it on auto-pilot, clicking Yes without thinking, an action the cognitive scientists call "chaining".
We might just tolerate the annoyance of confirmation if it actually made us safe, but research has shown again and again that it does not. On the contrary, mistakenly believing that a confirmation box will prevent users from making mistakes gives programmers a false sense of security. It keeps programmers from having to clearly explain to the user what he's doing, and providing a way to recover when he does something that he later regrets, despite having originally confirmed it.
No human being is ever 100% certain about anything; just ask anyone who's married. An application with undo capability recognizes and honors a user's humanity. One that lacks Undo is insisting that a user become something other than human to use that application successfully. Which would you rather buy?
Other operations in life don't require confirmation. Your car does not ask, "Do you really want to start the engine?" when you turn the key. The supermarket clerk does not ask, "Do you really want to buy these?" when you place groceries on the register belt. Programmers constantly ask for confirmation because they think users don't understand the consequences of their commands. That may be true, given the poor quality of the user interface. But confirmation doesn't solve this problem. If the user was confused when he first gave whatever command triggered the confirmation box, he'll be even more confused when he sees it.
But what if the user really has made a mistake? If you put a flashlight on the register belt with a package of the wrong size batteries, wouldn't an attentive clerk ask, "Are you sure you want this size and not the one that fits the flashlight you're buying?" A good user interface should and can save us from mistakes like that, but it won't happen by blindly and stupidly asking, "Are you sure?". Instead, a good user interface prevents the problem initially by Just Working. Perhaps the Web page selling flashlights would contain a check box saying "include batteries," checked by default. Better still, the flashlight would come with batteries already inside it, so it'd work the instant you unwrapped it and no one would ever have to worry about buying the correct size. Now that's a design that Just Works.
Another reason that you aren't asked to confirm starting your car or buying groceries is that these operations are easy to undo. You just turn off the key or return the unwanted item. Programmers often put "undo" capability in their programs, where it's the greatest design advance since the mouse. It takes an enormous amount of effort to make this feature work so that users don't even have to think about it ("easy is hard, the saying goes"), but the programmers who implement it are any user's best friends. I buy them beer whenever I meet them.
The worst confirmations are those of undoable actions, such as moving a file to the Recycle Bin, shown below:
It's much more efficient to fix the relatively small number of errors that actually do occur (for example, a slip of the mouse deleting the wrong file) than attempt to prevent them by annoying the user with a confirmation box every time (which are usually ignored out of habit). An ounce of cure is not worth five pounds of prevention, especially when what the programmer THINKS is prevention does not prevent anything.
The beauty of undo is that it allows users to explore a program. It's not always easy to understand a new program's operation from menu items and toolbar pictures. With undo, a user can try different commands, knowing that he won't damage something that can't be repaired with a few keystrokes. Programmers often regard incorrect user input as the act of an idiot who should have read the %*$#% instruction manual. It isn't. It is the primary mechanism by which the human species learns.
If undo is implemented correctly, then there's only one destructive operation in the entire system: emptying the Recycle Bin. Some would say that this operation should have a confirmation box, as it currently does. But even here, the confirmation dialog exists only to guard against another bad design, placing the "Explore" context menu item next to "Empty Recycle Bin." One slip of the mouse, sliding down three spaces instead of two, and you get the latter instead of the former. That's bad. Emptying the Recycle Bin should have a special action used for no other purpose, perhaps clicking on it while holding down some key. Better still, the Recycle Bin should automatically delete files after some configurable period of time so you'd seldom have to empty it manually. Don't you wish that your real trash cans Just Worked like that?
A good application should never ask permission. Programmers should provide undo capability, and not ask for confirmation. That's the way to write an applicatin that Just Works
I agree with you that the delete confirmation is a waste of time when undo is available. However, there are situations when moving files to the recycle bin doesn't recycle it, it deletes it. Isn't confirmation appropriate at that point?
ReplyDeleteNo, because it doesn't work. Users cruise through it on autopilot. Undo should never be unavailable. The lack of it forces humans to be something other than human.
ReplyDeleteYou can turn that off if you don't like it:
ReplyDelete1. Right-click on Recycle Bin and choose Properties.
2. Uncheck the box next to "Display delete confirmation dialog.
Easy done. Now it won't bug you.
As for undo not being unavailable, that's a function of disk space. It's kind of a catch-22. The size of the Recycle Bin is limited to a percentage of the drive size, so if a file that you are deleting is larger than the size of the Recycle Bin, it's deleted. It keeps the Recycle Bin from taking up more space on the drive than it is allocated.
To that point, it's worth noting that files will automatically be deleted from the Recycle Bin to make space to accommodate more recent deletions.
Personally, I like this. I don't want the Recycle Bin to take up more space than I have told it to do. In this case, I don't mind that undo is not available. To each his own, I suppose.
Other than this specific case, I do agree with your position in principle. Keep 'em coming.
Logically undo is intractable when modifying a shared resource as someone (or something) else may modify it after you (e.g. a database or network file). Even a local file can fall under this category if another program (user controlled or not) is running that can modify the file.
ReplyDeleteOtherwise, undo is usually not implemented because it is harder to implement than a confirm box...
Ok, Firstly you have some good points, there is some bad software design (and yes, I am a software designer), and I hope to include some of your Just Works mentality in future stuff that I do.
ReplyDeleteHowever some of these tasks are harder than they first appear. You often end up with 'do what i want, not what I said'.
For example, say you are wondering around in explorer, and delete a vital file to your favorite program by mistake. However you didn't notice (because it Just Worked) Later, you come to run your favourite program and it Just Doesn't Work, and gives you some strange message about files missing. Do you think 'hrm 2 days ago I was in explorer, and might have deleted something by mistake' or do you go looking for a hammer?
Basically you can only go looking to undo something if you know that you did it in the first place.
So, how far do we take an undo? Undo a saved document (so you have to keep multiple copies of the documents) Undo empty Recycle bin? (I know there have bee times I have wanted that!) Undo send email? There are many things in real life you can't undo (Undo 'insult boss', undo 'stupid bet' undo 'car crash') , and computes are no different.
Also:
Torches are shipped without batteries because if the batteries are in them, they hit a bump and turn on, and you have flat batteries.
No checkout person would ever say 'are you sure you want those batteries' it would be considered rude.
Brad, you're right about turning it off. I had that in the book, left it out of here for space, but thanks for filling it in. And yes, you are right that automatic deletion hits at a certain disk space level.
ReplyDeleteI invite you to consider that a disk system that REALLY Just Worked wouldn't put a hard-and-fast limit on the size of the recycle bin, but would use all unused disk space for it, automatically emptying it out as necessary. The OS would report the amount of available free space without taking the recycle bin's contents into account, unless a system tool explicitly asked for it, so the user wouldn't be aware of it. Again, we need more Just Working, in principle.
madmat, you're right that there are certain things that can't be easily undone. Amputating a leg springs to mind. But most things, even mods to shared state, can be backed out through a compensating transaction if the system is designed that way. For example, items bought with amazon.com's OneClick order don't actually enter the purchase system for 90 minutes, so a user can delete it if he makes a mistake or just changes his mind.
ReplyDeleteAnd yes, you are right that undo is much harder to implement. "Easy is hard", the saying goes. The automatic engine control system on today's cars is much harder to implement than the manual spark timing lever on the Ford's Model T. But it makes the driver's job much easier. The standard of care has advanced, in automobiles and medicine as well as software. Providing an app without undo capability, in the cast majority of cases where this is logically possible, is as unacceptable as manual ignition timing on a car, or a surgeon operating without washing his hands.
User Jeff submitted the following comment yesterday. For some reason, the comment moderation mechanism did not publish it, despite my having (I thought) approved it. Not sure why that happened. Here it is verbatim:
ReplyDeleteWhat's your problem with confirmation? If developers didn't confirm that you'd like something to happen, you'd turn around and complain that an action was taken without confirmation. If you spend a little time getting to know the operating system and applications, you'd learn that you can turn a lot of confirmations off. I personally hate applications that let you close without confirming telling you that you’re going to lose data. Sometimes the confirmation dialog also saves you from having to go save 15 different files manually. You laude google for their work, however, IT'S STILL A CONFIRMATION. If I enter a UPS tracking number, why doesn't their site just take me there? They've got the "I'm feeling lucky" button, why isn't their site smart enough to know that you're feeling lucky? (by the way, Live.Com has the same functionality) When developing software, you have to develop for the lowest common denominator. Those of you with mid to advanced skills must understand that. And if you have mid to advanced skills, you should also know that there are methods to avoid the confirmation dialog, or you aren’t as advanced as you’d like to believe. Most applications have an undo, but they also have confirmation. The inexperienced user will not know about undo, but they will know about confirmation. Users need to quit blaming developers for making software safer to use. What's so difficult about hitting ALT+Y or the space key or enter key when a confirmation comes up? You’re like the people who complain about spam in their e-mail inbox, but go out to the snail mail box everyday and don’t think twice about how much spam they have in their snail mail. (Now, here's a wonderful user interface, word verification, then tab expecting to go to the next field, instead you're taken to the blogger comments. That's real intuitive.) And comment moderation, don't want too many bad ones to show up, huh?
Jeff, my main problem with confirmation is that it doesn't work. Never mind that it's annoying and wastes time; never mind that it requires a user to understand a program's internal operation; concentrate only on the following fact, not opinion, but research-proven fact: it doesn't work. Users are constantly asked to confirm this or that operation, and they almost always answer yes because they do indeed want to do whatever that is. The relatively few times that the correct answer should be No, the users cruise through it on autopilot because they're so used to clicking Yes. This phenomenon is known as "chaining", and anyone who is ignorant of this basic fact of cognitive science should not have anything to do with UI design, in the same way that someone who is ignorant of basic anatomy should not be performing surgery. You might wish users would actually pay attention and read the box and think carefully about what the correct answer should be, but because they're human beings, and they're thinking about the Super Bowl or lunch or when they'll next have sex or even what they're going to do with your program as soon as the save operation completes, they don't. The software designers choices are either a) to recognize the user's humanity and figure out how to operate in harmony with it, or b) to harangue users ever more stridently to become something other then human. It is the beauty of software that operation a) is possible.
ReplyDeleteI can provide a clue about what happened to "user Jeff's" approved-but-not-posted comment: it showed up under the UPS vs Google article.
ReplyDeleteMr. Platt, I see you're getting quite a bit of abuse from programmers and power users, and I'm both. I'm generally sympathetic to your position (I came to this website because I bought and read your book, not because I found a Yahoo link), but I also see where the control freaks are coming from. I don't like cars that lock my doors for me when I engage the transmission, or beep at me if I haven't fastened my seatbelt. I don't like copiers which decide I must have made a mistake in selecting 8x11 paper for my copy, because the newspaper I've laid on the scanner window is much larger, and refuse to just copy an 8x11 section of that newspaper. I drove a manual transmission until I got married and my wife had trouble mastering one.
I actually don't like having a recycle bin, and appreciate that my editor (UltraEdit) asks me if I want to save my work if I'm closing the editor without doing so. Sometimes, not saving the changes is exactly what I want to do.
But I also appreciate that my user is not me, and most people have a job to do which doesn't involve intimate knowledge of the computer's inner workings. For such people, changes should ALWAYS be saved, with limitless levels of undo to back out each change one at a time. When they leave the editor, the changes have automatically been saved, so the question doesn't come up.
Incidentally, when I type some text into "Leave your comment" on this blog, and then click the "back" button, I get a popup confirmation saying "Are you sure you want to navigate away from this page? You have unsaved changes. Press 'OK' to continue, or 'Cancel' to stay on the current page." Kind of ironic, isn't it?
Here's one that drives me nuts. It's not a confirmation box, but it's certainly not thinking like a user.
ReplyDeleteIf I tell my laptop to go to sleep, I will sometimes get a modal dialog box popping up telling me I can't for some reason or another. I used to just close the lid to put it to sleep, but I'd get home, and my laptop bag would be cooking and I'd have about 3 minutes of battery life left. Now I select it from the shutdown menu, and wait impatiently until it turns off. The worst part is that sometimes this alert box is not on top of all the windows, so I have to go hunting it if my laptop stays awake longer than I think it "should".
What rocket surgeon decided that this is acceptable behavior?
Whew. That venting felt good.