There is a discussion of Wizard best practices in the out of print book Gui Design Handbook and in the online version at:
http://www.fast-consulting.com/gdhb/gdhb_table.htm Scroll down a bit to find information on wizards. You can find some thoughs on wizards in various pattern collections and user interface guideline documents. Key issues with wizards: Frequency of use - would you want a wizard for a frequent task? Generally no, though if the task is somewhat frequent, but complex and memory deteriorates between sessions because of complexity of an operation, then a wizard might still be useful (if reduces errors and isn't too inefficient). Complexity of the UI - a wizard might be helpful (especially is something is very infrequent), but you might also consider redesigning the UI to be more memorable and less complex. Impact of errors - a wizard can be used to constrain a process to reduce or eliminate possible errors. That was the case for early install/configuration wizards. Memorability - a wizard can be used as a memory aid for infrequent, complex, error prone, UIs. Training/experience - Tax programs are designed for once a year interactions with complex UIs and consequences that could lead to jail or fines. They are also designed to help the great majority of people who are not tax experts. Most tax programs do offer a non-wizard UI for those who are more skilled about taxes. Stress levels - Under stress, you may need some guidance. Those are some of the larger issues that would affect whether a wizard is appropriate. >From what you describe, it doesn't really sound like a wizard would much value unless it is used to create a special object where you need to have some rigid control over the impact of errors or what a user can do in a particular context. Chauncey On Fri, Sep 18, 2009 at 5:14 PM, Tom Dell'Aringa <[email protected]> wrote: > Afternoon, > > I'm developing a UI for a tool we have. I've built a wireframe version that > is kind of dynamic, where you drag and drop things into a central area where > you are configuring something. When you have your configuration built, you > send it off, you can even schedule it or save it for later. > > This is part of an existing piece of software. Currently they do some other > things that are similar using wizards. They want to do this in a wizard as > well. While the processes are similar, they are not the same. > > I feel like the dynamic version I have wireframed is more intuitive than a > procedural wizard. But I'm open to looking at both, I want to do what is > best for the user. So the big question is when is it appropriate to use a > wizard in an interface? > > If anyone has any good resources on that, I'd appreciate it. I did find this > article which is good: > > http://blog.componentoriented.com/2007/10/wizard_ui_dysfunction/ > > But I'd like to do some further research. I want to say I heard somewhere > that a wizard is essentially a lazy way to design, but I cannot locate (or > verify if it is true.) > > Welcome any thoughts. > > Thanks! > > Tom > > -- > Marooned - A Space Opera in the Wrong Key! > http://www.maroonedcomic.com > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... [email protected] > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help > ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [email protected] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
