The appropriateness of Wizards (not the magical kind)

18 Sep 2009 - 4:14pm
4 years ago
2 replies
458 reads
tdellaringa
2006

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

Comments

21 Sep 2009 - 11:37am
David Lambert
2009

Tom -

Glad you liked the article. In this case, it sounds like you're
looking at the opposite sort of problem -- a blank canvas.

If the users know the object they're configuring well enough to
really be able to grab stuff off a canvas and drop in the correct
place(s), then this paradigm might work really well. It'll give a
knowledgeable user a lot of freedom in how they put pieces together,
which is likely to make them very happy.

I'd watch out for less-knowledgeable users, though, who might have a
"deer in the headlights" reaction to a big, empty canvas.

Finally, I'd recommend you give some thought to how you validate the
configuration as indicated by the user. Do you have enough
information to be able to tell whether the thing they've constructed
is a valid entry? If problems are detected, what's the interaction
that communicates this to the user? Does it happen in real-time (ie,
you can't drop that widget here), or do you wait until they're done
to tell them that the thing they just built won't work (hint: that
won't score too many points w/ users)?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=45800

22 Sep 2009 - 2:21pm
Chauncey Wilson
2007

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 <pixelmech at gmail.com> 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 ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

Syndicate content Get the feed