TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Your opinion, please! (documentation problem), take II
Subject:Your opinion, please! (documentation problem), take II From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 18 Jun 2003 10:51:14 -0400
Brian Das responded to my comments suggesting that a knowledge base might
not meet the needs of many users: <<I get what you're saying, but you could
argue that the same problems appear in any document -- online help, paper
manual, and so on.>>
The first part of the problem is whether your audience would even consider
using the knowledge base. If I were to pick one word to describe them based
on the situation you described, and thereby do them a gross injustice, that
word would be "flustered". That's not the right type of audience to push
towards a software-based reference solution. These people are knocking down
the doors of your support department because they want someone to hold their
hands until they understand.
If you can't provide this kind of support to everyone (and you said that you
can't), you need to embed the solution in the software--which is why I
suggested a wizard-based approach. There are many alternatives to wizards,
including embedded help or a wholly redesigned user interface, but a wizard
is an easier sell to your product developers and more closely emulates the
solution users are currently seeking: someone (some "thing" in the case of a
wizard) to walk them through the process. That makes for a win-win solution.
The second problem, that of knowledge bases being inherently difficult to
use, is indeed a problem with any document. The solution is to pair a good
indexer with a good information architect to create a usable hierarchy
supported by a kickass index. Given that few companies seem willing to
invest in this kind of effort, I have reservations about recommending it. In
some ways, it's better not to do it at all than to do it badly. Speaking of
which:
<<Are these problems more pronounced in knowledge bases? Are KBs less
accessible than more structured documents?>>
It's not that a KB is inherently worse than the alternatives. The problem
arises when (as you suggested in your original approach) nobody takes
responsibility for planning, managing, and quality controlling the KB. If
everyone has the right to add material, the initial structure is quickly
lost, the quality goes downhill, and the KB becomes unusable. A KB is a
complicated entity that requires strong management if it's going to work at
all, and I'm not convinced you can provide this management while still doing
your regular job. (It's a question of time, not ability.) Remember the
acronym GIGO: garbage in, garbage out.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"Work is of two kinds: first, altering the position of matter at or near the
earth's surface relative to other matter; second, telling other people to do
so. The first is unpleasant and ill-paid; the second is pleasant and highly
paid."--Bertrand Russell
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
