Re: encouraging learning by experimentation?

[Tom Murrell <trmurrell -at- yahoo -dot- com>]

--- Lois Patterson <skycerulean -at- yahoo -dot- com> wrote:
> 
> This post is partly in response to Tom M., who wanted
> another topic.

(sigh) I suppose that means I have to play, doesn't it? <g> Seriously, it is
heartwarming to see that so many people are interested in keeping me entertained.
I'm touched (or is that teched? [inside American joke]).

> Another topic discussed at the Hackos seminar I
> attended recently (which I mentioned on another
> thread) was encouraging users to learn by
> experimentation. Hackos indicated that user
> documentation should indicate to the user how to
> recover from errors. People learn when they make
> errors. 

I think there is a lot of practical truth in that concept. I think we ONLY learn
when we experience. Reading allows us to acquire information; same for sitting in
lectures or other information exchange activities (with the possible exception of
exchanging emails on listservs <g>). But LEARNING comes from engaging all of the
senses, or as many as possible.

> In practical terms, has anyone tried to encourage
> experimentation by users in user docs? How do you
> approach error recovery?

That said, as a practical matter I can't recall writing anything that would allow
readers to experiment. Procedure writing is giving the reader at least one method to
achieve success. Properly written procedures don't really allow for experimentation,
unless you could Notes, Warnings, and Cautions as opportunities for experiencing the
penalties of straying from the true path. (I swear that some readers have to check
that the Cautions are true. "Caution: Coffee HOT just after it is poured into cup!"
'YEOW!!!' Lesson learned(?) <g>)

And, as John Posada pointed out, there are many situation in which we don't want
users experimenting and making errors. Around here, where we're dealing with small
retail transactions, but a lot of them, errors cost money, and if you cost more than
you're worth, they're apt to let you go learn somewhere else.

> Obviously experimentation is not appropriate for
> nuclear plant workers or some such thing.

No, I suppose not. Such mistakes would only be humorous in the abstract.

I think it's a good idea to look at incorporating real learning into documentation.
Probably that is most appropriate in training documents that will be used in
training environments, which are (I hope) somewhat controlled and somewhat isolated
from the 'real' world.

And thank you for being so concerned about my welfare. <grin>I guess it really IS
about me.</grin>

=====
Tom Murrell
mailto:tmurrell -at- columbus -dot- rr -dot- com
http://home.columbus.rr.com/murrell/index.html Last Updated 10/28/02
--First keep the peace within yourself, then you can also bring peace to others.
Thomas a Kempis (1380 - 1471), 1420--

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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

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!

---
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.