views:

350

answers:

9

If a user clicks a cancel button should it pop up a dialogue asking for confirmation?

If so, should this be all the time, or only when there are unsaved changes on a form?

+9  A: 

No unless it's something that is very vital/potentially harmful. Having popups followed by popups is annoying.

statenjason
+8  A: 

If canceling the action will destroy data or a device, yes. For instance, canceling in the middle of upgrading the firmware of some device.

If the action being performed takes a long time and an accidental cancelation will require starting over, yes.

For instance, I don't find the pop-up here on StackOverflow annoying when I decide to close a tab rather than making an edit I started on one of my questions.

richardtallent
+1 for the case of time taking operations. Though I don't agree about "Cancelling the action will destroy the data". Almost all forms take some inputs from user, if "Cancel" is pressed, let it be "Cancel"!
Hemant
+2  A: 

Make the action easy to do without confirmation (don't annoy your users!). But, also make it easy to undo. Read Alan Cooper's About Face for lots of good UI advice.

rp
Is it just me or does SO's link insertion mechanism stink?
rp
It is just you. Not everyone throws junk into links.
Geoffrey Chetwood
+4  A: 

"Cancel" means to give up on an action before it begins. If the action has already started, the command should be named "Stop" instead. That makes it clear to the user that the button might interrupt something in mid-stream.

A real Cancel action doesn't need confirmation because it doesn't cause any problems. A Stop action might, but only if stopping partway through could leave things in a messed-up state. (And in that case, you should consider finding a way to have the stop back out all the already-made changes so that the state reverts back to what it was before the action began. This isn't always possible, of course, like if you're deleting files.)

Jens Alfke
+2  A: 

It really depends on the situation.

Encoding a video for example, a process that may take hours, should have a confirmation, just because you may accidentally hit the button at 99%.

The initialization process of an installer or other app, on the other hand, doesn't need a confirmation since it can typically be restarted quickly enough and doesn't take long to begin with.

If clicking Cancel starts a process that will potentially take a long time (let's say it needs to reverse changes), the user should be informed about that, possibly with a popup, but some text next to the button might suffice as well.

The general rule is to minimize Confirmation Dialogs as much as possible, if for example it could be replaced with an Undo action. I don't think this applies to most Cancel buttons though.

deceze
+2  A: 

Use the following algorithm to determine the answer to your question:

if (1-p)*w > p*a then ask for confirmation

where

  • p is the probability that the user really wanted to cancel (0.7 or so)
  • w is the amount of lost (work-) time due to inadvertent cancelling
  • a is the time lost due to an anoying confirmation (5 seconds or so)

Of course you have to estimate p, w and a. Using my default values, you should ask for confirmation when unintentional canceling would cost the user more than 10.5 seconds of time. So, in the case of a long-time operation, e.g. encoding a video, you shouldn't ask if the user clicks cancel within 10 seconds after starting that task. In the case of data entry, don't ask if the form is still completely empty, but ask if the user has already entered data.

ammoQ
+1  A: 

Basically, if undo-ing a cancel is difficult, time-consuming, or impossible, you should prompt the user. Those are usually the case when the user has done some actions that they might wish to preserve (e.g. writing a blog post and closing a tab, updating firmware on a hardware device, running system updates, installing large pieces of software) instead of just deleting the current state. After all, sometimes the cancel button may be clicked accidentally. You just need to use common sense to determine whether it would be a really bad experience for the user if an operation was accidentally cancelled (which would call for a cancel prompt), or whether they could easily restart whatever operation was accidentally cancelled without much loss. The strategy I use for solving such problems is by putting myself in the user's shoes, i.e. imagining myself as a user of this program. How would I feel if I accidentally clicked cancel??? If that mentality is grim, add a prompt in case.

Maxim Zaslavsky
A: 

I think the answer in terms of data.

If user made changes on data , not talking about clicking somewhere on interface, user should be asked to confirm exiting. But if no change happenned, no reason for confirmation. Because confirmation is an effort for user.

+1  A: 

It would be better to not prompt, but make it easy to undo the cancellation once it is done, if possible. GMail does this well. You click 'Delete', it deletes, but you get a link at the top to say 'Undo delete'.