RE: encouraging learning by experimentation?

["Lisa Wright" <liwright -at- earthlink -dot- net>]

I think when documenting business applications, it's very important to
separate the two concepts of "experimentation" and "error recovery."
Experimentation is an excellent tool for training. But I've worked in
many environments (HR/Payroll, Finance, Legal) where the test/demo
system that is set up for and made accessible to users is never used
outside of the development team. Once they are past training, the users
are focused on getting work done, not on playing around. When they're
trying to get work done, the documentation can't fool around and lead
them down the garden path in an effort to teach them a lesson. As John
said, they want to get something done.

So I focus on encouraging experimentation when I am presenting training.
I also include error recovery. In the documentation I include as much
error recovery information as I can.

I think the lesson to take away from the Hackos seminar is to present
the right information in the right way at the right time. One of the
great ways to do that is to provide the user with ways to get more
information if they want it. Multi-layer help is a great way to do that.
Basic procedures at the first level (for those beginners and advanced
beginners). More in-depth or conceptual topics available if they want to
dig and become more expert.

Lisa 

-----Original Message-----
From: bounce-techwr-l-53104 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-53104 -at- lists -dot- raycomm -dot- com] On Behalf Of Lois
Patterson
Sent: Thursday, December 05, 2002 10:06 AM
To: TECHWR-L
Subject: RE: encouraging learning by experimentation?




--- John Posada <JPosada -at- book -dot- com> wrote:
> >>In practical terms, has anyone tried to encourage experimentation by

> >>users in user docs? How do you approach error recovery?
> 
> Huh?
> 
> My application cost my company about 18 million
> dollars and is charged over
> 200,000.00 per year for support. This is not a toy.
> If you experiment and
> make an error, up to 10,000 error messages could be
> generated on an hourly
> basis until fixed. The nearest anyone gets to
> experimentation is to become a
> developer, and developers are not users.

Clearly, your application falls into the category of
needing to discourage the users from experimentation,
in much the same way that nuclear plant workers would
be discouraged from experimentation (if a little less dramatically). I
was referring more to consumer-level software products, if that wasn't
clear.

I don't recall what application you are working on
now. However, many very expensive CRM and ERP systems
are never adopted by the user base, precisely because
people are too afraid and intimidated to actually use
them. The implementations, costing tens of millions,
are failures. Maybe one solution in these instances is
to have a test system that users can experiment with
in order to become popular with the system.

Lois Patterson


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!

Order RoboHelp X3 in December and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.