Re: encouraging learning by experimentation?

Subject: Re: encouraging learning by experimentation?
From: "Jo Francis Byrd" <jbyrd -at- byrdwrites -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 6 Dec 2002 16:25:29 -0600

We write the user's guides with the bare minimum of information for a
complex application. Then some expert comes along and writes the "Bible" for
said application, explaining all the fine tuning and nuances and makes a

How many of us invest in third party books so we can get a thorough
understanding of the application?

Jo Byrd
(holding up both hands and waving them)

----- Original Message -----
From: "Mike Bradley" <mbradley -at- techpubs -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Friday, December 06, 2002 4:13 PM
Subject: RE: encouraging learning by experimentation?

Has Mike Bradley (quoted below) described something of historic import for
technical writers?

Have we gone through a transition from "documentation that trains" to
"documentation that describes"? Is this an on-going evolution? If we use
"Instruction Manual" as a synonym for "User Manual" are we saying
that the manual contains lists of instructions or that the manual instructs
the user?

In the 1980s, for everything from word processing to electron-beam
lithography tools, I routinely wrote chapters explaining an application's or
system's basic principles and general operations. Sometimes I included
training exercises and even sample files, as well.

In 1991, I drafted the manual for the first release of Adobe Premier, their
video editor. It was just about the first video editor sold to consumers. So
I wrote a chapter on how to develop a good video, with simple advice about
camera shots, pace and so on.

Adobe cut it from the manual and cut all such comments throughout the book.
I was blown away by that.

A big sea change occurred here in Silicon Valley with the introduction of
the IBM PC. Partly, it was simply because we'd been a CP/M and Unix culture,
then a Mac and Unix culture, but we also changed from pioneers and
enthusiasts selling to other pioneers and enthusiasts to businesses selling
to businesses. No time for enjoyment and enthusiasm. Nose to the hard drive,
shoulder to the screen.

Granted, I've written training chapters once or twice since Adobe, but by
and large, it seems manuals focus on documenting tasks and the screen
nowadays, and leave the bigger learnings to the user and his company's
training department.

Who knows? Maybe that's a better model, but it makes writing less enjoyable.

Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from
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

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 for more resources and info.


RE: encouraging learning by experimentation?: From: Mike Bradley

Previous by Author: Re: Description of Tech Writers
Next by Author: slightly OT: making clickbook work
Previous by Thread: RE: encouraging learning by experimentation?
Next by Thread: RE: encouraging learning by experimentation?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads