Re: Future use

[Kathryn Poe <ksmp -at- CYBERRAMP -dot- NET>]

Folks,
I've done software documentation for 4 years and it is always a moving
target but that's the nature of the beast. (That and the way programmers
sometimes look at you as if you came to steal thier soul!)
One thing to add to Matt's comments- I also add a Release Notes page in each
doc stating specifically what is new in this release!  If you give the user
the highlights in plain English they won't be so thrown when they see the
message about "Feature Not Available in Release x.x". Tell them Release X of
this doc contains the following Changes and Updates: You can now input the
blue widget and the green widget is no longer supported.

-Kathryn Poe
Techncial Doc Consultant
Brain for Hire



Matt Craver wrote:

> Marci: Kimberly:
>
> >I am in a very similar situation. I am trying to document a constantly
> changing software product with changing priorities and changing
> schedules.  Does >anyone have any tips for working effectively in this
> situation?
>
> Our product is also constantly evolving, and there is no good way to
> constantly revise documentation to keep up while writing new manuals.
> Carl Bergerson had a good point that, if you can avoid a subject or
> feature, it is best to not mention it. I use "Not Currently Implemented/
> In Use" when this is not possible.  I also make very clear on the front
> of the document which version of the software the document goes with,
> and I give each document a revision number and date it on the cover.  In
> this way, the customer knows that the information is current and
> accurate at a particular level.
> -Matthew Craver,
> Technical Documentation
> Open Solutions Inc.
>