Knowledge base design?

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

Gayla Bassham is <<...working on launching a knowledge base... the 
technical side is taken care of by our own proprietary applications.>>

You mentioned that you had already found a bunch of existing software. 
Rather than reinventing the wheel, I recommend that you obtain trial 
versions of that software (or at least feature lists) to find out what 
features your proprietary version lacks. Others have invested 
considerable effort refining this field. Why not take advantage of that 
effort?

<<1. Is it better to have a lot of index entries or only a few? (I 
would like to have a lot, but a number of people here want to limit 
index entries pretty strictly).>>

The actual answer is to ignore the quantity per se, and focus on 
providing _the right number_ of index entries. "The right number" means 
that you have covered all the main synonyms people are likely to use 
rather than listing every synonym in Roget's thesaurus. Read up on 
indexing to find out how indexers decide on the optimal number of 
synonyms.

<<2. Are users more likely to use the index search or the hierarchical 
treeview to find an article?>>

Yes. <g> The studies I've seen suggest that the majority go straight to 
the index (sometimes the search function) when they're seeking a 
specific answer, but use the treeview when they're less sure what they 
are seeking and must find that something by browsing until they find 
something that seems familiar. (This consensus also makes considerable 
practical sense, which makes me believe the research.) I use both 
strategies at different times; I avoid the search tool unless I already 
know the keyword the software uses for a term.

<<3. Are there any guidelines for designing the hierarchical treeview?>>

The emerging consensus in the research community is that hierarchies 
should be broad but shallow. This approach minimizes the penalty 
incurred when you follow the wrong branch (i.e., you are less likely to 
get lost deep in a hierarchy and can retrace your steps easily). I 
haven't seen research suggesting that it pays to file certain topics 
under two or more branches of the hierarchy, but it seems reasonable 
that this kind of cross-reference is ideally suited to an online 
solution.

This is one of those situations in which "Miller's magical 7" actually 
applies: This is the well-studied notion that on average, the human 
capacity for working memory ranges from 5 to 9 items, with an average 
at around 7. This is nothing more than a specific number applied to the 
commonsense notion that the fewer things you require people to hold in 
their head simultaneously, the easier it is for them to hold onto those 
things and work with them. The range of 5-9 is not an absolute; it's a 
rule of thumb. Don't apply it blindly.

When you examine a hierarchy at the first level,  reading from left to 
right, you must keep all the options that seem potentially relevant to 
your search in working memory (discarding the ones that are clearly 
irrelevant) until you hit the one you are actually looking for. If you 
don't hit it, you compare the items you're holding in memory to see 
which one is most likely to prove productive. This suggests a hierarchy 
width of ca. 7 topics at the first level. If the topics unequivocally 
don't overlap, you can add more branches at the top because readers 
don't have to hold the irrelevant ones in memory.

Similarly, the depth of the hierarchy should follow the rule of 7, 
though much more loosely: As browsers penetrate deeper into the 
hierarchy, they must keep track of where they've come from in case they 
need to backtrack. Again, you don't want them to have to hold more than 
7 steps in their head at once. You can greatly ease or potentially 
eliminate this cognitive burden by using various visual cues that show 
the path they followed, such as an expanding file tree (like the one 
you see in Windows Explorer) or "breadcrumbs" (Home-->Help-->Knowledge 
base-->Techwr-l).

Keep urgent stuff towards the top and left of the hierarchy: stressed 
out readers in an emergency or any other unpleasant situation want to 
find something fast, and since they start looking at the top left of 
the tree, that's where information likely to be sought in stressful 
circumstances should go.

<<4. Should the same article show up in different spots on the 
treeview? (For example, assuming that I have four or five different 
applications that all print documents, should a generic article on 
printing show up for all of them?)>>

Why not? So long as your applicaton lets the person retrace the path 
they took to reach a topic, the physical location of a topic is 
irrelevant. Multiple classification is a wonderful tool if it's done 
intelligently, with the browser's needs in mind. But don't forget that 
a "generic" article should also include links to more specific 
information for each of the applications.

<<5. Is it useful to have a Getting Started section? What about 
tutorials?>>

Both are useful. No design is so intuitive that people will use it 
without some assistance.

<<What makes this all even more complicated is that I'm also supposed 
to be turning all of our documentation into
single-source at the same time I develop the Knowledge Base.>>

That may not be a bad thing. In principle, the KB will hold much of the 
same information you would be placing into the online and printed 
documentation. That means you should take a large step back and see how 
you could use the KB as the "database" that holds the data that you'll 
use to single-source your documentation.

At a minimum, and given that you're working under a tight deadline, 
plan to create the KB first, then extract information from the KB and 
paste it into your documentation. Then fill in the gaps. Subsequently, 
when time permits, develop something more elegant. Remember: "Cut and 
paste: the original single-sourcing solution!" <g> (You heard it here 
first.)

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


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

ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! http://www.webworks.com/techwr-l 

---
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.