Teaching and doing, take III

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA>]

John Gilger observes that when he gets a new piece of software he
<<run[s] through the tutorial if the interface is not *real*
intuitive.  It give me a general idea of how the thing works.  After
that, I pop open the help screens as I need them to figure out what
I'm supposed to do.>>

But that's not the problem we're addressing here. George specifically
stated that we're talking about users who _don't_ want to learn, and
these are the people who will neither open the manual nor read the
tutorial if any other options exist. I do things much the same way
you do, but I also spend a lot of time far away from the software
learning context (e.g., information design methodology), which makes
me atypical of the general user population (but not of the techwr-l
population).

<<IMHO we should keep the tutorials and the help screens separate.  A
good tutorial is essential (at first) then help screens give clear
reminders of what we forgot on didn't learn well. Save the wizards to
automate routine operations.>>

We agree fully on this. Trying to accomplish both goals in a single
method results in a Swiss Army Knife: something that has excellent
flexibility, but that is unexceptional or even sub-par in each of its
individual functions. The problem? Sometimes all you can create is a
Swiss Army Knife, or the only way to reach the user is to adopt an
analogous approach.

--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

When an idea is wanting, a word can always be found to take its place.--Johann Wolfgang von Goethe

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