0

I'm working on my first (mildly) significant web app, which comprises multiple pages and a modal dialog for entering/editing/deleting information. One view displays a tabular list of objects and offers the user the chance to edit (in a modal dialog) or delete objects individually.

I want to ask the user for confirmation before performing a destructive action, but I'd rather not use:

  • window.confirm("...") - too clunky
  • Angular/Boostrap/jQuery/other modal - visually better, more customisable, but lots of mouse movement back and forth if deleting multiple objects.

I've seen (but cannot currently find again) a solution which I think was described as a "modal button". Its initial label signifies the action ('Delete'). On first click, the label changes to ask for confirmation ("Are you sure?"). A second click invokes the action. Alternatively, mousing away cancels the action. The two clicks must be greater than some minimum time interval apart so that a quick double-click doesn't invoke the action.

To me, this feels like quite a nice way of asking for confirmation, but is it an established pattern? Or too unconventional? Are there existing implementations out there?

Edited to add:

The modal button implementation I was thinking of : http://bl.ocks.org/mbostock/584742

4

No. This will potentially lead to annoyed users who start spam clicking on buttons, which defeats the purpose of having a confirmation step in the first place.

When should you use modal?

When you're dealing with uncommon one-off actions with potentially serious consequences (e.g. irreversible delete of multiple records). The modal gives you room to explain to the users about the consequences of the action before they proceed.

What if you're dealing with more common actions where users may perform said action several times in a row?

Consider implementing undo-able/delayed actions. Allow the user the ability to quickly perform the action, but give them the opportunity to reverse the action. This can be done as a "soft" delete (e.g. Email Trash Bin), or a delayed action where the system actually doesn't process the action right away, but provide a several seconds delay in case the user made a mistake and need to undo (e.g. Gmail "Undo Send" functionality).

  • Delete and commit are already decoupled. The delete appears to be instant, but only updates the in-memory model. There is a secondary 'Save' action that commits the sum of all additions/edits/deletes to the database, but there's no explicit indication of how the current state differs from the persisted state - it's left to the use to remember "I added that one, changed those two and deleted that one". I think I'll explore giving visual indications of changes, and having undo/revert options. – Chris Oct 14 '15 at 7:32
  • Oh, you have a commit save button for the user? If so, there's probably no need to have a separate confirmation. Clicking on save acts as the confirmation. – nightning Oct 14 '15 at 16:57
2

You should let user delete or edit without confirmation, which increase friction. Instead of confirmation, you should implement an undo action.

Have a look on this example in Rails.

  • Zero-confirmation-with-undo does introduce a level of complexity (where do you store the info, for how long do you allow the undo, etc), but there's no doubt that it's all the rage at the moment. – adelphus Oct 13 '15 at 23:45
  • @adelphus Just have a look on the video. The complexity depends on your stack, but it can be easy to implement in Rails or others popular frameworks. – Benjamin J. Benoudis Oct 14 '15 at 23:31
1

if deleting multiple objects

You could provide a way to select multiple elements (checkbox) and a button to delete the selected rows (with a popup if the number of deleted rows is big enough).

This way, you need 2 (spacially separated) clicks to delete one item, but only n+1 click to delete n items (or n+2 if you add a popup).

There is a secondary 'Save' action that commits the sum of all additions/edits/deletes to the database, but there's no explicit indication of how the current state differs from the persisted state

Or you could still show the 'deleted-not-commited' item with a some transparancy (or visual indication that it will be deleted). The button that what used to 'delete' it could be used to cancel this action (the 'revert option is then only implemented on client side).

  • This morning I was considering visual cues to show "this item has an unsaved edit" and "this item will be deleted (but here's a restore button)". The separation of selection and action is appealing, so thanks for the suggestion. – Chris Oct 14 '15 at 10:25
0

I'm concerned that this interface can be simultaneously too subtle and too irritating.

As a user, when I perform an action with potentially grave consequences, I expect something obvious -- like a pop up. The pop up can look elegant, but it needs to be obtrusive enough to catch my eye.

The other problem; if I have to click on the same button, but wait for a certain interval before doing so, then I'm being bottle-necked. It's really irritating when I have to wait for software. Sure, it may take me time to move my mouse to a pop-up, but at least I'm doing something and don't feel like I'm having to wait on the software.

I think pop ups are the way to go. Cutting edge user interfaces are fine, as long as they accomplish the task, but when there are consequences to an action, function should take precedence over form. The whole point of a confirmation is to get the user's attention, so it stands opposed to subtlety.

0

Maybe you're thinking of implementing an Edit Mode, such as when updating an iTunes playlist on iPhone.

You have your playlist, you select Edit. Now you're in Edit Mode. The only options are Add, Reorder, Delete. There are 2 taps to delete - however, you do not select the same target twice. When finished, you exit Edit Mode, and can no longer perform destructive actions.

The way Apple has implemented this is smart - using one side to delete, then the other side to confirm - because sometimes we accidentally double-click on a target.

Edit: So to answer the question - no, it's not a good idea. Use a separate target, ideally one located away from the first one.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.