8 ms·

Killing the Cancel Button on Forms for Good

55 points by UXMovement 16y ago

systemtrigger 16y ago
Completely agree. So many cancel buttons are just clutter.
Vivtek 16y ago
My favorites are designers who think the Clear Form button should be to the left of the Submit button. I mean, bad enough to have the opportunity to wipe out everything I just typed, but why make it that easy?
- jonasvp 16y ago
  Completely agree. While the cancel button might be useful, the reset button is such an invitation to disaster, I don't know why it was even invented. If I spend time filling out a form, why would I want to clear it? If I make an error, I'll correct it - not start anew. When I see a "clear form" button nowadays it's a big red flag that the owner of the site is still stuck in the 90s usabilitywise.
  - Vivtek 16y ago
    Well, for what it's worth, I thought it was stupid in the 90's, too. I never did understand the logic of having a reset button.
teye 16y ago
Yawn. Jakob Nielsen scooped you by ten years. http://www.useit.com/alertbox/20000416.html http://www.useit.com/alertbox/20000416.html
- Qz 16y ago
  Doesn't make it less true today.
- deleted 16y ago
  [deleted]
barrkel 16y ago
I strongly disagree with the confirmation dialogs' Cancel button: confirmation dialogs are generally pointless and annoying. It's far better to provide a means of undoing. On the other hand, Cancel buttons on configuration dialogs in non-web contexts are great: they relieve the stress burden of playing with settings. This is something that freaks me out every time I end up in System Preferences on OS X: I have no way to undo what I just did. I have to hunt around and fiddle to put things back the way they were. I much prefer the way Windows does it with OK and Cancel: opening up a dialog is like starting a transaction, and OK and Cancel become Commit and Rollback.
- chrisbolt 16y ago
  With OS X, every change is immediately visible so you immediately know what to undo. With Windows, nothing you change takes effect unless you click OK or Apply, at which point the Cancel button has no effect and there is no Rollback. How is this better than OS X? It just adds three superfluous buttons.
  - barrkel 16y ago
    It's simply not true that every change is immediately visible; only for appearance preferences is that the case. It isn't the same case for behaviour configuration. It's hard to understand how uncomfortable it feels when you're used to having this safety net, and it's taken away. It makes changing the preferences (for most applications, not just System Preferences) a much more cautious affair, in my experience. Even something as simple as changing the default font used in an application - once changed, it can take a lot of hunting to get it back the way it was.
    - lovskogen 16y ago
      Could you give examples of options that should need a second confirmation? I think the instantness and not having to Apply is great - but maybe I'm not setting the same options as you.
      - 16y ago
wvenable 16y ago
All my web application's forms have onbeforeunload handlers that prevent you from accidentally navigating away from the page (including the back button) once you've started editing a long form. It's possible to continue to navigate away from the onbeforeunload dialog but the cancel button is a nicer way out. Every cancel button also has a confirmation on it so you can't accidentally cancel the form either.
- lovskogen 16y ago
  What if the user really want back? You just broke the back button and moved it's functionality to Cancel.
  - wvenable 16y ago
    No, they get a dialog (you can't completely prevent navigation in a web browser). They can say, "yes I want to lose all my changes", and then it will go back.
Timothee 16y ago
Personally, I'm not against Cancel buttons in some cases for the simple reason that I'm not sure the site will work fine with the Back button on multi-page forms that are used for almost all payment transactions. I also tend to use a Cancel button if there's one, or a navigation link to exit the process because I'll be sure to avoid a "resubmit POST values?" alert if I were to click 'Back'.
jlesk 16y ago
I use Cancel buttons for pop-up forms all the time. It usually just hides the containing div, so re-opening the form will show the data as it was entered previously. Making the Submit button 2-3x longer than the Cancel button helps mitigate the risk of accidentally hitting the wrong thing.
stretchwithme 16y ago
Amen. How long will the dialog box drive people's thinking?
decadentcactus 16y ago
Considering most progress bars are just approximations anyway, Cancel buttons don't even work half the time. I distinctly remember pressing Cancel while loading a TF2 server, with maybe 80% filled, but it loads anyway, because it had actually finished loading, just didn't update the progress bar.
stackthat 16y ago
One big question is if you need confirmation button then should you put a "Cancel" or "No"? or both?
evanrmurphy 16y ago
Cancel buttons...[give] users the opportunity to accidentally click on it when it’s mistaken for the Submit button. Removing the Cancel button completely removes the chances of this mistake happening. This is an excellent point. There are two situations where Cancel buttons are proper.... The first situation is confirmation windows.... The second situation is progress bars. Would this suggest that Cancel buttons are never appropriate on basic HTML / mobile websites? This seems like an extreme rule to me, but maybe it's good advice.
evanrmurphy 16y ago
In Gmail, the "Compose mail" form has a Discard button that serves as a Cancel. Have others found this to be a nuisance? (It's never bothered me before, and I think I've often found it quite convenient.)
- mooism2 16y ago
  GMail's "Discard" button is needed because GMail saves your unsent e-mail as a draft otherwise. Whereas most forms don't upload your form while you're still filling it in, which is what makes "Cancel" superfluous from a functional point of view.
  - evanrmurphy 16y ago
    Gmail's basic HTML view also has a discard button, even though it doesn't auto-save drafts. You make a good point, though. Maybe basic HTML just has Discard to stay consistent with standard.
tav 16y ago
While I agree that they're often misused in forms, I'm not a 100% convinced that killing the cancel button is the right way to go. They're increasingly used as a web equivalent of the "close" button and in that context, they do function quite well. A substantial portion of both users and AJAX apps still don't use/support the back button effectively. And when there's a form overlaying the content, using a cancel button to get rid of it does make a fair amount of intuitive sense...
rkuester 16y ago
Neither "ok" nor "cancel" are appropriate answers to the yes-or-no question, "Are you sure?"
gcb 16y ago
forms does not have Cancel button! they have reset buttons. big difference. There's no input type=cancel. only input type=reset http://www.w3.org/TR/html401/sgml/dtd.html#InputType http://www.w3.org/TR/html401/sgml/dtd.html#InputType And resetting is sometimes desirable, say, for a real time map filter form. where you can play with the controls, reset, play some more, reset... you get the idea. Now, for forms that are presented to the user empty, as most are, the reset button with a 'cancel' label, is just plain dumb. yes.
yycom 16y ago
IME users (office drones) seem completely ignorant of the back button.

55 points by UXMovement 16y ago

Completely agree. So many cancel buttons are just clutter.

My favorites are designers who think the Clear Form button should be to the left of the Submit button. I mean, bad enough to have the opportunity to wipe out everything I just typed, but why make it that easy?

jonasvp 16y ago
Completely agree. While the cancel button might be useful, the reset button is such an invitation to disaster, I don't know why it was even invented. If I spend time filling out a form, why would I want to clear it? If I make an error, I'll correct it - not start anew. When I see a "clear form" button nowadays it's a big red flag that the owner of the site is still stuck in the 90s usabilitywise.
- Vivtek 16y ago
  Well, for what it's worth, I thought it was stupid in the 90's, too. I never did understand the logic of having a reset button.

teye 16y ago

Yawn. Jakob Nielsen scooped you by ten years. http://www.useit.com/alertbox/20000416.html http://www.useit.com/alertbox/20000416.html

Qz 16y ago
Doesn't make it less true today.
deleted 16y ago
[deleted]

barrkel 16y ago

I strongly disagree with the confirmation dialogs' Cancel button: confirmation dialogs are generally pointless and annoying. It's far better to provide a means of undoing. On the other hand, Cancel buttons on configuration dialogs in non-web contexts are great: they relieve the stress burden of playing with settings. This is something that freaks me out every time I end up in System Preferences on OS X: I have no way to undo what I just did. I have to hunt around and fiddle to put things back the way they were. I much prefer the way Windows does it with OK and Cancel: opening up a dialog is like starting a transaction, and OK and Cancel become Commit and Rollback.

chrisbolt 16y ago
With OS X, every change is immediately visible so you immediately know what to undo. With Windows, nothing you change takes effect unless you click OK or Apply, at which point the Cancel button has no effect and there is no Rollback. How is this better than OS X? It just adds three superfluous buttons.
- barrkel 16y ago
  It's simply not true that every change is immediately visible; only for appearance preferences is that the case. It isn't the same case for behaviour configuration. It's hard to understand how uncomfortable it feels when you're used to having this safety net, and it's taken away. It makes changing the preferences (for most applications, not just System Preferences) a much more cautious affair, in my experience. Even something as simple as changing the default font used in an application - once changed, it can take a lot of hunting to get it back the way it was.
  - lovskogen 16y ago
    Could you give examples of options that should need a second confirmation? I think the instantness and not having to Apply is great - but maybe I'm not setting the same options as you.
    - 16y ago

wvenable 16y ago

All my web application's forms have onbeforeunload handlers that prevent you from accidentally navigating away from the page (including the back button) once you've started editing a long form. It's possible to continue to navigate away from the onbeforeunload dialog but the cancel button is a nicer way out. Every cancel button also has a confirmation on it so you can't accidentally cancel the form either.

lovskogen 16y ago
What if the user really want back? You just broke the back button and moved it's functionality to Cancel.
- wvenable 16y ago
  No, they get a dialog (you can't completely prevent navigation in a web browser). They can say, "yes I want to lose all my changes", and then it will go back.

Timothee 16y ago

Personally, I'm not against Cancel buttons in some cases for the simple reason that I'm not sure the site will work fine with the Back button on multi-page forms that are used for almost all payment transactions. I also tend to use a Cancel button if there's one, or a navigation link to exit the process because I'll be sure to avoid a "resubmit POST values?" alert if I were to click 'Back'.

jlesk 16y ago

I use Cancel buttons for pop-up forms all the time. It usually just hides the containing div, so re-opening the form will show the data as it was entered previously. Making the Submit button 2-3x longer than the Cancel button helps mitigate the risk of accidentally hitting the wrong thing.

stretchwithme 16y ago

Amen. How long will the dialog box drive people's thinking?

decadentcactus 16y ago

Considering most progress bars are just approximations anyway, Cancel buttons don't even work half the time. I distinctly remember pressing Cancel while loading a TF2 server, with maybe 80% filled, but it loads anyway, because it had actually finished loading, just didn't update the progress bar.

stackthat 16y ago

One big question is if you need confirmation button then should you put a "Cancel" or "No"? or both?

evanrmurphy 16y ago

Cancel buttons...[give] users the opportunity to accidentally click on it when it’s mistaken for the Submit button. Removing the Cancel button completely removes the chances of this mistake happening. This is an excellent point. There are two situations where Cancel buttons are proper.... The first situation is confirmation windows.... The second situation is progress bars. Would this suggest that Cancel buttons are never appropriate on basic HTML / mobile websites? This seems like an extreme rule to me, but maybe it's good advice.

evanrmurphy 16y ago

In Gmail, the "Compose mail" form has a Discard button that serves as a Cancel. Have others found this to be a nuisance? (It's never bothered me before, and I think I've often found it quite convenient.)

mooism2 16y ago
GMail's "Discard" button is needed because GMail saves your unsent e-mail as a draft otherwise. Whereas most forms don't upload your form while you're still filling it in, which is what makes "Cancel" superfluous from a functional point of view.
- evanrmurphy 16y ago
  Gmail's basic HTML view also has a discard button, even though it doesn't auto-save drafts. You make a good point, though. Maybe basic HTML just has Discard to stay consistent with standard.

tav 16y ago

While I agree that they're often misused in forms, I'm not a 100% convinced that killing the cancel button is the right way to go. They're increasingly used as a web equivalent of the "close" button and in that context, they do function quite well. A substantial portion of both users and AJAX apps still don't use/support the back button effectively. And when there's a form overlaying the content, using a cancel button to get rid of it does make a fair amount of intuitive sense...

rkuester 16y ago

Neither "ok" nor "cancel" are appropriate answers to the yes-or-no question, "Are you sure?"

gcb 16y ago

forms does not have Cancel button! they have reset buttons. big difference. There's no input type=cancel. only input type=reset http://www.w3.org/TR/html401/sgml/dtd.html#InputType http://www.w3.org/TR/html401/sgml/dtd.html#InputType And resetting is sometimes desirable, say, for a real time map filter form. where you can play with the controls, reset, play some more, reset... you get the idea. Now, for forms that are presented to the user empty, as most are, the reset button with a 'cancel' label, is just plain dumb. yes.

yycom 16y ago

IME users (office drones) seem completely ignorant of the back button.