Some basic UI patterns for preventing accidental deletion

Many client applications and web sites let the user enter and manipulate data, and these manipulations often include the ability to delete data. Designers of UIs that include deletion of data generally feel the need to protect the user from unintentionally destroying data. For such a UI, it's important to consider the context surrounding the Delete command (or whatever action triggers deletion) before settling on a solution.

It's worth asking: exactly what is the concern with the user clicking a Delete button? I've often heard people express fear that the user's mouse might slip and click a Delete button, or that the user might not be paying much attention to what they are doing and might stab at the Delete button without understanding what it will do. I suspect that, in many cases, designers now habitually second guess the user's intention behind a deletion without considering alternatives.

Designers actually have more choices at their disposal than a delete confirmation dialog. Here's a quick survey of some UI patterns for a Delete command, in rough order of what I perceive to be the most frequently encountered to least frequently encountered:

1. Delete with Confirmation Dialog. The user selects a Delete command (or press the Del key, etc.) and the application displays an "Are you sure?" dialog; the application only deletes the data if the user responds affirmatively. Such dialogs are ubiquitous. The goal is to provide the user with a second chance to consider their action. In my experience, such dialogs provide slender protection—users can blow past the confirmation dialog before their brain has even registered what it is asking them.
   
2. Delete Immediately. The user selects Delete, and the application deletes the data immediately. This is generally used if the amount of accidental loss is very small, or if it's quite easy to reconstruct any accidentally deleted data. A good example here is the Delete button next to items in today's typical web shopping cart. In my opinion, this plain "Delete Immediately" pattern is woefully underused. As shopping carts show, it's perfectly fine to blow away data immediately if the user can just quickly add back something they didn't mean to delete. (This is probably another case where the difficulty of producing a dialog in vanilla HTML inadvertently leads to a better UI.)
3. Delete + Undo (single or multi-level). The application deletes the data immediately, but allows the user to undo the deletion by selecting separate Undo command. The application may allow the user to Undo only the most recent operation, or any arbitrarily long history of operations. The classic example here is a text editor. Most decent file system browsers support an Undo stack as well. This model is actually quite nice: it provides the benefits of Delete Immediately, and moves the complexity of restoring data to those users actually facing the need to get their data back. Even a single level of Undo can be helpful, as described in this post about Gmail's Undo Deletion command.
4. Trash (with manual or automatic cleanup). The application moves deleted data to a temporary Trash bin (or Recycle Bin, if you're afraid of being sued by Apple). The user can recover deleted data from the Trash. The data is permanently deleted at some later point in time: when a time interval elapses, when some space threshold is exceeded, or when the user manually empties the Trash. The classic example here is the Mac Trash can, but most email clients follow this model as well. Perhaps because of these strong precedents, the Trash pattern is used almost exclusively in icon-based object-oriented UIs, and rarely anywhere else.
5. Mark for Deletion. The user invokes Delete, and the selected data is marked in some way (e.g., grayed out, or with strikethrough) to indicate that the data is still there, but will no longer be treated as active (included in calculations, etc.). As with the Trash pattern, the data is permanently deleted at a later point. Example: IMAP email clients such as Mozilla Thunderbird. I consider this to be another under-utilized pattern.
   
6. Delete with Context-Sensitive Confirmation Dialog. The user selects Delete, and the application determines from the data to be deleted or other contextual information whether the user is likely to be unaware of consequences of the operation. In other words, the delete confirmation dialog only comes up with when it's important. A tepid example of this pattern comes up in text editors that only give you a "Save changes?" dialog if you're trying to close a non-empty document, but that close an empty document silently. This is another pattern that could benefit from much wider use. The basic idea is that, if the dialog only came up in the 10% of the time the user was really about to shoot themselves in the foot, the user would have a higher chance of stopping to read what it said. "Are you sure you want to delete this file you've been working on for the last eight hours?"

Any time an "Are you sure?" dialog is about to be added to a UI should force you to at least briefly consider whether an alternative pattern might better suit the context.

Comments

[Dick Boogaers]

Here's another one:
If the deletion will result in some other user interaction, defer it until all chances the user has to cancel further actions have passed.

Case in point: if a user deletes a reservation in a reservation system and this has financial consequences (some money has to be paid back) simply go on with that, but provide cancel buttons along the way, to cancel the whole string of actions that took place since and including the delete action.

[Michael Zuschlag]

Right on! I think knee-jerk use of confirmation message boxes is one the design habits contributing to epidemic message-box-blindness (for example, see http://napps.networkworld.com/compendium/archive/003362.html). IMHO, a message box should appear only for exceptional circumstances (e.g., your Pattern #6). One should never design a message box to appear *every time* the user clicks a particular menu item or button. That said, there *is* a need for a GUI equivalent of a guarded switch to prevent slips of the mouse (or accelerator key) from activating an undoable command. A message box just isn’t the way to do it.