MSDN Magazine > Issues and Downloads > 2005 > March >  { End Bracket }: To Confirm is Useless, to Undo...
{ End Bracket }
To Confirm is Useless, to Undo Divine
David S. Platt


The common user interface technique of confirmation, popping a dialog box into the user's face and asking, "Are you really REALLY sure you want to do that?" is evil. It's unfriendly, it's distracting, and it's completely ineffective. It shouldn't exist. Anywhere. Not ever.
Have you ever, even once, said, "Whoa! I didn't want to do that. Thanks," and clicked No? Or have you seen anyone do that? I haven't. Confirmation is so vastly overused that it has, ironically, 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. It provides you with no safety whatsoever.
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. On the contrary, 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.
What if the user really is mistaken? 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?" A good user interface should and can save us from mistakes like that by preventing the problem initially. 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 inside, so it'd work the instant you unwrapped it and no one would ever have to worry about buying the correct size.
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 can be hard"), 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. It's much more efficient to fix the relatively small number of errors that actually do occur (for example, a slip of the mouse that deleted 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.
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 picture. 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. An application with undo capability recognizes and enhances the user's humanity.
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 ask permission, ask forgiveness. Provide undo, not confirmation.

David S. Platt teaches programming for the .NET Framework at Harvard University and at companies all over the world. He was selected by Microsoft as one of their Software Legends, which you can read about at www.softwarelegends.com. He is the author of nine programming books, the most recent of which is The Microsoft Platform Ahead (Microsoft Press, 2004). Reach him at www.rollthunder.com.

Page view tracker