Knowledge base design?

Subject: Knowledge base design?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Wed, 29 Sep 2004 10:34:01 -0400


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.



Previous by Author: Action(s) menu?
Next by Author: Gui behavior issue. Need guidelines.
Previous by Thread: RE: Gui behavior issue. Need guidelines.
Next by Thread: Re: Word vs. Frame - Link on in this forum?


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


Sponsored Ads