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.<p>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.
Yawn. Jakob Nielsen scooped you by ten years.<p><a href="http://www.useit.com/alertbox/20000416.html" rel="nofollow">http://www.useit.com/alertbox/20000416.html</a>
My favorites are designers who think the Clear Form button should be to the <i>left</i> 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?
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.<p>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'.
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.
<i>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.</i><p>This is an excellent point.<p><i>There are two situations where Cancel buttons are proper.... The first situation is confirmation windows.... The second situation is progress bars.</i><p>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.
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.<p>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...
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.
Considering most progress bars are just approximations anyway, Cancel buttons don't even work half the time.<p>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.
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.)
forms does not have Cancel button! they have reset buttons.<p>big difference.<p>There's no input type=cancel. only input type=reset<p><a href="http://www.w3.org/TR/html401/sgml/dtd.html#InputType" rel="nofollow">http://www.w3.org/TR/html401/sgml/dtd.html#InputType</a><p>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.<p>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.