Who is my audience?

[Shorter Rankin <srank -at- PACBELL -dot- NET>]

Anon, a mouse, wrote:

>I work for a large university (40000+ full time students). Over the past
>few years, we have implemented a new computer system. It involves 9
>separate 'modules' which are used in various ways by approximately 4000
>staff. It was designed in-house, and there were no vendors involved.
>
Some of the advice you have been getting today is just terrible.
You should implement MY solution instead <blush>.

1. Talk to management. 'One size fits all' doesn't work in the
docs.
You need more flexibility. You already have part of the solution
because you have classified your users into major groups. As a
minimum you need some documentation which is responsive to the
diverse needs of these groups. If management rejects the idea of
more than one set of docs you finesse the situation be expanding
your definition of what constitutes 'one set.'

Anon, a mouse, wrote:

>I'm now at a point where system changes have stabilized, and I can
>think about redesigning our documentation.

Are you sure about that? Sounds to me like you are describing a
mission-
critical app that 'grew like Topsy' and now suffers from
featureitis
and major instability. The existence of 'many, many e-mail
updates' to the manuals provides evidence that what I say is
true.
If so, you need to classify and simplify and get stability
before you
do anything else. Under no circumstances should you implement a
high-
tech help solution until you have done this. You can and should
put in
a low-tech cost-effective help system which gets you part way to
where you
need to go:

CLASSIFY:
Start with the e-mail doc fixes. You want to know two things:
    a.)Where do they come from?
    b.)What are they about?
Let's say you generate these yourself. (note 1) Seperate the
source
documents into piles and start counting. Look for common
patterns.
Identify those that are truly doc issues, app issues, both. Who
generates them, registration staff, faculty, programmers? Then
you have a better idea of who needs what help on what feature.

SIMPLIFY:
Armed with the foregoing, talk to the developers. You are in the
maintenance - bug fix phase in the software development life
cycle.
I'll bet your app could profit from a bug fix before you expend
major
energy - cost on the docs. A total redesign of the system is not
part
of my solution today, but you might need one. You have a nine
module
system with hugh docs that nobody reads or understands. I think
that's
ridiculous. You get there by allowing rampant sub-opimization
and by
implementing every 'feature' just because the developers can.
Your long-
term solution is to appoint a system owner who has the moxie to
determine
what goes into and what stays out. For now, you want to simplify
whatever
you can simplify easily. With any luck the app stability will
increase some
as you do this.

PROVIDE HELP:
For the purpose of this solution your campus is on some form of
UNIX and
everyone who needs access to a terminal and browser has one. I
would forget
HTML help for the present. I'd go with straight HTML. You need
flexibility
until you can determine where the app needs to go. Straight HTML
provides
this flexibility, can give you a cost-effective short-term
solution, and
if done right can give your diverse groups 'different looks'
depending on
what help they need. Heck, your student assistants could even
assist in the
preparation of HTML pages.

/----------------------/
note 1: your e-mail doc fixes come from you in response to
requests from your users. The alternative is your e-mail
doc fixes come from your users and you just distribute
them. In either case e-mail doc fixes do not work.
They just add more complexity to an already too complex
system. People lose them, forget where they filed them, etc.


Thanks Eric for sending something I could generate an on-topic
message about.


Shorter Rankin
Sacramento, CA

Posts: mailto:techwr-l -at- listserv -dot- okstate -dot- edu
Commands: mailto:listserv -at- listserv -dot- okstate -dot- edu (e.g. SIGNOFF TECHWR-L)
Archives: http://listserv.okstate.edu/archives/techwr-l.html,
	http://www.documentation.com/, or http://www.dejanews.com/
Subjects: JOB:, QUESTION:, SUMMARY:, ANNOUNCE:, or none of these.