[Web4lib] "A truly hideous search experience"

[Susan Kane]

As someone who spent five years of her professional life implementing
federated search in libraries -- I have a few thoughts on this problem ...

Federated search is a challenge but in this case, searching is not the
problem.  The results list is the problem.

There are more articles than books.  So if you search "everything" and give
everything equal weight, the results list will be full of newspaper
articles.

This is not the result you want -- and it's not what any good search engine
does.  So unless your federated search vendor has a way to boost some of
your catalog results into the top ten -- you should search books and
articles separately.

I know, I know ... this goes against having one search box, which is what
everyone wants.  But you won't get good results from a single search of
books and articles unless you can hack the results list to weight items by
type.

Google does this (Why is Wikipedia always in the top 10?) and all the major
vendors in the discovery market with a combined catalog + article search do
this.

If you can't hack the results list, you should use a tabbed search box (Find
Books and More on one tab, Find Articles on the other tab) or (Search
Catalog on one tab, Search Articles on the other tab).

Or you can put two search boxes on the main page -- one for "Books and More"
and one for Articles.  But people like tabs at the moment.

And while students won't understand *why* the searches are separated, Find
Books and Find Articles are meaningful phrases that will send people where
they need to go.

(If they ask why and stay around to hear the answer, get their email address
and send them recruitment materials for your favorite library school.)

I see three problems with the popup box you have now.

(1) It interrupts the search experience.  Students these days search first
and think later.  You're asking them to think first and you're doing at a
moment when they expect to see results.  This is frustrating.

(2) It assumes that users will read instructions.  This is not true.  It's
not a moral issue.  It's just not true.  Our task is to design for reality
as it is and users as they are.

If they do read, they will choose Both, and get articles.  That's confusing.

(3) We tend to click on the button to the extreme right (this is usually
Yes, Continue, etc.).  This may be why most of your testers are getting
articles.

Again, confusing.  Esp. since they are searching the library and we are
supposed to have books.

So -- my advice is to (1) make some executive decisions and (2) give
students options on the results screen.

Assuming a tabbed search, you have to make an executive decision for the
most visible search box.  Do most students need the catalog or articles?

Once they see a results screen -- whether articles or books, put some
prominent text for the other search -- "Are you looking for articles?  Click
here"  "Are you looking for books?  Click here" ... then re-run their search
in the other database.

Students will look more closely at their results than they will at a search
box.

A search box these days says "Search me!  Search me!  Search me!"  Few
people can resist this temptation long enough to think about what they are
searching.

In contrast, when results are not as expected, users suddenly become
librarians.  They modify their search terms, re-run searches 15 times, look
all over the page for what they need.  At that point, you hope they see the
"Are you looking for?" text.

Test it, tell us what happens.

As for licensed vs. open content, most people hit the off-campus user with a
proxy server request before displaying the results screen for the article
search.

You can put up text to explain it but most people won't read it.  Add it to
a FAQ for those truly interested.  It's a good time to explain how the
library buys all these great articles for students which can't be found
online.

If you can get the user a bit further, that's also appreciated.  If Google
Scholar really is your federated article search, for example, you can show
the results and wait until they ask for fulltext through your link resolver
before hitting them with authentication.

But I assume that Google Scholar in this case is a placeholder and that it
will be replaced by a results list from vendors that requires auth before
display.

Good luck!  Every library I worked with struggled with these issues. You are
not alone!

Susan Kane
Boston, MA