-1

I have a web form with multiple steps/pages (I'm using django-formwizard) that is dependent on POST requests like the typical web form. If the user presses the back button, things break.

I in this Stackoverflow post that you can stop the default behavior of the back button while it's on your own domain before it unloads the page.

I am thinking about, if the form step is greater than 1, I assume the user is trying to go back to step 1. Therefor, I ask the user to confirm, telling them of the great sin they're about to commit.

If they say yes, call a GET request to the form with step 1 (which would undo all of their input as a side effect. I would tell them about this in the confirmation).

If they say no, I would block the event they were just trying to do (go back) and stay on the current page (my form at the current step).

Is this a good idea?

I do have a "previous" and "first step" button.

This form is more of an event registration with 4 steps, all of which are self contained (you shouldn't need context of previous steps) and those that I think may possibly need it have that information displayed on the appropriate steps' pages.

Ian Kirkpatrick
  • 1,861
  • 14
  • 33

1 Answers1

0

It may be necessary to allow a user to go back and forth between pages/tabs in an interface where you're gathering information that's to voluminous to grab on one screen. A classic example is demographic information on a registration screen (name and address on one screen, security questions on another, next-of-kin on another).

In this case, going back one screen isn't a "sin"--it could be a UI requirement. I do this all the time. I have to retain the information from screen-to-screen and allow the user to review it to make sure it's correct. Not allowing to to go back and review/correct would be a questionable design decision. Altering the behavior of your UI in this case could be confusing to them.

Just something to think about as you go along :-)

markaaronky
  • 1,231
  • 12
  • 29