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.
John Posada wondered: <<I'm writing and/or updating 15 FM books. I have a
web site where I post a PDF of each book. On a rotating basis, I'll update
and rePDF anywhere from 1 to 4 books every day or every couple of days. The
problems is that telling a distribution of 20 or so people and/or Exchange
distribution lists means that almost everyday, a whole bunch of people are
hearing that such and such documents have been updated...and after awhile,
the notices just become noise.>>
One thing you should consider (from the reader's standpoint) is why the
books are changing so frequently. Use this understanding of their needs as
the basis for a triage approach (essential notifications, useful
notifications, and unnecessary notes):
If the software is being patched on an ongoing basis, and your changes
reflect critical information that users of the software (developers,
in-house testers, etc.) need to know, then notify them as soon as the
updates become available. If you only send out notices of critical updates,
you greatly reduce the amount of "noise" and focus the reader's limited
time/attention on your note.
If the changes reflect the fact that you're building a book from scratch,
and adding new sections as you go, then it's probably safe to simply provide
a link to the documentation (perhaps from within the software under
development?) on the network, and let people open the latest copy whenever
they need to access the docs. You can count on them to open the docs when
they need to, and thus don't need to notify them. Ask them to notify you if
they don't find what they're looking for and you'll also start building a
model of what parts of the documentation are most important to them and
should be worked on as a priority.
Last but not least, if you're simply improving already-adequate and accurate
docs by making them more consistent, editing existing descriptions, applying
a more effective visual design, font fondling, etc., then you probably don't
need to notify anyone at all. Simply send out an initial note that the most
recent versions of the docs will always be available at [describe location
on your network]. Better still, tell them in person as part of your ongoing
maintenance of your relationship with these people.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
(try ghart -at- videotron -dot- ca if you get no response)
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"Work is of two kinds: first, altering the position of matter at or near the
earth's surface relative to other matter; second, telling other people to do
so. The first is unpleasant and ill-paid; the second is pleasant and highly
paid."--Bertrand Russell
ROBOHELP X4 - THE INDUSTRY STANDARD IN HELP AUTHORING
Buy RoboHelp by July 31st and receive a $100 mail-in rebate!
Find out more about RoboHelp X4: http://www.ehelp.com/techwr-l
Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-
---
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.
