Re: Welcome, and Net-Docs

[nancy ott <ott -at- ANSOFT -dot- COM>]

> We have recently started looking at ways to develop "independent users"
> who will try to help themselves rather than making phone calls first and
> reading the documentation, if necessary, later. Short of redesigning
> the software or the interface, which in many cases isn't an option, what can
>  be
> done to encourage people to use the stuff? Have any of you embarked on such a
> venture?

> Eric
> ejray -at- okway -dot- okstate -dot- edu

I've encountered this problem, too.  The company I work for develops
electric and magnetic field simulation and signal integrity simulation
software.  Our basic documentation set consists of an installation
guide, a reference manual, and one or more "getting started" tutorials
for setting up problems.  Since our products are fairly complex
(especially the signals product), there's a lot of documentation for
each package -- the reference manuals in particular tend to be very
long.

I've gotten feedback from some of our customers and salespeople about
our manuals being too long and too intimidating -- and therefore not
being used.  On the other hand, I've also gotten feedback from
customer support, other salespeople and customers, and our
international distributors praising the completeness of our
documentation.  So what's a poor writer to do?

Obviously, there's a problem with accessibility, especially of the
reference manuals.  However, I didn't want to "dumb down" the manuals
(as one person suggested) in order to get people to read them.
Instead, I have:

1. Redesigned the manuals to make them smaller and hopefully less
intimidating.

2. Reorganized the reference manuals to eliminate redundancies in
command descriptions and so forth.

3. Developed new documentation -- designed to be used in conjunction
with the basic set -- that's shorter and more accessible to users.
We did a quick command reference for the last two products to be
released, and are currently working on a short sample problems guide
that gives examples of various types of problems and their results.

4. Worked with our software developers to improve the user interface
of new and updated products.  (The documentation group is involved in
product development from the early stages onward.)  We've tried to
make the interface simple enough for people to figure out on their own
without having to call customer support or look up cryptic commands
and messages in the reference manual.

I also plan to do usability testing and implement an on-line help
system, but won't have the time or resources to do either until next
year.

Has anyone out there had any success in actually *solving* this
problem and increasing their readership?  I'm not sure yet how our
changes translate into increased accessibility; they've only been in
place for a few months.

--
-----------------------------------------------------------------
nancy ott      |  The master documents by not-documenting.
               |
ott -at- ansoft -dot- com |                - The Tao of Technical Writing
               |