Re: Re[2]: Welcome, and Net-Docs

[David Hamilton <david -at- URSUS -dot- COM>]

This has actually been an interesting thread, since it shows us
(technical docs folks) something about ourselves.

I had an opportunity to gain a different viewpoint when I managed the
project of upgrading internal technical support operations for a
division of a very large computer company, a few years ago.  There had
been no technical support call tracking mechanism in place before
then.  The data produced by this system was interesting, since it
broke down support calls by workgroup and catagory.

One of the support call catagories was listed (internally) as the
"RTFM catagory".  Tech support folks responded to these calls, in the
format of, "On page x of the xyz manual, it says...".  The workgroup
that had the most support calls falling into this catagory was (you
guessed it) the internal tech docs group.

This became an inside joke, since no matter what degree of hard copy
or online documentation was implemented, we just couldn't get these
folks to look at it before calling for tech support assistance.

For me, this was an educational experience.  For the tech support
group, it was frustrating.  It was additionally interesting because I
did some work with that same docs group, and heard them bitch about
how the users never read their docs.  Of course, this might have been
an isolated incident, but I learned from it.

By the way, the single most important factor for online docs with
respect to reducing support calls, was the implementation of a system
that extended the hyper-links to allow the execution of programs from
the online docs system.  A user could read the description of a
particular applications package, the caveats, and the charge-out info,
and select a "hot button" that would cause that package to be
installed (for example).  This had a major impact on support calls for
routine matters.

With respect to the problems of users who do not save the information
regarding list maintenance funcions, and instead send messages to the
full mailing list, I see this as a failure of the mailer tools.  So
much else in the typical user's environment is handled by the
selection of a button or other GUI element.  Why is this function
different?  There is a predictable formula for handling maintenance
functions on mailing lists.  The mailing list databases are published.
So why do the "subscribe" and "unsubscribe" buttons on the popular
mail handling programs not handle the appropriate messages.  It seems
to be such a simple matter to resolve, yet it remains a continuing
problem for every mailing list.

This is a problem that can easily be handled by technology.  There is
no reason why the individual users must learn diverse systems to
implement their intentions.  It is almost trivial to provide the
capability of scrolling through online lists of available mailing
lists, selecting one (or more) of them, and tying them into the local
mail handler agent programs.  A "subscribe" or "unsubscribe" button
hit should function the same way for mailing lists as it does for
USENET mews groups.  There is no prohibitive technology involved - it
is only a matter of a few standards.

In my opinion, the more that can be handled in the user interface -
the less that remains to be handled by published documentation.

-dh
_____________________________________________________________________
David Hamilton                                        david -at- ursus -dot- com