Adding new content to a recently released document?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Christine Gonzales wonders: <<How do you communicate revisions to a
document? Do you just make the change, or create a new revised document or,
send an e-mail that says "there are changes to this document..." For
example, I created a document on some new features to a tool that was
already being used in house. 3 weeks later, there are some "do this if this
and do that if this" on the new feature that were communicated via e-mail,
and should be added to the document.>>

It's obviously impractical to print and distribute a new version of the
entire manual every few weeks, and anecdotal evidence (repeated discussions
on techwr-l) suggests that sending change pages (i.e., "please insert this
page between pages 23 and 24 of your manual"*) is an exercise in futility,
since nobody inserts the change pages. This suggests some form of online
information should do the job nicely. If the software is distributed on a
CD, the updated manuals could easily be shipped on the same CD. The ideal
situation is to integrate the changes into the context-sensitive online
help, so nobody ever has to go looking for them or wonder whether the
changes are there: when you need the information, it's already there in the
Help file. You can use the same approach if the manuals are used solely
in-house, but in this case, rather than distributing them on a CD, you might
be able to make them available on your intranet (or in a special network
directory for those who don't have a formal intranet).

* Just checking to see if anyone is really paying attention. We now return
to your regularly scheduled message...

Of course, you may also need to alert users to important changes. ("Remember
the red button we told you to press? That button now deletes your file and
fries your computer. Please use the green button instead. And too bad if you
don't read online help files--that'll teach you to respect our work!") In
that case, you need a prominent link to changes in the table of contents and
other likely locations. For example, for changes that affect procedures
users are likely to reach directly, without ever seeing the table of
contents, the changes must be visible at the start of the appropriate
topics.

<<Of course, there are those that like hard-copy and will print a copy and
never bother going back the Intranet for the latest one, but I can't help
them.>>

Alas, you can't help them. Much though we discuss our responsibilty to the
user, it's important to remember that we can't do much more than make
information readily available and easy to use. They're the ones who have to
decide to use it.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

"I vowed [that] if I complained about things more than three times, I had to
do something about it."--Jon Shear

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

A landmark hotel, one of America's most beautiful cities, and 
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.  http://ieeepcs.org/2001/

---
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.