0

I have a web application where we end up at a screen with a form and we have both a CANCEL and BACK button on that screen. My doubts are :

  • Should we clear out the form on pressing the back button?
  • Do we really need the CANCEL button altogether?
  • Do we need to add any checks(for eg A user might have filled half of the form) on CANCEL/BACK buttons?
  • 1
    A little more scenario description will be helpful. – divy3993 Jun 23 '16 at 10:02
  • Whats the purpose of this form? I mean like its for registration, payment process, profile setup form. – divy3993 Jun 23 '16 at 10:04
  • 1
    What does Cancel do? What does Back do? When do these buttons come up? At the end of the form or at the start? – Swapnil Borkar Jun 23 '16 at 10:09
  • We have a create policy screen where we have a form which comes up by clicking a create policy button on the home screen of my web application.So ideally cancel was to just come out to the home screen which was being done by the back functionality as well. – Nirav Chadda Jun 23 '16 at 10:20
  • 1
    Two buttons for the same functionality seems unnecessary. You can simply have a single button called Back or have the X [Close] action to get all the confusion out. – Swapnil Borkar Jun 23 '16 at 10:31
1

The first question is "Do you need either of those buttons?"

"Back" is a universally-available browser control. There is no need to replicate existing browser functionality inside your interface -- at best it'll be redundant, at worst it's a source of confusion (is it going to act exactly like the browser 'back' button, or do something different? does it overwrite the browser history or append to it? There's no way for the user to know without experimenting.) Unless there are particular navigational needs you haven't described here, you probably should remove this button.

The one case where a bespoke "back" button is reasonable is when the user is in the middle of a multi-step process which occurs within the context of a single page -- a stepwise inline popup or modal "wizard" or the like -- and the user needs to be able to move back and forth between the steps of that process without leaving the context of the full-browser page. In this situation, the modal or popup signifies to the user that the "back" button it contains is limited to that context, rather than the full page.

As for "Cancel": based on your description, there are several things that button could be doing. Some are defensible and useful; some are not.

  1. If "Cancel" means "navigate to the previous page", then it is redundant with both back buttons (the browser's and yours) and is misleadingly labeled. Remove it.
  2. If "Cancel" means "reset this one-step form to its default state", then it should be labeled "Reset", not "Cancel". It should be retained only if the form is long and complex enough that resetting it might be useful functionality.
  3. If "Cancel" means "this is step n of a multi-step process, at least one part of which has already been completed, and we're allowing the user to bail out of the entire process and discard any already-submitted data" -- then it's useful and should be kept. In this case, the difference between "back" and "cancel" is clear: "back" will take you to the previous step, "cancel" will abort the entire process.

Should we clear out the form on pressing the back button?

For most interpretations of the word "Back", the form will no longer be visible to the user after the user presses that button -- so there's nothing to clear.

If it is a "step back to a previous step of this multi-step process" back button, then you should not discard the user input: users will expect to be able to move from step to step without loss of data.

Do we need to add any checks (for eg A user might have filled half of the form) on CANCEL/BACK buttons?

Most of the time, you should err on the side of not pestering the user with alerts and messages. But two scenarios in which an alert is appropriate are:

  • It's a long, complex form that would take a significant amount of time for the user to fill in again, if they inadvertently navigate away from it.
  • The site / app interface is such that it's easy for users to accidentally lose track and navigate away from the form. (Facebook is a good example of this: it's easy for a user to start typing out a comment or post, scroll around on the page to look for something else, then click a link to some other page, forgetting they were mid-comment.) This is generally more applicable to plain navigation, less so to explicit "back" / "cancel" / "reset" buttons, because it's harder for users to not realize what they're doing when they're actively clicking a button that tells them what they're doing.
| improve this answer | |
0

In a multi-step-wizard like scenario this would make sense, but if I understand your case correctly and you really only have one step then Cancel would probably be enough.

| improve this answer | |
0

Depends on the function and result of the interaction. If both buttons basically have the same effect, you'll only need one button.

Back means navigating away from your current page, but it doesn't tell the users what happens to their input on the current page.

Cancel clearly communicates that you are about to abort the process, and thus clearing the info you might have entered will be lost.

| improve this answer | |
0

For arguments sake lets say this is a two step wizard and you are on step 2.

Back - goes back to step 1. Retain any values entered on step 2 when going back unless fields on step 2 are reliant on options chosen on step 1 (in which case retain what makes sense on step 2).

Cancel - cancels the entire wizard with a confirmation to confirm cancel. Cancel should be on every step of wizard.

| improve this answer | |
0

On Back button you should navigate to the previous page without any confirmation or any message.....

On Cancel you should just ask for a confirmation and reset the field(clear all fields) so do look for proper validation upon that...

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.