Posted by: jsonmez | March 25, 2012

Are You Really Sure You Want to Make a Cancel Button?

Are you really sure you want to create the cancel button for your application?

You know, I might click it.

Not only might I click it, I might click it at the most inopportune time.

I might click it right in the middle of  that large file that you are copying, right after you spun up that 2nd thread.


Cancel is a commitment

The next time you consider creating a cancel button, I suggest you think of it as a commitment.

In my world the cancel button has two promises.

  1. Stop what is currently happening in a non-destructive way.
  2. Stop RIGHT the F NOW!

I’ve been encountering a good deal of cancel button which don’t obey the basic laws of cancelling that any user would expect.

I have actually been randomly clicking “cancel” whenever I see it, much to my coworker’s dismay.

I started doing this, because I wanted to see how widespread the cancel cancer is.

And it is pretty widespread.  A majority of cancel buttons I have been testing neither stop right away or prevent destruction.

I found instead that clicking the “cancel” button in most programs is sure to hang that program for an extended period of time, ultimately causing you to kill the process, and it tends to leave processes half done without rolling them back.

Clearing things up

Let me be a bit clear here.  I am not talking about cancel buttons you see in an “Ok / Cancel” dialog.  Most of the time those cancel buttons actually work, because they are really operating as “back” buttons, they aren’t actually cancelling a process that is happening live.

I am talking mainly about cancel buttons that cancel an active ongoing activity.  For example, cancel buttons in an installer or during an SVN update.

We could call these kinds of cancel buttons “asynchronous cancel buttons.”

But, I need to provide a way for the user to cancel

Good, but don’t lie about it.

There are certain things that just can’t be cancelled.

When I get on a plane, I can cancel my trip when I am sitting there waiting for the door to close.  I can even cancel my trip while the plane is taxing to the runway, if I yell “I have been RAPED by a BOMB that is on FIRE!

But, I can’t cancel my trip, once the plane has lifted off the ground.  If I try to cancel it then… well, bad things would happen.  Very bad things.

So how come when I am installing your software, or your software is updating its database, I have this shiny little cancel button I can click at any time during that process?

Surely I cannot cancel just any time!

Surely there are parts of the process that cancelling would be fatal or it is too late to rollback.

My point is, if the user truly can’t cancel, don’t present a button that says they can.  More specifically, if you can’t obey the laws of cancel 1 and 2 from above, don’t even show a button.  Just say “sorry, you can’t cancel this process at this time.”

I don’t even need to know why I can’t cancel.  I mean, it will make me feel better if you tell me that the Unicorn Glitter Engine is in a critical state and any disruptions could end life as we know it, but I’ll settle for you just greying out that cancel button or not displaying it at all.


Putting back on the developer hat

I’m guilty of it myself.  I know I have created cancel buttons in the past that have caused pain and anguish.

But what can we do about it as developers?

First off, we should be thinking carefully about breaking a long running process into steps.  At each step of the way we should consider if it is conceivable to cancel that step without destroying data and hanging the application.

In any long running process, we should be able to identify certain parts which are cancellable and those which do not make sense to cancel.

It is your job as the developer to ensure that if you decide to allow for cancelling that the cancel undoes the existing process and work immediately.

I cannot stress this enough!

This is the behavior that most users expect and the very meaning of the word cancel.

To do this might take extra work.  You might have to think a bit more about the threading situation of your application.  You might have to think about rollback situations.  But, if you don’t do it, your cancel button will become just like the boy who cried wolf and no one will believe them.

And if you’re not willing to go through this effort, at the very least, be kind enough to your users to just remove the cancel button, because you can bet I’ll be clicking it!



  1. I disagree with you about the basic purpose of the Cancel button. But yes, the Cancel button is too often used inappropriately.

    The Cancel button is a magical button because we’ve built up trust with the end users – If you press this button we guarantee you will go back to the state you were in before you performed the action that got you there.

    If it takes a bit of time to revert those changes, that’s fine, but I want all changes reverted. If you can’t revert, don’t use a cancel button, use something like “STOP”

    • Good point Chris, I agree with you about using something like “STOP” if you can’t actually revert the changes.

  2. Many good points here and thanks for the article. The only thing I’ll quibble over is your second promise.

    I think it’s acceptable in some cases to treat cancel as a “request” if you give suitable feedback to tell the user that you’ll do what they want but they should just bear with you for a second or two longer.

    The scenario I’m imagining is where the user’s action has triggered a remote process where, to cancel it, another action must occur.

    • I also think it is fine for the cancel process to take a second or two, it just needs to begin immediately. Not in a minute or two.

  3. Only allowing CANCEL between discrete steps is not adequate. The gaps between steps are usually very short (milliseconds), whilst the steps could be long (seconds). Expecting people to sit poised waiting for the brief time that CANCEL is applicable is unreasonable. Reaction times are a minimum of 1/10th of a second.

    Maybe CANCEL is the wrong word. We need something succinct that means ‘when this bit of the install (or whatever) has completed – which may take some time, please undo it and also undo all of the previous steps’. Most users accept that CANCEL actually already means that. If you want a ‘stop whatever you are doing even if it is dangerous to stop’ then ABORT may be more applicable.

    I have buttons in applications that I have written whose tooltip explicitly states that the button will not be honoured until a stage has been completed and that this may take some time. But the button is disabled as soon as it is pressed to confirm that the request has been registered. I have considered having a mechanism to say ‘I have changed n=my mind, please ignore my CANCEL request’ (a CANCEL CANCEL button – could even be an alternative button text on the CANCEL button itself) but have never implemented it

  4. Along the same lines…In versions of Windows prior to Vista, when you clicked on “shutdown” or “logoff” you were prompted for a “do you really want to do that?’ On my new Win 7 pc the default button was “shutdown” and lo and behold… no prompt!!! Hope you weren’t working on anything important because if you accidently click on that, buh bye, all of your running apps are toast. If you’re lucky your main apps might prompt you to save your data, but the vast majority honor the shutdown and just terminate. What genius thought of that “enhancement”?

    • I can’t remember what it use to be like but the standard to tell the difference is
      Shutdown… //The … indicates there is an additional, Cancel-able step
      Shutdown //No … so it will occur immediately without any more interaction.

  5. I like the big, red Cancel button. Next time I write a UI component, it will have one of these. And when a user clicks it, it will say…

    “Please do not click this button again.”

  6. I think it is fine if pressing the cancel button does not stop a process immediately, But we have to give the user immediate feedback that the click was registered, e.g. by disabling the cancel button or changing some status. We have to inform the user that something different has begun.
    There is one other point that might be considered: If pressing the cancel button abandons a lengthy operation, the application should be nice and give the user a last opportunity to not cancel if she pressed the button unwittingly.

  7. VMWare is bad about this. you click “resume” to resume a suspended image and there is a dialogue with a cancel button…pressing said button takes twice as long as loading the image (presumably it must resume the image then suspend it again)

    i have not been guilty of this but only because its not really come up. in all cases my cancel is on an input dialogue or a confirm dialogue. once i had one on a download dialogue which pressing it canceled the download leaving a .part file so the download may be resumed at another point (with a dialogue alerting them of this fact)
    ive never seen a point in my programming life where i need a cancel but can’t reasonably cancel…if i can’t cancel it dont show the button.

  8. […] 9. Are You Really Sure You Want to Make a Cancel Button? […]

  9. This has long been one of my pet peeves as well. Don’t give me a Cancel, or any other button, if you can’t really do what the button says. Microsoft is the absolute worst about this. I’m a developer, I understand why Cancel can be hard, yet it still irks me to run into this – it’s just sloppy and lazy.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: