Help systems, was: (no subject)

["Blad, John Erling" <john erling blad aftenposten no>]

>Seriously though, the question would not be
>automatically sent via IRC, one would have the choice if the answer were
>needed immediately or whatever.  Also, the question/answer could be sent to
>email, which might take a lot longer, but would a potential alternative
>route that would save on costs.

>Tom M.

Most of the time the questions are not very unique. Most problems comes from
porly designed navigation systems and a failure to use the same words for
the same things, ie the author of the help system (or whatever
documentation)
uses different words compared to the users. He simply can't find "his"
problem.
If the author of a help system have a list of the different items the
users ask for he usually will see the missunderstandings quite fast.

An example: One website in Norway http://www.ssb.no have statistics about
all aspect of Norway and norwegian life. One such statistics is "Consumer
Price Index" http://www.ssb.no/kpi_en or in norwegian "Konsumprisindeksen".
When people try to find this they usually type in a query for "prisstigning"
or "price increase/growth" ("norwegian") which is exactly what everyone
calls
it. Several releases of the statistics don't use that wording at all. When
searching the wais log at the site it was very easy to spot this.

Just a thought.. Boeing(?) uses a documentation system based upon XML and a
database. If someone needs information about a gadget somewhere in the plane
you can print out complete descriptions for how to get from A to B. If a
help system is built around something similar you can get from "present
state"
to some wanted "future state" by following a generated list of descriptions.
Compared to todays "This is the FOO gadget and it works like this..." I
belive
this will be much more useful because it describes what you *want to do*,
not
what the different parts of an application *can do*.

I'm not sure how inteligent the system is. I belive it needs some guidance.
It is a travelling salesman -like problem. As I recall they includes "close"
parts and stuff like that.

Tried to figure out what this system is called but.. ;/

It is not so difficult to implement as it sounds. It is basically a database
containing a list of which documents referencing which other documents,
a search engine that finds the two endpoints and a egine to fugure out how
to get from A to B (the traveling salsman problem). Close problems can be
represented by links in the list of documents.

John