Re: "Teaching" wizards?

[Bill Burns <BillDB -at- ILE -dot- COM>]

Geoff writes:

> True enough, but the problem is with the implementation, not with the
> technology itself. Compare, for example, the following two wizards:
>
> To create a new file:
> 1. Open the file menu. [click]
> 2. Select "new" [click]
> 3. Name the file. [type]
>
> and
>
> To create a new file:
> 1. Open the file menu.  [click]
>         Most commands related to files are under the File menu.
> 2. Select "new" [click]
>         See the "^N" beside that menu choice? That's a shortcut, and it
> means you can avoid the whole menu simply by typing Control-N.
> 3. etc.
>
        8<8<8<8<8< snip >8>>8>8>8>8

> Since the goal is to both do and teach, I'd propose calling this a
> "mentor"(TM)...
>
I don't think there's anything wrong with your example, but there may be
better methods to use than wizards. If the goal is to teach rather than to
finish the task for the user, a training card might be more appropriate.
These start the task, but then prompt the user to perfrom each step,
changing the help state align with each action the user performs.

Sure, you can give the user the necessary information to learn a task in a
wizard, but that's not the conceptual aim of a wizard, and many users will
likely overlook the additional information. Show Me links with demos can
also cover more ground than the standard wizard. Obviously, these methods
take more time for the help developer to implement, but if the aim is the
user's internalization of the task, walking them through is a step up from
telling them while the application performs the task for them.


Bill Burns
Senior Technical Writer/Technology Consultant
ILE Communications
billdb -at- ile -dot- com

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=