Library search as ‘search portal’

It’s generally understood now that we need a library search that encompases more than what was in our traditional catalog.

Local index

One way of doing this is indexing more materials in our local search engine. This is the approach taken and promise provided by many ‘next generation’ library search tools. That can be pretty good when it’s possible, but it often isn’t–for external third party databases that we don’t have access to locally index. (This includes both our licensed dbs, and increasingly, third party free internet dbs and tools that are of high utilty to our patrons).


Another option is federated broadcast search.  This too has lots of problems. For reasons both of technology (inc. our metasearch tool and third party db providers) and metadata (lack of coherence between metadata from different systems), the searches provided by federated broadcast search are not very powerful. Users can’t slice and dice the data as they’d like.  Individual databases stop working in the meta-search tool and need individual attention to fix.  Some sources still aren’t metasearchable, for reasons of technology or licensing.

I believe that federated broadcast search is still going to be the best bet for providing a uniform cross-search-capable interface that works accross more of our (dozens or even hundreds) of licensed databases than any other option. But it’s got problems. Even in “next gen” systems like Primo that theoretically let you combine broadcast federated materials and locally indexed materials in one single merged result set–most (all) implementors choose not to, because they don’t want to bring the locally indexed results down the level of the federated broadcast results.


We can fantasize about the type of search interface we’d want. It would include all the sources we’d want, but would still let users limit to just books or just articles[1], or include full text searches (when some sources include full text) or search just metadata only, picking from a wide range of fielded searches combined with full boolean expression power. The relevancy ranking, merging results from different sources, would be fabulous, especially when they chose not to pick a particular field and just search ‘google style’. It would have a quick response time. It would Just Work.

But we don’t have options to give us that, yet. Partially due to technology not yet developed, but even more than that due to lack of cooperation from all our content providers (some of which are free and we don’t even have contracts with) in making this work, licensing from content providers that disallows it, lack of metadata coherence, etc.


So what is our best option?  I’ve been thinking lately that a few top useful search tools should have their results combined in our main search interface, not in a merged result set, but giving separate little search windows for each set of results, not trying to combine them at all.

Here’s one mock up I did of this idea, with our ‘catalog’ (locally indexed) results in the main list, but little side windows showing you the first few results of other tools results, and offering the user a link to see full results from that search tool. This was based on our existing OPAC interface, which I’m not particularly fond of, but the point of this exercise was not to redesign the whole thing, just to see the idea of including extra ‘mini box’ search results.

Mock up of a feasible search portal

That mock up (which is not live or based on real software, it’s just a graphic, and please ignore that ‘not found’ that slipped into my graphic) has our Metalib-powered federated search tool in one side box, and Worldcat results in another side box.

Google Book Search is another obvious candidate–GBS API didn’t exist when I did that mock up a couple months ago.[2] And/Or Internet Archive full text search, if they ever provide one.  After more than a few of these, you wouldn’t neccesarily want them all to be ‘open’ at first, you’d maybe want to provide just a heading with a toggle to expand the first few results.

This seems to me like the best feasible present-day plan to integrating other useful searches into a library provided search portal. Other useful searches include both our licensed content, and the new (and sure to increase in number) third party free tools we have no contract with but which provide some amazing services for scholarly research, like Google Books.

What do you think?

Trying to change user behavior? Nah.

When I explained this sort of idea to a friend who also happens to be a student at my school (does not work at the library), she said “Oh, is part of your goal to get people to come to the library services first, instead of using things like Google?”  Actually, no. My goal is to provide useful services for research that give patrons tools they do not get elsewhere, including integration of library document delivery options etc. I suppose one measure of the success of that would be if more users do start coming to our tools.

But I have no desire to get people to stop using Google Book Search, or Amazon, or anything else. Recognizing that users will be using tools all over the place for their research needs, another part of the program has to be integrating library document delivery services into those external tools too, so when a patron finds an interesting book on Google Book Search, they can easily find out if our library has it (in print or electronically), request it from ILL if not, save the citation to their library-provided reference manager, etc.

This essay is largely about making our library-provided discovery tools ‘reach out’ to the other available tools. But the flip side is getting third-party tools our users use to ‘reach in’ to connect them with library services related to citations they find. I talked more about this in the section on considering a link resolver as an “electronic front door to the library” in another blog post.


[1] In some user interviews we’ve done here, some users have said “please don’t make me search articles and books together, sometimes I just want one or the other.” “please don’t make me include full text searches if I don’t want to.” Etc.  i think this is partially due to users recognizing that when we do try to do this, the resulting systems are awfully creaky.  If we could really have our fantasy system, would they still want this? Who knows.

[2] I believe the GBS API terms of service would allow this sort of thing. i don’t think, based on talking to a Google developer, that Google intends to allow you to merge GBS results with other results in a single result list, but the terms of service are filled with so much legalese it’s hard to be sure.  Those terms of service were clearly written with the javascript single-book-call API in mind, and don’t seem to have been updated for the full search api. I dunno, anyone have an opinion?


6 thoughts on “Library search as ‘search portal’”

  1. UBC takes a neat linking approach called “OneSearch Links”, see here. As the parent of a 3rd year undergraduate with two more children poised to enter university, I don’t think we can underestimate response time in defining a compelling search experience, I am constantly amazed by how often I hear everything the library offers is too slow, especially commercial databases. For better or for worse, google is often closer and faster to our user base than anything we provide. Broadcast searching, in particular, stumbles here, I often wish we could hammer out a common index format among our content and indexing suppliers, and use something like lucene as the basis for bringing together disparate indexes rather than introducing network latency into every interaction.

  2. Response time is definitely a huge issue. That most of our software fails at—even our OPACs that DO have local indexes generally have ridiculously slow response times.

    It’s definitely an issue with broadcast search. I am trying to convince my fellow librarians at my place of work that if a particular resource being searched is so slow that it brings down the response time of the overall broadcast search, it should be dropped from the default search sets–no matter how useful it is. Tell the vendor to make it faster. They aren’t agreeing.

    While the fastest broadcast search is still going to be slower than the fastest local index search, our current broadcast search is far from ‘the fastest’. I think broadcast search can probably be fast enough. Some sources in my broadcast search return in a couple seconds. Others take 10 seconds or more.

  3. We took a local index approach and have included some issues noted in the article.
    We have (as a start) included
    – our local catalog
    – journal holdings e and print
    – Open Access texts wordwide (with geoscientific subjects)
    – some local bibliographies
    – and RSS feed information on contents of current journal issues


    It is Lucene as a technical base.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s