Users editing help files?

[Geoff Hart <ghart -at- videotron -dot- ca>]

Evelyn Dunn wondered: <<My manager has received a request to let some 
of our users add policy  information to existing Help topics. While I 
am willing to add this  information, the group in question does not 
want to take this approach.>>

The question that should always be asked when advocating changes to a 
system that works well is the following: What problem are we trying to 
solve? The inability to answer that question tells you the idea is 
ill-considered. The ability to answer it clearly and objectively will 
often tell you what needs to be done to solve the problem, or at least 
focus your attention on the right problem.

<<We treat our Help files as production data and the files are 
currently  locked down. I have suggested that they use hyperlinks but 
they insist they want to embed the information.>>

To me, this sounds like a recipe for disaster. You quickly end up with 
the Wikipedia problem (lots of information of dubious quality added to 
a core of sound information). It might be very useful to link the help 
system to a wiki of some sort so that you accomplish both goals: your 
goal (that the core Help is sound, objective, and high quality), but 
and the goal of those who requested authoring rights (i.e., the wiki 
provides an immediate way for these people to add content). 
Subsequently, you and your team can take the best of the wiki content 
and add it to future generations of the help, while ignoring the 
useless stuff that gets wiki'ed.

Moreover, if nobody is responsible for quality assurance of the 
additions, there's no way to find out why the changes are being 
suggested. Simply making a change without thinking about why is at best 
a way to accumulate subjectively useful clutter that may be irrelevant 
or actively harmful to many users of the information if the author 
misunderstood something. It can also miss out on a great opportunity to 
understand the reasons behind the addition; understanding these reasons 
can sometimes reveal serious flaws in an existing process, or 
opportunities to greatly improve an adequate but not stellar process.

<<The department in  question has a high turnover, they would not be 
training their users on our Help system, and few of them have good html 
skills, not to mention  they know nothing of technical writing.>>

This also raises a large red warning flag. Among other things, people 
who have no investment in the future of the system have little reason 
to be careful in emending it since their goal is solely to satisfy 
their short-term needs, irrespective of anyone else's needs.

On the other hand, the "high turnover" suggests a wonderful 
opportunity: the things these people propose adding may give you strong 
clues to ways that your help system is failing neophyte users. Pay 
attention to their suggestions and you may find a way to usefully 
reinvent your help system so as to improve its effectiveness for this 
audience.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --
Geoff Hart   ghart -at- videotron -dot- ca
(try geoffhart -at- mac -dot- com if you don't get a reply)
www.geoff-hart.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Try WebWorks ePublisher Pro for Word today! Smooth migration of legacy
RoboHelp content into your new Help systems. EContent Magazine Decision-
maker review (October 2005) is here: http://www.webworks.com/techwr-l

Doc-To-Help 2005 converts RoboHelp files with one click. Author with Word or any HTML editor. Visit our site to see a conversion demo movie and learn more. http://www.componentone.com/TECHWRL/DocToHelp2005

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.