[Web4lib] "A truly hideous search experience"

Fri Jan 14 22:24:43 EST 2011

As the designer of fed search software and working for one of the major vendors in this genre, I would suggest much of what Susan did below. Setting up fed search involves a lot of compromises and decisions about what results should be displayed and how, and how that is affected by "for who". Whatever you decide there will be a cost. But decide you must.

I believe it is the results that are the biggest place where work is needed. For my first search, I did not even notice that there was a second tab for the PILOT results! I expected them to be integrated in one list, and scrolled through the whole "articles" list (itself something of a rarity for users :-) before noticing the other tab. If you have to deliver results in one-set-per-tab, then what will the results display be for 25 database Sources? - 26 tabs? or still 2? (one for all databases and one for the books from the catalog). In any case you really need to put some text on the displays pointing out (in those big red letters) that the user has other results to look at - and a single click link to get to them.

Virtually all fed search vendors enable you to limit the number of results from a particular Source. You should use this (judiciously), as Susan suggests, to ensure you get a decent representation from each Source. If you do get to combine results, then you can look at sorting the results according to your own criteria, and/or provide control functions to enable the users to extract the type of material they require (assuming you can classify it - even if only by the type of Source).

Peter

Dr Peter Noerr
CTO, MuseGlobal
+1 415 896 6873 (office)
+1 415 793 6547 (mobile)
http://www.museglobal.com/

> -----Original Message-----
> From: web4lib-bounces at webjunction.org [mailto:web4lib-bounces at webjunction.org] On Behalf Of Susan Kane
> Sent: Friday, January 14, 2011 1:02 PM
> To: web4lib at webjunction.org
> Subject: [Web4lib] "A truly hideous search experience"
> 
> 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
> _______________________________________________
> Web4lib mailing list
> Web4lib at webjunction.org
> http://lists.webjunction.org/web4lib/