TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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
fortune.
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 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.
