This is what I tend to think of as the "library search" problem as
opposed to the "catalog search" problem. User comes to the library home
page, quite possibly ignores text and labels, and enters search into the
first search box found. They often search for content like books and
journals but also very often search for things like facilities,
services, staff, tools, equipment, etc.
If they do happen to be looking for content they often don't know which
of our silos to go to. Charley mentioned our Quick Search app at NCSU.
As much as it is a discovery tool it also plays a role in stealth
instruction, trying to show our users how our content is organized into
silos and hopefully helping get them to the right silo. Of course there
is that one rather largish silo rather vaguely called the "catalog" that
includes a wide mix of things. It's hard to explain to the user what
that is especially if we can't talk to them and if they won't read
instructions. To promote this particular silo there is the Quick Search
catalog widget, which include three components mostly focused on stealth
instruction:
1) the first three catalog results (for taste and scent--and maybe
immediate gratification),
2) a hit count for five major formats (to explain what kinds of things
the catalog holds and how many of those things relate to the search), and
3) a link to full results to give an overall sense if search success in
that silo and provide an opportunity to go in and use the added value
features of the dedicated catalog interface.
Space in the Quick Search results page is very tightly managed and
prioritized within eye track geography and so that is all that is shown
for the catalog (which pulls in 24.5% of Quick Search clicks). Like
with some of the other widgets, this is perhaps more about acquainting
the user with the silo than delivering results.
So there's all these silos that have been hooked up (catalog, web index,
ERM, FAQ database, staff directory, etc.) but there are certain user
queries that occur so frequently that they can be given special handling
right off the top. In Quick Search this is addressed by about fifty
Best Bets handled through a separate special index. The top 15 clicked
Best Bets include things like article databases ("Web of Science"),
tools ("Citation Builder"), content domains ("GIS"), services
("E-Reserves"), and facilities ("Digital Media Lab"). Best Bets can
serve as minor leagues for future home page links (overall Best Bets
click share in Quick Search fell from 31% to 21% last year, largely as a
result of two of the most commonly clicked Best Bets being promoted to
the home page). Best Bets as well as "landing pages" seeded into the
web index can also help disambiguate when a particular query can have
many different contexts (e.g. ETD seekers vs. creators).
As for Web pages results in Quick Search, though they take up a lot of
space most everything past the first two results is throwaway, both in
the sense of low click rate and in the sense of inhabiting lower value
space in the eye track geography. The first two results make up 76%
percent of web page result clicks (web results as a whole make up 28% of
Quick Search clicks).
Steve
John Little wrote:
> Hey: I spent the morning catching up on email. I just started reading this
> (and haven't finished) but I realized we've had a similar discussion where I
> was calling "one box technology" by another term, "integration." Anyway,
> you may be interested in the thread. I'm going to finish reading it now.
>
>
>
> ---------- Forwarded message ----------
> From: Eric Lease Morgan <emorgan_at_nd.edu>
> Date: Fri, May 2, 2008 at 4:06 PM
> Subject: [NGC4LIB] google onebox, "next generation" library catalogs, and
> interpreting queries
> To: NGC4LIB_at_listserv.nd.edu
>
>
> I have been thinking about Google Onebox technology, "next
> generation" library catalogs, and interpreting user queries.
> Specifically, I think the techniques behind Google Onebox technology
> could easily be implemented in "next generation" library catalogs.
>
> Google Onebox [1, 2] is a technique for providing enhanced services
> against a locally implemented Google Appliance. It is also
> implemented against the Google index itself. Through the Onebox
> technique, Google looks at the shapes of queries and passes them off
> to other, outside search engines combining the results with typical
> index results. Many queries have particular patterns. Many of these
> are defined by Google itself. [3] I have begun creating a Onebox for
> our local Google Appliance. Enter a couple of words. By default it
> searches the local personnel (LDAP) directory, and if a match is
> found it returns a name, email address, and telephone number. If
> nothing is found, then no harm done.
>
> Similar things could be done against library-related indexes. Does
> the query look like an ISBN number? Do in ISBN number search. Does
> the query fit a name in your authority list? Return an authority
> record. Does the query look like a citation? Find the article. Is
> there a comma between the first and second word, then consider
> changing the query on the fly to an author search.
>
> The power of this technique is two-fold. One, it does not necessitate
> the inclusion of all your content in a single index, although that is
> something I advocate. Two, the technique allows you to bring back
> answers instead of pointers to answers. Instead of bringing you back
> a HTML page that night contain the email address and telephone
> number, it returns those things directly.
>
> In short, I think we should consider looking at the shapes of queries
> before blindly sending them off to our indexes for searching. Instead
> we can (should) look at the queries first, combine what we see with
> our professional judgment, and possibly enhance or redirect the query
> accordingly.
>
> [1] Google Onebox design principles - http://tinyurl.com/4nvahr
> [2] Google Onebox developer's guide - http://tinyurl.com/2w2qkr
> [3] Cool Google queries - http://tinyurl.com/9k4nd
>
> --
> Eric Lease Morgan
> University of Notre Dame
>
>
>
> --
> John.Little_at_Duke.edu
> ILS Support Section Head
> Duke University Libraries
> 919.660-5932
>
--
Steve Morris
Head of Digital Library Initiatives
North Carolina State University Libraries
Phone: (919) 515-1361 Fax: (919) 515-3031
Steven_Morris_at_ncsu.edu
Received on Thu May 22 2008 - 10:40:11 EDT