It’s generally understood now that we need a library search that encompases more than what was in our traditional catalog.
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, 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.
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. 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.
 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.