Re: (no subject)

["Ilan Volow" <raskinite geocities com>]

"Tom Musgrove" <TomM pentstar com>  said:

>The user is generally
> choosing search terms that make sense, but are not the words that the
> content creator used thus they sort through dozens or even hundreds of
pages
> without success


I think that under help searches there should be an option to do an
absolute, basic, brute force word lookup. One thing in Office 2000 that
really bugs me is the fact that there is a word I'm looking for in the help
that M$ does not consider to be a relevant search term,  but is a word that
nonetheless shows up when I try to do an important task. Let's say, for
example, that office 2000 has a "World Domination" feature, and one of the
options for the World Domination feature is called "Armadillo" (hey, it's
not any stupider than a talking paper clip ;) I try searching for Armadillo,
under help, and nothing shows up. Yet there is some help section somewhere
that does mention the Armadillo option. If I look hard enough, I will find
it in the help section, somewhere.  If the search system had an "every match
relevant" option (I'll  think of a better term later on), I would be able
bypass any sort of deficiency in any sort of help algorithm.

> From: Liam Quin <liam holoweb net>
> To: GNOME-Gui <gnome-gui-list gnome org>
> Subject: Re: (no subject)
>
> On Wed, Nov 15, 2000 at 01:17:54PM -0600, Tom Musgrove wrote:
> > That is a good point, sorta like 'stopping and asking for directions'
> > <grin>.
> >

> computer for help is defeat, but asking for a human to help the person
> fight the computer isn't?  How is the request worded?  Or, are they
> asking someone they trust?
>

Maybe the trouble is that we're trying to use words and text when, in at
least some cases, we should be making better use of onscreen objects.
Instead of the user searching for a word that matches the procedure they
want to perform on an object, why don't we let the user interact visually
with the object in question to get the procedure(s) that can be performed on
it. In other words, we could give each type of onscreen object (with a few
exceptions, like menus) its own "help" entry in the contextual menu, and by
selecting that entry, the user would get all the help system entries on that
objects methods and properties. As a simplified example, lets say the user
is using a drawing app and they draw a rectangle. Whoops, they draw the
rectangle too small and they want to resize it, but they don't know how to
perform this procedure. Rather going all the way up the help menu and
selecting any relevant search options and then typing in a GtkEntry "resize,
rectangle" etc, the user could simply right click (or for us lefties, left
click) on the object and they would see the "Help(Rectangle)" entry at the
bottom of the contextual menu (preferably with a seperator right above it to
make it stand out more). The user would click on this, and they would
immediately get a help screen containing links to the methods that can be
performed on the rectangle. You wouldn't have to limit this system to just
the document/data the user creates. You could extend this model even
further, and give buttons, icons, any other part of the program contextual
menu help. This way of getting at an object's relevant help entries is not
only more intuitive than the traditional way, it's also more efficient,
since the contextual menus can be accessed faster than the traditional pull
down menus (in keeping with Fitts' law). I think that the abysmal efficiency
of current help systems as a much responsible for co-worker brain picking as
the current help searching systems. Many people know how to use the current
help system, but it's just soooo slow.

If I've just reinvented someone's wheel, please correct me, so I can start
work on the hovercraft.

--Ilan