Date: Mon, 13 Nov 2000 09:34:28 -0800 (PST) From: opentrax@email.com To: doc@freebsd.org, bugs@freebsd.org Cc: mwlucas@blackhelicopters.org, jkh@winston.osd.bsdi.com Subject: Wizard, Experts and Guru Systems (Was Re: Any comments?) Message-ID: <200011131734.JAA05859@spammie.svbug.com> In-Reply-To: <7939.972943916@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Oct, Jordan Hubbard wrote:
>> More modern technical support systems usually use a "wizard" that
>> walks you through the troubleshooting process. Half our problem is
>> helping the user define the problem, after all.
>
> Yep!
>
>> Suggested solution:
>>
>> A Web-based "problem tree" that walks the user through to a pointer
>> for the correct information.
>
> Damn, and there I was reading along and thinking "Yes! He's about to
> suggest and volunteer to create an expert system using some inference
> language like CLIPS or PROLOG! Our hero!" and then I saw "Web-based".
> Still, even a web page-based interface using static content would be
> an improvement. :-)
>
I've had this in my inbox for about 2 weeks, trying to make time
for this. A recent PR (doc/22042) has prompted me to get on with this.
Let us for a moment consider the problem as a whole.
There are many problems with customer support, the most common
and least remember by developers is to label the OFF switch.
On one hand the PRs try to take up the slack, but often fall
short with a "Not handled here", "You must be crazy" or
"that's the way it's always worked". All are appropriate.
All get misused, by the reporter, the reviewer or
the maintainer.
To this end, the first question we must ask is:
What is the purpose of this?
I won't bother with the many obvious answers.
Let me just say, each has their reason.
So, how does this all fit together?
Let's consider the first most obvious reason
we all does this. We like working with other people at
least as smart as we are. Sometimes we are even annoyed and
offended when "not smart" people enter the fray.
However, many people would like *some* expertise, but
could live without the pain of learning it all.
So the question is: how to empart knowledge with (or without) pain?
Certainly, we could have a web-based system that does something.
Perhaps a static tree (as suggested) might be an approach.
However, such systems don't fair well durning change.
And *BSD is at-the-current under much change.
If we consider this system for, let's say, setting up
a video monitor to handle X-Windows configuration.
This system would run into multitudes of problems.
In the end, this system might not fair better than
a printed book. Useful, but limited.
On the other hand, a dynamic system such as one
that uses a Database or so-called expert system,
such as Prolog, needs an expert to handle the expert
system.
One system that might fair better is one centered around
a knowledge-base system. The easiest analogy is
to consider AltaVista, Google or AskJeeves.
Knowledge tends to cluster in many forms.
Obvious examples are newsgroup and mailing lists.
However, their biggest problem is Signal-to-Noise.
If, on the other hand, we examine this closely, we can
see that they are clustered via keywords or hashs.
Things like this might suggest using Grep, Awk or Lex,
but they are too general in purpose and at
best can only be tools to solutions.
If we then consider a subject like monitors, then
we could consider solutions. Here is what I mean.
Monitors->MFG->Model
Gem 1702
170?
Diamond AG-1412
DG-8416
Relisys ???
In this example, I choose to break the knowledge
base organization into MFG and Models. However,
I could have just as easily choosen Height-x-Width
followed by dots-per-inch, or modes available
by screen size.
It doesn't matter.
Mfg and vendors use whatever system suites them.
In some case, the paramters make no sense,
intentionally or otherwise. However, all MFGs
do things so they can move merchandise in their
channels. To do this, they must conform to some
standard naming conventions. Those standard-names
get passed along when people write in both
newsgroups and mailing lists.
The question now is how to find what you're
looking for. Again, the paramters to the
problem vary greatly. Wheter someone just wants
to remember a vendor's name, to someone making
a purchasing decsion, to someone trying to
resolve a bad schenario.
Again, the language leads us to the solution.
In this case, we have some order that we
can really use to our advantage.
For instance, FreeBSD has most PRs start at gnats.
After that there is a series of ACKs and NACKs.
The key now is to find/track the resolution
as it fits within the context of the person
asking the question. Again, the knowledge is embedded
in the language, not the actual words themselves.
This might seem a bit confusing, unless we consider
that each message is both part of the question
and part of the answer. That is, in most situations
a question can be turned directly into an answer.
Here is an example:
What color is the wall?
The color of the wall is black.
True many emails babble (like this one), but
they do pertain important information. Perhaps,
this example will spark a light somewhere -
where someone has time. :-)
best regaards,
Jessem.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011131734.JAA05859>