Action-Confirm Design Pattern

Inspired by the User Interfaces of mobile apps on the iOS and Android platforms, I created a delete button using a design pattern that I’ve named the Action-Confirm design pattern. I created this for a web application that I recently worked on.

In a nutshell it’s an Action button that transforms into a Confirm button when clicked. It’s a compact solution that provides the user with a way to confirm a possibly destructive action without interrupting the flow of the application.

What problem does it solve

The problem with confirmation dialogs is that they interrupt the flow of the application. Often these dialogs are modal so the user has to stop and deal with them to get on with whatever it was she was doing. The Action-Confirm design pattern presents a less intrusive solution that also is very compact. It keeps the user in the flow and is very quick to act on.

When to use

Use this design pattern when:

• The user needs to confirm an action
• Screen estate is limited
• You want something less intrusive than a regular confirm dialog

The solution

The user is presented with a list of items. Each item has one or several actions. In this example the action is a Delete icon.

When the user clicks the Delete icon it transforms into a Confirm button that looks distinctively different. The user can now either click the Confirm button to proceed with the action or click outside it (or press Esc) to revert to the previous state.

If the user clicks the button it’s replaced by a loader animation. It’s important to provide this feedback so the user knows that work is being done under the hood.

After the item has been deleted on the back-end the item is being removed from the list.

If something would go wrong and the item couldn’t be deleted, the item is reverted to its original state and an error message is displayed (not shown in an image).

Caveats

Graceful degradation

In a web environment this design pattern depends on JavaScript to be available. You therefor need to provide a fall back solution in cases when JavaScript and/or CSS aren’t available (Progressive enhancement). One way to do this, and how I implemented it, is to let the default action of the delete button (which in fact is a <a>-element) be to navigate to a confirmation page that has a form with a submit button. It’s important that the form is posted using the method POST and not GET.

Note: The reason you should never let a regular link (or a GETrequest) make a destructive action is that it makes the application very vulnerable. Imagine for example a search spider following all delete links. Uh oh!

Use undo instead

Naturally one can argue that a better design is to instead of making the user confirm an action, let her easily recover from errors by providing some kind of undo. However, in some circumstances this isn’t an option because of limitations in the underlying implementation. In these cases the Action-Confirm design pattern could be a viable solution. Read more about using undo in the article No undo? Redo!.

Don’t we want to interrupt the user?

One can also argue that it’s a bad thing not to interrupt the user with a modal dialog. After all, doesn’t we want the user to stop and evaluate whether the action was intended or not. Research has showned that users often just click through these dialogs without giving them a second thought. In these cases the dialog becomes useless and nothing more than an annoyance. This design pattern doesn’t solve that problem but it minimizes the intrusiveness of it.

Conclusion

I created this design pattern to solve a common problem: Confirmation of an action. What do you think? Is it better than a regular confirmation dialog? Could it be further enhanced? Are there any other problems with it?