Inspired
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.

As a fallback the delete action is confirmed by posting a form
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?
April 1, 2011 at 5:53 pm
Very interesting approach, until now I just imagined to display a javascript alert before deleting on a web page, but in the iphone it doesn’t have that option. I think I will use that idea in my job 🙂
April 4, 2011 at 6:37 am
Great idea! The only problem I see is the confusion for the user if they want to go back. Is hitting an escape button or clicking outside going to be obvious to the user?
April 4, 2011 at 12:58 pm
Eric: Good point! On the other hand in the words of Alan Cooper:
Maybe this is one of those idioms. From observing users using this design pattern I gathered that they get it really quick, but it can of course be a problem discovering it the first time.
Do you have an idea of how to hint the user without using too much screen estate and getting overly complicated?
April 28, 2011 at 6:24 pm
Very neat.
Regarding the graceful degradation section, are we still considering cases when users have disabled JS or CSS ? I’d say 99% of users have them enabled, why bother for the paranoid users that are still stuck on blocking these features ?
May 13, 2011 at 12:35 pm
Pablinho I think graceful degradation is very much a concern to take into consideration. It’s not just those users that have JS and CSS turned off (whether it’s because of paranoia or of corporate policies) but also those users that uses assistive technologies like screen readers. And also, the web is rapidly moving from just being viewed and used by desktop browsers. There’s a whole array of new devices that’s being connected to the web, and I’m not just talking about mobile devices but cars, refrigerators and what have you.
So I firmly believe that graceful degradation or more accurately progressive enhancement is becoming even more and more important.
May 21, 2011 at 5:02 pm
Really neat concept! Are you planning on releasing a code sample for this? I couldn’t find a download link or sample in your article.
May 21, 2011 at 11:53 pm
Jaana Glad to hear you like the concept! I’m actually thinking about building a jQuery plugin for it, but don’t know when I get the time to actually do it.