Bad Proven Practice

In the design community (software/industrial/etc) we get into ruts. Ever think that some common automobile features, that have been present for decades, are just plain wrong?

Some of them one might think are simple accidents of history, but ergonomic studies have shown that many (e.g. using a steering wheel to steer) are no worse than any known alternative.

User interface design is riddled with bad patterns. Some of these patterns are part of successful systems and will continue to be applied many more years. What do we do with good patterns gone bad? Or, more precisely, what do we do with patterns that exist simply because we didn't know any better?

For example:

Pattern: Confirmation Dialog For Dangerous Actions

Context: You are designing a part of an application where the user is allowed to delete or destroy data by initiating an explicit action. These types of actions can include:

Dragging data to a deletion icon.
Selecting data and applying a DELETE command from a pulldown menu.
Quitting an application without saving a file.

Problem: A user will become frustrated with a program that allows him to destroy data without chance of recovery.

Solution: Once user has selected the destructive action, prompt him with a dialog box asking if he wants to continue with the action.

This pattern is common bad practice. If the user is performing an explicitly initiated dangerous action (the key is labeled very clearly DELETE) then the user probably wants to perform that action. Asking for a confirmation in a dialog box is a waste of time. In addition, a well designed application will allow for recovery from any user initiated destructive operation.

I disagree with your statement that "a user performing an explicitly dangerous action probably wants to perform that action." Users new to a system will often poke around and try things, and sometimes users will click on the wrong button. I am not saying there are no annoying and unneeded confirmation boxes in existence, but confirmations save mass market and new users from making mistakes they usually do not know how to recover from.

--KenMegill

For example: You can delete Win95 files and directories by dragging them to the trash icon. You probably really meant to do that, so why should you be prompted by a confirmation dialog? If you really didn't mean to delete the files, you can recover them anyway. -- ToddCoram

What if you can't restore it, eg you are using a remote resource with no undo facilities and you can't emulate them?

What if you are my mom, and can't recover them if you delete them accidentally? --KenMegill

I have found that the added dialog box does not help. I have become so used to clicking on the Yes button that I do it automatically, even on things I do not wish to delete. The "safety" provided by the extra confirmation is an illusion. -- WayneMack

I used to use an application that would randomly swap the "delete" and "cancel" buttons in the deletion confirmation dialog. Whilst this was sometimes annoying, it occasionally prevented me from mistakenly deleting things, because I had to look harder and read the labels of the buttons, making me think about what I was doing - so it was useful. However, this is a very simplistic way to do things. Perhaps a CaptchaTest would be better for confirming potentially destructive operations. -- EarleMartin

In general, AndrewKoenig refers to these as AntiPatterns (a Wiki page with a lot of links from and to it!)

The particular problem has been called (by EstherDyson) the "Do You Really Want to Do This With All Your Heart?" user interface. Aside from being frustrated, it doesn't work; people get so used to confirming, the one time they really don't want to do what they just said, they don't realize they don't want to do it until after they've habitually confirmed. (Of course, you could ask them again....-)

-- PaulChisholm

What about a wide-spread practice that everyone thinks is good, but it is really not-so-good (like the confirmation dialog example above). This is a case of "Bad Practice in Good Practice's Clothing." Not really an AntiPattern, but a pattern that pretends to be about good practice. -- DavidHooker

The rule of thumb I was taught that any confirmation to which the user gives the same answer 90% of the time ("Really delete?") is useless; the other 10% of the time, muscle memory carries you through the box before you think. I think the 90% threshold is too low. AboutFace says that confirmation dialogs work only if they are unexpected, and I think that's a better formulation.

Another BadProvenPractice is dynamic menus, in which menu selections are made unavailable because "you couldn't possibly want to do that now!". The idea is to remove UI complexity; in practice, I sometimes wind up clicking frantically all over the screen so that Microsoft Word (to name just one offender) will consider me in "table-cell-editing state" and will display the table-cell-editing variant of the Table menu. Like the confirmation dialog, dynamic menus are powerful when well-used, annoying when overused.

-- BetsyHanesPerry

Dynamic menus are an example of ModalBehavior?, discuraged by most all interface guides. Pay attention, Microsoft!

When he was working at Apple, Bruce Togazzini (sp?) suggested that whenever you select a menu item that's greyed out, the system should pop up a dialog box (or tool tip, or something) that tells the user how to make that menu item valid. Unfortunately, nobody has implemented this idea.

Except Windows 2000. They snuff least-recently-used menu items from the Start menu. Then when you look at the menu too long they pop up a help baloon saying to click the little down arrow icon. -- PCP

MicrosoftWord used to implement this. When you pointed to an inactive menu item, the status bar text changed to something like "This menu item is not available because ....". Maybe they removed it after some usability study came to the conclusion that users don't look there...

Pattern: Confirmation Dialog For Dangerous Actions

Try this. A program has an object model of Major Records, each added or removed from a list, and Minor Records for each Major one. The Minor ones are checked as On or Off in a short list. A worker loads one file with all these records, and messes with each one for their workflow.

If you delete a Major record, you get a confirmation dialog.

An Undo-Redo stack is well beyond the scope of the project.

The fix is to (think outside a rather lopsided box and) make each file only contain one Major Record. Now the Open dialog and its file list become the list of Major Records. And you get rid of ones you don't want to see in that list by recycling them.

This fix also simplified the hell out of the innards of your program. You added features by re-using the OS properly, including the recycling bin's Recover feature. And you have one less dynamic list inside the program, and one less listbox in the UI, and one less clump of Add Delete code, and so on...

If BadProvenPractices typically happen when someone declines to make a program more complex, simplifying often fixes them.

-- PCP

"This is a tradeoff though. You traded Integration for a form of Undo. If Major Records are edited often enough, the users may find it a burden to have to work through a File Manager to fiddle with them. Sure you make the program simpler internally, but you've made it more complex externally. Just imagine writing the documentation for how to Delete a record now."

How about a checkbox on the dialog that says "Don't ask for confirmation". It would last the entire session.