RE: [Doxygen-users] Search engines

[Glenn M. <gle...@vo...>]

Hi Moshe,
=20
I purchased DevaSearch for $99 ( http://www.devahelp.com/). I didn't
need the full blown suite of tools for Dreamweaver.
=20
DevaSearch is not dynamic in that you run it on a set of files and it
remains static until you run it again. However, it is great for my uses:
delivery on CD-ROM and over the intranet.
=20
I don't use the Search that's built into Doxygen. I like the DevaSearch
because I can specify what gets included. My projects have multiple
Doxygen builds and several directories with the HTML output from
FM/Mif2Go.
=20
More important than the Search, I implemented a tool in Perl to create
an index over my set of HTML files. The HTML output from Doxygen is
consistent enough -- particularly with the doxytag references -- where I
can reliably find appropriate anchors to include in the index. I also do
what I call "word-chunking" whereby a code item like "getMosheMovieList"
would have the following index items:
=20
getMosheMovieList
list
   getMosheMovieList
moshe
   getMosheMovieList
movie
   getMosheMovieList
=20
Yes, it does "bloat" the index, but it's online. My index has static
pages [a-z], so they load fast and can be scrolled quickly up and down.
Online users don't complain about too many index entries. (One system I
produce has 16,000.)
=20
The index is actually more useful than the full-text search in the long
run. When dealing with code items, I think that my index is better. With
my homegrown tool, the developer doesn't have to know the exact name of
the code item. If they know that "movie" or "list" is part of the code
item name, they can get there. IME I believe that the FTS provides more
outright misses than hits.
=20
Here's something from Jared Spool ( jar...@ui...) of User
Interface Engineering about search engines and websites:
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--> Users Don't Learn to Search Better

When we watched 30 users trying to search various sites for content they
were interested in, we noticed a peculiar phenomenon:

The more times the users searched, the less likely they were to find
what they wanted.

The data is quite clear on this: On a single search, users found their
content 55% of the time, whereas users who searched twice found their
content only 38% of the time. None of the users in our study who
searched more than twice ever found their target content.

As we mentioned in the last UIEtips, less than 25% of our users searched
more than two times. But those that did persevere did not see positive
results.

The #1 cause of people trying to search more than once is getting a "no
results" message in response to their query. Most users give up when
this happens. However, some try their query a second time.

Here's what happened in our study:

On the first search attempt, 23% of the users got a "no results"
message.

Of those users who kept going, 44% got a "no results" on the second
attempt.

If they still persisted, 50% got a "no results" on the third attempt.

And if they were really persistent, it didn't help because 100% got a
"no results" on the fourth attempt.

Theoretically, as people use the search engine, they should get better
at making it perform. After all, each successive interaction is a
learning moment -- something that is teaching them the idiosyncrasies of
the tool.

But that's not what we've seen. Either users succeed up front, or things
go downhill rapidly.

Encouraging users to continue with helpful hints doesn't actually seem
to help. As we mentioned before, many sites provide hints on the "no
results" pages that try to encourage users to enter different search
terms. Unfortunately, the presence of these hints didn't reduce the odds
that a user would get a "no results" the next time around.

Keep in mind that the way we constructed the study is very telling: We
specifically brought the users to sites that had the content they were
seeking. The fact that one out of every 5 users got a "no results"
message on their first attempt says that there is something
fundamentally wrong here.

The key for designers seems to lie in getting users relevant results on
the first try. The sites that did that were most likely to succeed.

(Erik Ojakaar is in the process of compiling the results of this study
into a nifty, new report on Search. If you found this article
interesting, you'll find the report invaluable. We'll let you know as
soon as it's ready!)

- o - o - o -

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
In other UIEtips, they prove through usability testing that designed
content navigation is more effective than Search at getting the user's
where they need to go.
=20
HTH,
Glenn Maxey
Technical Writer
Voyant Technologies, Inc.
1765 West 121st Avenue
Westminster, CO 80234-2301
Tel. +1 303.223.5164
Fax. +1 303.223.5275
gle...@vo...


=20
=20
 -----Original Message-----
From: Moshe Kruger [mailto:Kr...@Pa...]
Sent: Sunday, December 16, 2001 8:36 AM
To: 'Dox...@li...'
Subject: [Doxygen-users] Search engines



Dear listers,
=20
The native search engine provided with Doxygen requires the installation
of HTTP daemon.
=20
Based on past experience, our developers have rejected this setup as it
makes life particularly difficult for customers configuring applications
requiring an HTTP daemon.
=20
Can you make any other well-informed recommendations? Open Software (if
it's as good as Doxygen :-)) or shareware would be preferable, of
course, but are not an absolute requirement.
=20
TIA,
=20
Moshe Kruger
Technical Communicator
Paradigm Geophysical