Re: Discuss: Third party manuals?

[Rose Wilcox <RWILC -at- FAST -dot- DOT -dot- STATE -dot- AZ -dot- US>]

Folks are right about third party manuals filling the need
for ripped off or non-purchased product manuals.

Another thing third party manuals do that we sometimes
can't do is address specific audience needs that either
A) we don't know about or B) that we don't have time to
document.  (Sometimes we're even told to "leave that
out; that's not important".)

In many cases, we don't have the time (or some of us
don't have the skillsets) to write task-oriented manuals
and end up producing references organized in such a
way that the user must understand the program before
using the manual.  Or we try to produce the best task-
oriented manual we can, but we have to rely on mar-
keting, programming, and our own tech-writing staffs
to determine what the user tasks really are.  After the
product hits the market, the users think up new tasks
that we with our human limitations were not able to dream
up.  Third-party software writers can take advantage
of our limitations, based on lack of time and the need
to hit the market early.

The alternative is to hold up the product release until
proper usability testing can be done on both the product
and the documentation.

How many of you are thinking, "Yah, right" at this point?
How many companies really have the luxury of doing
this?  Ideally, we could document everything; realistically,
we document as much as we can
and move on to the next project, perhaps writing a "future list"
of tasks we hope to accomplish in the next release.

In the meantime, technical writers quit their jobs for better ones.
And leave their hopes for the manuals behind, along with
the task of documenting the next release for a new technical
writer who is hard put to learn the system, the tools, the culture
of a new company.  By the time he or she feels comfortable
in the job, the head hunter is on the phone with the next offer
or management has added 5 new products to the line-up,
all which require documentation.

What we *can* do is learn task-oriented writing, advocate for
our user audience, try to get to know our user audience, and work
to improve the status of technical writers so we will: A) get higher
salaries and better benefits as well as a career ladder to keep
tech writers at the same companies longer and B) have enough
tech writers and contract tech writers on staff with training in the
products, etc., at any given time in the release cycle.

What management can do is listen and learn from all this.

******
Rosie (NorthCrowe)
rwilc -at- fast -dot- dot -dot- state -dot- az -dot- us
ncrowe -at- primenet -dot- com
"I know everything.  One has to, to write decently."
Henry James