Wizard-Style Web UI

I'm creating a Web user interface for an internal application that comprises a sequence of pages that conceptually could be thought of as a wizard. All of the pages apart from the last one have a "Next >" button.

My question is, do you think I should include a "< Previous" button too or should I rely on users knowing about the browser's Back button?

John Topley (www.johntopley.com_
Wednesday, November 26, 2003

Studies show, the reference i can't find, that people
prefer an application previous button to the browser
button.

son of parnas
Wednesday, November 26, 2003

This may be helpful:

"The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory."

http://www.useit.com/alertbox/990530.html

Matthew Lock
Wednesday, November 26, 2003

I'd say include the "previous" button.  For one thing, the user shouldn't have to move their mouse way up to the "back" button when it's already hovering over the "next" button and the "previous" button would be located right next to the "next."  The other reason is that with web apps, unless you explicitly include a "previous" button, the user doesn't know whether it's ok to use the "back" button.  There are enough poorly designed, brittle web apps that take a dive whenever someone uses the browser's navigation features for users to have learned to be wary of doing so.

Matt Latourette
Wednesday, November 26, 2003

Agreed, so many applications with POST style interfaces will break on a back button, so including a previous button sends the message that "this is okay".  You'll have happier end users.

Lou
Wednesday, November 26, 2003

You can include a previous button, but that will not mean people will use it. In our apps we found early on that may users hit the browser's back instinctively, even when they have noticed the presence of an in-page button for that purpose.

So make sure your "wizard" can handle "back" as well.

Just me (Sir to you)
Wednesday, November 26, 2003

Thanks. I'll include a Previous button and check that the Back button works.

John Topley (www.johntopley.com)
Wednesday, November 26, 2003

Let me just say... Back buttons are much much much much much much much harder to deal with than they seem at first. Good luck, it's worth making sure everything is "back button friendly", but don't be surprised if you end up totally screwed by the back button...

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, November 26, 2003

Thanks Brad. It's okay, I'm using Struts and that takes care of everything for you (yeah right!)

I am getting used to considering how a page will be set up if it's arrived at from the page after it, as well as the page before it.

John Topley (www.johntopley.com)
Wednesday, November 26, 2003

just to be slightly redundant and slightly snarky, Jakob Neilsen is dead wrong there:

"Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory."

seriously, that's a crock of baloney. as someone already pointed out, users with half a brain are already trained to tremble in fear at the thought of clicking a back button on anything that isn't an HTML file.

anyone who doesn't have that pavlovian response yet is like those dogs that just sat there and got electrically shocked when they had the option to walk away from the electrical shocker. learned helplessness.

i once had to request a refund on an amazon order because i had naively typed ctrl-n so i could shop around their store in two windows at once. so they processed my order twice, with no indication to me that they had done so. amazon! but i was an idiot to think they weren't idiots :)

pupos
Wednesday, November 26, 2003

If the wizard is more than 3 pages I suggest pouring all the data into session variables.
Ive been doing something simmilar the last week and sessions, slow as they may be is really the smoothest way of dealing with this.
A filled in form should stay filled in untill the user edits it even if he skips 10 steps back in the wizard.

Well, if youve got 10 forms, perhaps it makes more sense to just pour them into the database and just put a flag into session to mark that the form has been submitted once.

Eric DeBois
Wednesday, November 26, 2003

yeh, session scope is the magic bullet. with low traffic no reason you shouldn't do that. anyone have an opinion on what degree of traffic begins to make session vars a bad idea?

personally, i recently ended up saving every page to the database. so when they click on a "next" button it's really a "save and continue" button. i like the simplicity of the save and continue approach, and session scope isn't needed.

pupos
Wednesday, November 26, 2003

I'm using Struts with a session-scope ActionForm, so the fields do stay filled in.

John Topley (www.johntopley.com)
Thursday, November 27, 2003

With wizard or tab like WUI's i use a frameset with javascript array indexed by form element name. I initialize the frames form from this frameset array and upon submit dynamically create a form with hidden elements from this array and then submit via get or post. So you can happily tab around before submitting anything to the server.

Is this very 90's ?

Karel
Friday, November 28, 2003

The technique is fine, although the use of frames to accomplish it is the "90's" aspect you're worried about. :-p

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, November 28, 2003

  Recent Topics

  Fog Creek Home