> Your point is well taken, but we should be
> careful not to elevate very simple or "dumbed
> down" searches to an ideology. The appropriate
> granularity of search and retrieval, represented
> by how articulated indexes are and what search
> functionality is offered to the user, is affected
> by many factors. Among them are the age and
> knowledge of the searcher and the nature and size
> of the database being searched.
Our usability studies would indicate otherwise.
> Taking the size and nature of the database into
> account, for example, it makes perfect sense that
> the LII, which has only tens of thousands of
> metadata records covering a multiplicity of
> subject areas, would often be most effectively
> searched via one keyword anywhere index rather
> than via specific subject, title, etc. indexes.
Actually, LII is very hard to search, and getting harder, and for the same
reason OPACs are hard to search (which has little to do with the number of
records): because our search is limited to metadata. The user has to know to
limit him or herself to a much coarser search than the granularity afforded
by search engines. That has been a growing disconnect between or data and
our users. It's not because the user is stupid. The user is actually pretty
darn smart. The user comes to LII, the little tool, with skills acquired
from much larger tools, and yet can't fjord the gulf of usability. All too
often, our data reveal, there's a heartbreaking disconnect between what
people want and what we offer, even though we often have exactly what
they're looking for.
Note that our plan to replace our search engine (actually-we don't really
have a search engine, just an indexer kabobbled together with other
tools-but that's another story) *won't fix that problem.* It will remediate
it through some very nice capabilities, but it's not the magic bullet.
> However, databases with millions of records, or
> specialized databases with even just hundreds of
> thousands of records, would often be most
> effectively searched by a multiplicity of
> specific indexes, boolean operators, and various
> retrieval filters to increase search granularity.
That's a hypothesis, but it's not evidence-driven.
> Any catalog, whether existing or "next
> generation," should be flexible enough to
> accomodate a range of search and retrieval strategies.
That's true. But any catalog should take into account the majority of user
behavior, and the bulk of effort in system design should be directed at
these users. Over 90% of our users are librarians or library workers
(yes-the same group that had trouble with subject searching; you'd be amazed
what librarians think a subject is, or how many people, getting zero
results, will then NARROW a search), and despite what you'd think, even
they, like most users, use one, two, or three-word queries, with very little
finessing even where finessing is readily available. (Quoted searches are
the most common form of finessing.) Most of them don't use any of the
operators you describe, even though we support them and explain about them
in our help, which we know nobody reads. In a usability test last year,
using a group that included techies, savvy reference librarians, long-time
LII users, etc., the ONLY person who ever once looked at the help, when
stuck or otherwise, was a 25-year-old soccer mom.
Most search engines include elaborate search functions not because people
use them or because they're generally useful but because it's a customer
expectation-and at that, only from people who either have no idea what their
users are doing or (as we do at LII) are careful to cater to perceptions and
to cultivate our "aficionado" community. It's worth our while to cater to
the very tiny slice of users who would appreciate a feature such as an
in-line domain limiter search, because they're vocal and articulate, and
they provide us with information that is very useful to our development. But
they ain't the masses, and I wouldn't trade better relevance ranking for the
ability to do, say, an internal wildcard.
Now, if you want to talk about functionality that helps users-FRBR,
post-coordination faceted navigation, spell-check, best bets, field
weighting, synonym support, and-depending on the data you're working
with-stemming or light pluralization, well, that's another story. But from
talking to search engine specialists and vendors and wading in user data for
the past forever, I'll stand by what I said: start with the data and let it
drive your conclusions.
Karen G. Schneider
kgs_at_bluehighways.com
Received on Thu Jun 08 2006 - 12:21:56 EDT