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.
I write lots of manuals for techno-dweebs. Consequently much of what I write
involves "instructions" such as:
- A requires module B in C mode.
- D provides the input for E.
-= stuff deleted =-
glen accardo glen -at- softint -dot- com
Software Interfaces, Inc. (713) 492-0707
Houston, TX 77084
Glen, I write similar types of procedures for field
engineers. They are required to perform operations using the
procedures in a "verbatim compliance" manner -- there is no
allowance for interpretation in the field. If an instruction
step cannot be performed as written, then the operation must
be halted. In order to write in this style, you really need
to put a lot into word choice and structure of the
instructions. You'd be surprised at some of the
misunderstandings that have been caught in the review process
with the most straight forward looking phrases. I find that
usually, less is better. I try to start with the simplest
construction that makes sense to *me*, then I'll add only as
much detail as needed to remove any ambiguity. Sometimes,
though, its easier to do the reverse and start with a block
of description and keep paring at it until all the "fat" is