Re: Reprinting a manual before new software version

[Chuck <writer -at- BEST -dot- COM>]

4. do something else entirely.

But before I make that decision final, there's a point missing: has the
software itself changed? If so, why the @#!&%! is your product team
making and releasing changes without incrementing something in the
release number, whether it be X.1, X.01, X.0a, or something to
differentiate, depending on the magnitude of the change? That's what the
point upgrade system is designed for: to show changes that do not
warrant major release number increases. (Note: marketing people *really*
abuse this system, and Microsoft is a leader in this misleading
practice.)

You really *have* to have that differentiation, especially for customer
support. If your company has slightly different versions out there, each
one with only "X.0," and someone calls with a problem, how will a tech
support person *know* what version the problem lies in? And how will the
developers be able to track how the problem was introduced so it can be
fixed?

Most of the time these days, major versions are scheduled so rapidly
that single point versions don't appear as marketing versions (the X.1),
but rather bug fixes are slipstreamed in as X.01, X.0.1, or whatever.
Feature changes are held off utnil the next major release because it's
not that far in the future.

For the smaller point releases, just make the changes, not the version
on the inside title page and the copyright page (but not the outside
cover), and slimstream the manuals with the newer software. If there are
no changes to the way the software works, hold off until the next major
revision to provide a manual update and just re-use what was originally
shipped. Then provide a small addendum for any critical issue.

Darren Barefoot wrote:
>
> Good morning,
>
> Here's today's conundrum: I work for a software development company. In
> December of 1998, we released version x.0 of our product. A newer version
> (x.0 + 1.0) will no doubt be forthcoming some time down the road (at least
> 4-6 months away, I would guess). In the meantime, we are running out of
> manuals and are planning a reprint. However, the manual has been
> significantly updated to reflect functionality changes and generally become
> better. However, it's unlikely my company name it version x.1.
>
> So, new buyers will get new manuals with version x.0 that have different
> (i.e. more accurate and up-to-date) info from existing customers who bought
> version x.0 in the past six months. We're talking maybe a 10-20% change, but
> of course spread out over the entire manual. What should we do to the new
> manuals (besides changing the copyright page) before the reprint to reflect
> this? Options include:
>
> 1. Do nothing. Users who compare old manuals and new manuals can be
> confused.
> 2. Include a one page insert describing the changes, and then hope it gets
> lost so users with the old manuals don't necessarily clue-in that they've
> got out-of-date docs.
> 3. Include "change bars" along the top or sides of new sections, thus
> advertising that the manual has changed.
> 4. Something else entirely.
>
> Any thoughts or comments would be appreciated. Thanks. DB.
>
> ---------------------------
> Darren Barefoot
> Technical Content Developer
> 1-604-904-0822 ext.112
> <mailto: dbarefoot -at- mps-canada -dot- com>
> <http://www.mps.com>
>
> Meridian News!
> Attend a FREE half-day seminar, Build Beyond Your Limitations, to
> receive a preview of the Meridian Project Pack.  For Build Beyond Your
> Limitations seminars in your area, or for more information on our
> products visit our Web site at www.mps.com
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000==

--
"[Programmers] cannot successfully be asked to design for users
because...inevitably, they will make judgments based on the
difficult of coding and not on the user's real needs."
        - Alan Cooper
        "About Face: The Essentials of User Interface Design"

Chuck Martin
writer"at"best.com    www.writeforyou.com


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=