Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Scenario: I have a web form split across 3 screens/pages. A user can move between forward and back between the screens via Next and Previous labeled buttons respectively.

Question: When the user presses a previous button, should it act like the history's back button or should it "move forward in history" by navigating to the previous page?

To clarify the second scenario: User A fills out the first two pages of the wizard (History: page 1 > page 2 > page 3). User A hits the previous button to return to page 1 (History: page 1 > page 2 > page 3 > page 2 > page 1). When the user hits the browser's back button, it returns them to page 2 (in this scenario).

I believe that the previous button should act like the history's back button; however, I am seeking confirmation.

share|improve this question
1  
they should function the same –  jberger Feb 27 '12 at 18:53

3 Answers 3

up vote 9 down vote accepted

The Previous button should not act like the Back button. The Previous button means "go to the next-lowest numbered step"; the Back button means "go to the screen you were on before this one". In any given context they may have the same effect or different effects.

So here are two paths the user could take.

Step 1 Next→ Step 2 Next→ Step 3 Previous→ Step 2 Back→ Step 3

Step 1 Next→ Step 2 Next→ Step 3 Previous→ Step 2 Previous→ Step 1

This is how Next and Previous buttons, and Back and Forward buttons, have always worked. Don't change them unless you have a really, really, really good reason.

share|improve this answer
1  
I think this is the correct answer here. Back and Previous are not the same thing, you've illustrated this perfectly. –  JonW Feb 29 '12 at 11:39
    
Changed the accepted answer since this truly is the better answer overall. –  JamesEggers Feb 29 '12 at 15:56
    
THIS THIS THIS! I've gotten very frustrated trying to purchase an item where shipping/billing address was in step 2, and get to step 4 (confirmation) and realize I made a mistake, but the back button erases all the info I put in during step 3 because it called the browser back button! –  aslum Feb 29 '12 at 20:02

Short answer: the previous button should not act as the history's back button (if I understand your term correctly). Next and previous should navigate up and down the numerical sequence of steps.

In scenarios like this, you should generally try maintain consistency in the user's expectation for how the system will work. In the case of a linear series of steps within a wizard, the user will be led to expect that the "next" button navigates to the next step in the sequence, while the "previous" button navigates to the previous step in the sequence, regardless of where the user starts.

share|improve this answer
    
nice answer.... –  mgraph Feb 27 '12 at 21:48
1  
You're right about the Previous and Next buttons. But are you really proposing to change the Back button so it works like the Previous button? –  Bennett McElwee Feb 29 '12 at 3:49
2  
I think I have to disagree with this accepted answer, or at least the phrasing of the first line. Previous is not the same as Back in history, as @BennettMcElwee detailed in his answer. –  JonW Feb 29 '12 at 11:38
1  
In my situation where I have a truly linear process, having a previous button replicate the behavior of the back button would work; however, I'm changing the answer since Bennett's is better in terms of general advice beyond my scenario. –  JamesEggers Feb 29 '12 at 15:56

I understand your idea of the previous button basically doing the same thing as the browser's back button (it makes logical sense from a navigation standpoint), but be careful with how you're handling the programming side of things: if you fill out a form on a page, and then hit the back button, the default behaviour of the browser would be to abandon whatever was filled out on the page that was just left (e.g., filling out Page 3, and hitting back to Page 2, might lose form data from Page 3). It depends how you're implementing the navigation functions of course, but I think a loss of data has a bigger UX impact than any navigation scheme I can think of.

I can imagine a few methods of handling this:

  1. The form is really all one single page, and javascript/css can be used to turn the different steps (page sections) on and off as if they were tabs and finally the whole form is submitted to the server all at once.

  2. Your server saves a record of the referring page and upon hitting previous actually saves whatever data was already filled out (temporarily) so that it isn't lost, and the user can bounce back and forth between steps without frustration (however now the actual back button will behave slightly differently than the previous button in that pressing back will not save temporary data).

  3. Don't use a wizard pattern. I personally find it much easier to navigate, understand, and use a long single page that only requires me moving my scroll-wheel (but I don't know how big your form is as this does have some practical limits). Single page vertical scroll is the easiest possible thing for a user to interact with and should be seriously considered. Practically speaking, the user can navigate sections by touch and without looking, while clicking on button elements requires fine-motor control and precise cursor movement and clicking (which anyone can obviously do, but it is harder than simply scrolling).

Finally, validation is one more consideration. Does validation occur on the client side and at each step (each time a user clicks next) or does it happen only at the very end on the server side? I'd be frustrated if I went through every step of a long form only to discover that something I did way back on step #1 was incorrectly formatted the whole time. I think in this day and age of super fast javascript engines, all forms should provide instant feedback if there's a problem on the client side.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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