Full text searches

[Tim Altom <taltom -at- IQUEST -dot- NET>]

Here's a little number from the STC meeting tonight. We had a presentation
on CBT, which led to a discussion about online help, which brought up the
subject of full text searches. Of course, some are for 'em and some are agin
'em. Myself, I'm not a fan of the beasties, despite the new WinHelp 4.0
capability. In my mind, they're more confusing to the new and mid-level user
than they're worth. To an old hand, though, they're priceless. Since I'm
usually writing to the lowest denominator, however, I prefer to keep full
text searches out of the mix.

For those who've never used one, a full text search is literally a scan
through the entire document, that concludes with the help engine listing all
of the topics that contain a search word. And in my mind therein lies the
danger. If you enter a search string of "account" in a help file that
accompanies an accounting package, you'll probably get "hits" on perhaps
three-quarters of the topics. Imagine a newbie picking among those dozens or
hundreds of topics, searching for the right one. Now, a seasoned pro might
use the search string "account, setting up" and get a few topics. But few
users are so sophisticated.

Another thing that bothers me about full text searches is that it gives the
writer a graceless way out of designing a good keyword index, which demands
a good and thoughtful consideration of the user's needs. I put it to one
client this way: imagine a continuum with "total user control" at one end,
and "total designer control" at the other. Now imagine that every decision
you're going to make about design will fall somewhere on that continuum. A
full text search falls at the "user control" end, while no search engine but
a small, tight keyword search falls at or near the other end.

Now, "user empowerment" may sound marvelous, but it has its price. When we
drive a car, many of the things that need doing are done automatically. And
we see few status reports. A 777 pilot, on the other hand, can get ahold of
hundreds of functions, and may have to interpret an equal number of status
readouts. Now, that's user empowerment. Yet if our cars were as complex to
drive, most of us would give up. Give me a machine that controls its own
current and voltage, adjusts its own fuel flow, and has ABS. Somebody is
thinking ahead, designing a car for the way I drive and shielding me from
the incessant flow of superfluous information.

I look at the text search issue the same way. When we empower the user, we
also burden the user. It's a Hobbs choice. I prefer to err on the side of
anticipating the client's needs and trying to take most of the burden on
myself. Still, there were dissents at the meeting, and I'd expect nothing
less here.

Tim Altom
Vice President
Simply Written, Inc.
317.899.5882 (voice)
317.899.5987 (fax)
http://www.iquest.net/simply/simplywritten