Designing a knowledgebase?

Subject: Designing a knowledgebase?
From: "Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 29 Mar 2001 08:57:00 -0500

Megan Golding is <<designing a company-wide (technical) knowledgebase... I
work with several technical groups... Each group needs a repository for
documentation they produce for consumption by other groups. I've decided to
merge all of these requirements together into a unified knowledgebase
that'll be hosted on the company's intranet.>>

Sounds like a challenge. You have several different audiences, each with
potentially different needs, and finding a common ground between them--or
identifying workarounds where no such common ground exists--may take some

<<I need a scheme for organization of the documents that make up the
knowledgebase. I've thought about segregating documents by authoring group
(development, systems administrators, etc.) but don't think this is very

Using a group-based hierarchy can be very friendly indeed if the divisions
between groups are clear to users; for example, everyone knows they have to
go to the Fruit site if they're looking for information on apples, and to
the Vegetable site if they're looking for information on peas. But overlaps
or ambiguities can pose serious problems in trying to find things. For
example, are the tomatoes located in the Fruit section (because that's where
your botanists will look for them), or the Vegetable section (because
whatever their botanical status, they go in salads and thus ***must*** be
vegetables <g>)? My entirely non-binary answer is that you should accomodate
both perfectly reasonable assumptions: if the Fruit people are responsible
for creating the tomato docs, then put them in the Fruit section, but
include a link from the Vegetable section.

<<I'm picturing allowing users to "browse" the knowledgebase like they
browse Yahoo -- by category. How should I organize the documents into

First off, you have to decide whether you can actually come up with clear
categories or (as in the case of my tomatoes) figure out a compromise that
makes the information accessible from at least two different places. Talk to
a few users from each group that will be contributing to the site to find
out how they'd organize the information, and look for both similarities (so
you can create a structure that works for everyone) and differences (so you
can create additional structures for those who have different needs). The
joy of online information is that, in theory, it doesn't much matter where
the information is physically stored; you can provide as many different
paths to that information as you're willing to create (e.g,. one table of
contents for each path). Practically speaking, of course, it makes much more
sense to match the hierarchy to the navigation systems you create (so you
know where to find the documents when it's time to update them) and to limit
the number of navigation systems you create (to facilitate maintenance, so
none of the TOCs gradually drift out of synch with the rest of the site).

Second, you'll undoubtedly receive suggestions to add a search engine to
your site, and while that's not a bad idea, I've yet to find a search engine
that does an acceptable job with large or complex knowledge bases. That may
change in a few years, but so far... That being the case, strongly consider
including a proper index: not a word-by-word concordance, which is what
search engines use, but rather a set of links to the documents created
specifically by someone who understands the contents of each document and
can come up with most of the keywords your audience will think of when they
search for that document (i.e., someone with indexing skills). Doing this
manually is a chore, so look into tools such as HTMLIndexer
( to automate the task.

<<a group of about 10 people will be contributing information to this
knowledgebase. I don't want to have to edit and publish their stuff -- these
folks should be able to publish themselves. How would you manage this?>>

Presumably, they already edit and do quality control on their other
documents, and the intranet should be no different. At a minimum, insist on
a reasonable level of quality control provided by the contributors (e.g.,
peer review, editing by their group's editors). It will almost certainly
prove more effective in the long run to develop a style guide for the
intranet and have one or more editors assigned to the task of keeping things
consistent, but you may not be able to achieve this right from the start.
You cannot enforce quality unless someone's willing to do quality control.

<<I was thinking of managing contributors by creating a category called
"drafts" and allowing contributors other than myself to publish only to that
category. This section would include visual cues that the topic(s) is/are
draft-quality, but still allow the information to be searched for, found,
and used. I can review the contents of the "drafts" category regularly and
publish this info to the appropriate final category.>>

It's certainly better than no quality control at all, but intranets can
become exceedingly important tools, and it makes no sense to undermine their
future value by not building in quality from the start. Advocate strongly
for only posting high-quality documents now, so that this becomes your
standard operating procedure in the future. The Internet itself is a fine
example of what happens when anyone can post information with no quality
control; there's an enormous amount of tripe out there, and it overwhelms
the good bits. Don't let the microcosm (your intranet) emulate the macrocosm
(the Internet).

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at

"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein


*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available 4/30/01 at or info -at- devahelp -dot- com

A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.

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 for more resources and info.

Previous by Author: Word and master documents: don't go there!
Next by Author: Websites
Previous by Thread: Re: APPLICATION DEMO
Next by Thread: RE: Designing a knowledgebase?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads