How do you handle the "Cancel" button?

Question

I am currently creating yet another form, and as usual, I am not sure which way to implement the "Cancel" (or "Back") button next to the "Submit" one, that allows the user to forget this form and go back to the listing page.

There are obviously many ways : you can either use a simple button or a link (or any tag with proper onclick and styling, for that matter), and all can use JavaScript to go back in history or simply go to a given url.

Each method has its advantage : the back() button allows to go directly where the user was (on the 3rd page of the list sorted by name, for example), but may pop the "confirm resend" window. On the other hand, going to some url is "cleaner", but means either going to a generic one (1st page of list, default sorting), or keeping the previous url as a hidden parameter, if one wants to go exactly to the same page (3rd page sorted by name).

How do you guys handle this ? I usually use the history.back() solution, because in my case it usually does the trick, but there may be some disadvantages to this method.

Answer 1

Solely using JavaScript for this is a bad solution as it disenfranchises users without JavaScript enabled. JavaScript should always enhance the solution, not be it. (See progressive enhancement).

If the user presses a cancel button your server side script should know where to take them back to. If it was a page that required a form submission you need to rework your site so that it uses redirects after form submissions to prevent the resubmission of forms in these cases. (It's called POST/Redirect/GET).

You then can use JavaScript to enhance this for users with JavaScript turned on to make this faster (like get the contents for the previous page using Ajax and redisplaying it).

Answer 2

For single-stage forms, I'd use a link. You can obtain the URL the user came from using the REFERER header and link 'Cancel' to that page. If the form is multi-stage, on the first stage set a cookie with the referrer URL and use that for the Cancel link.

However, with a multi-stage form you may store partial data in the database. In this case, it's beneficial to use a button, which submits some kind of ID and can delete that data before redirecting back to where the user was. (Although you'd need to delete data periodically anyway in case the user closed their browser.)

As John Conde pointed out, on submission of the form you should use a redirect in order to avoid the POSTDATA problem.

Answer 3

On top of @JohnConde's and DisgruntledGoat's advice (which is sound) I'd suggest showing breadcrumbs or similar to provide a useful 'back link' section (can also be generated server side by the refer(r)er).

It eliminates ambiguity of the purpose of 'back', the user has had a visual clue (usually above the form) of where the system thinks they are (but in practice do not expect them to use the actual links there). POST/Redirect/GET stops the back button breaking, reinforcing this behaviour at all levels.

A competing approach to this design, used on more cavalier sites and those frequented by 'power users', is to empower your users through links (or Ajax widgets) allowing them to manipulate the system and removing the concept of 'back' (although not removing features such as undo).

Bottom line is that you'll (apart from in rare cases) want to either embrace 'back' or remove the need for it. Leaving it in limbo can scare users when it reacts in unpredictable ways.