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:Help for a Newbie - response From:Dianne Martin <dianne -at- ACADSOFT -dot- COM> Date:Tue, 13 Aug 1996 09:32:22 CST
-----------------------------------------------------------------------
<snip>
Date: Mon, 12 Aug 1996 11:27:20 -0400
From: Kate Marventano <Kate_Marventano -at- ZD -dot- COM>
Subject: Help for a newbie?
I am curious as to methods you use in the final stages of your
books/material
before handing them off to editors. What techniques do you use for
proofreading, and ensuring that your material is the best it can be
before handing it off?
This is a great post. We all need ways of improving our 'final'
documentation.
I personnally have a multi-step process.
First, I develop the style sheet (within the authoring package -
e.g., MS Word, ForeHelp, PageMaker, etc.). This provides consistancy
of style which is easier on the eye. Then I create the outline
for the documentation. This is the only piece I run by the
developers. I need to make sure that all the features are included.
Second, as I write, I use the tools within my authoring package to
verify consistancy and review spelling/typos and grammar (I am a
notorious passive voice user!).
Third, I pass off chapters to co-workers to review for content and
readability. These co-workers are not writers. Generally, they are
the support team or even the sales team, but never the developers!
(They know too much about the background to help with the
readability.)
Fourth, I re-read the documentation, often out loud (my cats and dogs
love this 'storytime' in the evenings!).
Edits are made along the way. Each step always finds errors or
omissions and improves the contents.
Fifth, I give the manual to the people who edit it. We do not have a
team of editors, so it usually winds up being the Support Manager, or
the Lead Developer.
If pressed for time, I use steps 1, 2 & 3, then off to edit. Of
course, to reduce the load on the people I 'borrow', I give them each
one section of the documentation at a time. I don't want to overload
them and therefore lose their help.
After a short time, you become familiar with your own shortcomings
and can spot the errors before any editing at all. Your writing
improves and so do your docs!
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-