Re: Printing an incomplete manual

["Kristine J. Olberg" <kjolberg -at- IX -dot- NETCOM -dot- COM>]

----------
> From: Melonie Holliman <mrh -at- ABMDATA -dot- COM>
>
> I am in a quandry. I wondered if anyone else has experienced
> this. I am the only technical writer working for a small
> company producing a database which will be used by mostly
> computer illiterate individuals. Our software is changing
> daily. However, I have been asked to provide a "Limited
> Edition" manual which will be printed soon. The manual
> will be outdated almost as soon as it leaves the office.

My experience with end users who are nontechnical or computer illiterate
tells me that they do not adapt well to change. Typically, the reason they
use the computer is because they have to use it to get their job done. And
when the computer gets in the way of getting that job done, they get
frustrated. Software that changes frequently will frustrate them quickly.
Why is the software changing so rapidly? Is the user interface changing? Is
the functionality changing? Are bugs being fixed?

I'm not a cynic by nature, but this situation spells trouble from the
software perspective. I think your company, not you, has at least one
fundamental problem: a flaw in its development methodology, namely, to
release a product before it's ready. This occurs all too frequently for any
of a number of reasons, including but not limited to: (1) unrealistic
project schedules, (2) incompetent project management, (3) ill-defined
requirements, (4) ignorance or avoidance of sound development
methodologies, (5) naivete of human factors, (6) lack of appropriate
testing cycles, and on and on.

Your challenge is this: change management. You need to be aware of all of
the changes from "release" to "release" so you can document those changes
explicitly for your end users. I would suggest delivering, along with your
help file, a hardcopy  "Summary of changes" document that addresses all of
the changes. This document should be short, not more than a page or two, so
the end user can quickly get a feel for the changes. The reason I would
provide this on hardcopy is because your users are nearly computer
illiterate. (All things being equal in another situation except for
computer-savvy end users, I would put the summary of changes in a readme
1st file or some other online format.)

I would also revise your product documentation using revision bars or
something similar so that readers can quickly see where things have changed
since the previous version. (My pet peeve: if you use revision bars, make
sure they appear on the left side of the page, not in the outside margin. I
think MS Word defaults to outside margin, meaning that the marks are on the
left side of even-numbered pages but on the right side of odd-numbered
pages. This method goes against the reading paradigm for readers of
English: we read across the page starting from the left. Forcing a reader
to focus on the right side of a page causes them to process too much
information. Now, if we read from the outside of the page inward to the
binding, Word's default would be appropriate.)

Good luck. I wish you and your company all of the best in your endeavors.

Regards...Kris
----------------------------------
kris -at- olberg -dot- com
kolberg -at- actamed -dot- com

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html