Re: Striving To Increase The Page Count Was: Estimation of the nu mber of pages...

[David Neeley <dbneeley -at- gmail -dot- com>]

Slipstream upgrades in documentation -- the product is released, but
the downloadable docs are updated -- can often be useful to clarify
those issues that were insufficiently covered originally. If this is
the case, there is no need whatsoever to wait until a new product
release. In fact, it is often advantageous to release the changes as
an upgrade to the docs themselves.

If your marketing department is conscious of this kind of issue (tech
support problems being reflected in updated, improved docs), they
might also contribute by doing mention in newsletters or customer
email regarding the updates to drive more customers to the upgraded
docs for download. This serves a very good marketing purpose, too,
since it puts your company in a favorable light with customers in that
you are continuing to support their needs during the release cycle
itself.

If you have the unfortunate position of having to support multiple doc
versions, the issue is somewhat more complex. Generally, it seems the
most reasonable compromise is to upgrade the docs for the "latest and
greatest" version only -- with the notices of upgraded docs serving as
additional incentive for customers to upgrade. However, even this
general practice may be changed should a major problem develop that
affects prior versions. After all, if they are still subject to tech
support by your firm, you want to reduce that support cost!

Generally, an evolving product will carry forward the prior version
documentation with suitable upgrades to match the changes and
additions in the product itself. Thus, your practice may involve
maintaining the original document with variable text for version
upgrades...or creating an entirely new document from the original with
the modifications incorporated directly. Again, there is substantial
variation in the field.

Of course, if you have a content management system, all of this is
relatively simple to track and the same document base may be used for
all versions, with the CMS creating the final doc depending upon the
version involved. Thus, if you have Documentum or one of its many
competitors, updating prior versions may be simpler than if you're
still doing things manually.

As for document numbers, that depends upon your docs and your
practices. A change list in the docs can and should indicate the areas
or topics that changed, giving customers a fast reference to the
changed material without having to guess. However, the document
version numbers themselves should be reflected throughout as a visible
reminder that changes have, indeed, been made.

Let's say your product is a "version 3.1". Documentation to match may
be done with minor version numbers, as in "documentation version
3.1.0" (for example) to be followed when the docs alone are upgraded
with "documentation version 3.1.1"...

...back to the job search!

David

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

ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!

RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.