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: Friday Poll Idea (WAS: In love with a word) From:Geoff Lane <geoff -at- gjctech -dot- co -dot- uk> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Mon, 9 Jan 2006 16:37:54 +0000
On Monday, January 9, 2006, Nuckols, Kenneth M wrote;
>> However, when writing for an audience of mixed abilities, it is often
>> good practice to tell your readers how difficult a procedure is. FWIW,
>> I've done this with "spanner ratings" (the more spanners, the more
>> difficult) and with introductory text. Doing this helps readers
>> determine quickly whether specialist experience or resources are
>> required, and so whether to attempt the job themselves or call in
>> specialist help.
>>
>> --
>> Geoff
>>
> I'm going to disagree with Geoff on this. As TWs, our documentation
> should be focused at a particular audience and we should write the
> instructions accordingly. If we have to write a procedure for, let's
> say, replacing the fan blades and bearings in an engine off of a Boeing
> 747 for an audience of holiday travelers, we should simply write the
> procedure in such a way as to best allow a layperson (with the proper
> tools) to complete the task.
> Now, I doubt anyone would ever have to write such an extreme example of
> a task poorly suited to the intended audience as I described above, but
> at some point we need to presume a certain level of education or
> experience for the audience and fit the tasks and procedures to that
> audience.
> In an example like Geoff mentioned, if the task is one of several that
> would likely be reserved for technicians or "specialized" experts, then
> I would lobby to put those procedures in a separate manual (or at least
> an appendix) to avoid bogging the "typical" end user with procedures
> that might require tools, training, and experience beyond what we could
> reasonably expect them to have, as a group.
---
I guess, then, that you haven't written for a publisher of third party
manuals (such as Haynes or Autobook) or, indeed, written for any
mixed-ability audience.
In aviation, only qualified persons are permitted to work on CofA
machines - and so the writer can reasonably assume that level of
skill. However, there are theatres where one publication has to work
for a broad audience spectrum. As TWs, we should focus our
documentation on *our* audience (rather than on the audience we would
like to have) and write our instructions accordingly.
A broad-spectrum audience requires wide focus. For example, when
writing a maintenance manual for a motor vehicle, it is reasonable to
anticipate all skill levels from novice owners to qualified mechanics,
and equipment levels from basic tools to a "state of the art"
workshop. You would expect to find everything in such a manual from a
basic oil change to a full engine refurbish. Some of the operations
(e.g. an oil change) can be done with basic tools and reasonable DIY
skills; some (e.g. injector calibration or fuel-pump metering) require
specialist skills and equipment.
Unfortunately, some people don't read through the instructions before
commencing work. These people might pass the point of no return before
discovering they haven't the skill or equipment to continue. At the
very least, a "spanner rating" at the start of the procedure might
alert the reader to such an issue and if they stop people from ruining
their day, such ratings are worthwhile.
You might lobby to have the "expert procedures" in a separate manual.
However, you probably wouldn't get far if the publisher's standards
demand one book per vehicle (as many do).
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
