An undo/confirm alternative for the web

When developing an application, we often have to think about protecting the user from actions that are irreversible. You don’t want the user to be able to do something in one click that they regret a split second later.

Two ways about it

There are two ways of tackling this problem: undo or confirm. You either give the user an easy way to quickly reverse their last action or make them stop to think about what they’re about to do.

The first option, the undo, is arguably the better one, which is why you see a lot of native applications opt for it. It bypasses the inefficiency of a confirmation prompt and makes the user feel more in control by not questioning their every action. When the user does make a mistake, there’s always the trusty CMD+Z (CTRL+Z for Windows users) to fall back on.

However, when you develop a web application, you don’t always have the luxury of a native development environment. Mimicking native undo behaviour on the web is still a tricky undertaking. And when undo is implemented, you rarely get the full package: multiple undos, redos and/or a history overview.

The confirm option typically interrupts the user between the clicking of a button and the action behind it with a dialog. But when you present the user with such a prompt, you are annoying them in two ways. 1) They have to read a message that states the obvious. Users instinctively know the underlying message of the prompt, yet we still ask the user, ‘Are you sure you want to do this?’ over and over again. 2) They have to move their cursor/finger away from the thing they were doing to the ‘Yes’ or ‘OK’ button and back.

But there’s another way.

The middle ground

In the web application I’m currently working on, I wanted to make the user think about what they were doing without the hassle of a confirmation box. I wanted all the benefits of the confirmation dialog without the user feeling interrupted by stating the obvious every time they were doing something irreversible.
Essentially I just wanted them to use the time it takes to click the ‘Yes, I’m sure’ button to reflect on their action before taking it.

A hover-locked button

The solution (inspired by a confirm menu in a game called “Wild Star”): a simple button that is locked until the user hovers the cursor over it for a set duration.

An animated GIF showcasing how the hover-locked button works

<button class="fa fa-trash-o trash c-hover-locked" data-locked-sec="6" title="Remove this style sheet">Remove this style sheet</button>

The class applied to the button comes with a data-locked-sec attribute that allows me to overwrite the duration it takes to unlock the button based on the importance of the action behind it. The duration for the button that deletes a project, for example, has a lock duration of 5 seconds, whereas a single list item only lasts 1 or 2 seconds.

The downsides

  • There is no hover on touch devices so it won’t work on mobile phones or tablets. This isn’t a big problem for my current project since there is no mobile side to it, but I will need to look into a confirmation dialog fallback for computers with a touch screen like the Microsoft Surface.
  • The user’s first contact with the hover-locked button might cause some confusion. In my application, a tooltip explains how to use it on the first project.

The hover-locked button doesn’t completely replace the confirmation dialog. If the action the user is about to take has repercussions they might not know about, a confirmation dialog is still the way to go. Combining the two has the added effect of giving more weight to the confirmation dialog, so that when one does pop up, the user knows something’s up.