Archives for posts with tag: search behaviour

It’s been a long while since we’ve updated this blog, and we have made significant progress in implementing Summon. We even have a name for the service, CityLibrary Search, which trips off the tongue nicely! There is a big milestone looming for us at the moment, the go-live date, which is (currently) the end of August, when we will make Summon the primary search tool via the Library’s home page. More on this when it happens.

In the meantime, I thought I would write about one of the thorniest problems we have been trying to deal with. This is the issue of “known database searching” using Summon. The idea here is that it is sometimes (often?) the case that users are uninterested in performing a full pre-indexed federated search, and instead just wish to get to a specific database. For example law students are likely to want quick access to one or both of the two big legal information databases, Westlaw and Lexis Library. This is borne out by user behaviour: we see a large number of searches for known databases in our current library catalogue, Encore.

Therefore it is important that any discovery service (or indeed library catalogue) can provide quick access to any given named database. Encore does a pretty good job at doing this- see for example this search for Westlaw, where said database comes up top of the list of hits, with a prominent link through to the database itself. Summon is, I would argue, less good on this score. A search for Westlaw comes up with lots of hits. At the top of the list is a “Recommendation”, which is a link through to Westlaw, but in my view the link is not particularly prominent, and it is also not very clear that the link will take you to that database. The rest of the regular Summon hits are, essentially, noise- a variety of articles that happen to mention Westlaw in some context or another, but which certainly won’t provide an authenticated link through to the database itself. Summon does have a “Database Recommender” function, but this seems to be erratic in its operation, for example throwing up irrelevant recommendations.

So, what is to be done? Our current thinking is that we will upload our Millennium LMS Electronic Records Management (ERM) records (a tautology I know!) to Summon, and class these as databases which are “our own” content, which will hopefully push the database records up the hits list. You can see an example of the ERM record for Westlaw in Summon here– the problem is that currently you have to specify the facet “Database” to be able to retrieve the relevant hit, something that few if any users are likely to do. Using ERM records will also allow us to specify alternative names for databases- to use the Westlaw example again, Westlaw does much better when searched for in Summon using its “real” name, Westlaw UK (see hit number two).

Another possible approach (perhaps to be done in tandem with the ERM records approach above) will be that taken by the Queensland University of Technology’s Summon implementation. They have uploaded their Libguides A-Z list as structured XML into Summon’s index as local holdings. This appears to do a good job of creating database links, though they seem to be categorised as “Web resources”, not as databases proper. You can view a presentation on this approach here (requires a Google Drive log-in).

So, the short version: it’s complicated, but pretty vital to get right. We don’t want to try to direct users to Libguides whenever they need access to a database because (as user behaviour stats show) they legitimately expect to be able to access databases via Summon itself. I’ll follow this post up if and when we have found a satisfactory solution.


Neil’s previous post mentioned the idea of trying to provide a ‘Google-style search’ for accessing library resources, something which has been talked about a lot over the last few years. What often isn’t discussed, or not in detail, is what we actually mean by this. Does ‘being like Google’ just mean having a single search box instead making the user choose which type of search they want to perform: Title, Author, ISBN, Subject etc? Or is there more to it?

Aaron Tay’s excellent blog post How is Google different from traditional library OPACs and databases? discusses some of the key issues.

Some of the things that Google does but (most) library catalogues don’t do are:

Auto stemming – that is, a search for ‘run’ will include results for ‘running’ and ‘car’ will also find ‘cars’

Auto correcting – if you search Google for ‘librar opacs’ it will change your search to ‘library opacs’

google search

Soft ‘and’ – occasionally Google might drop one or more of your search terms

Auto complete – it suggests search terms as you are typing

We may not always like the way Google sometimes interprets and alters our searches but it is what most of us are now used to. It can be quite baffling to someone who grew up with Google when their search in the library catalogue for “charles handy new alchemist” does not find the book “The New Alchemists” by Charles Handy.

So how much of this Google-like searching does Summon do? My initial tests indicate it can do some of these things but it doesn’t go nearly as far as Google.

Summon does not auto correct my search terms though it does suggest alternative searches to try. However it only suggests alternative searches if my search finds zero results. My search for ‘Milly Moll Mandy’ sadly neither autocorrected nor offered the alternative search ‘Milly Molly Mandy’, because it found one result that matched my mistake.

It has a good auto complete function – start typing and lots of suggestions are offered.

Summon has at least some stemming ability- my search for ‘charles handy organisation’ happily found alternates ‘organisations’ and ‘organization(s)’.

As far as I can tell it does not attempt a ‘soft AND’ and drop any of my search terms.

Thus far we’ve tried to explain the general idea behind modern resource discovery products like Summon, as well as why we chose Summon here at City. But what benefits does Summon bring to library users, above and beyond the various ways of finding information already available?

The answer to the question above lies in my use of the phrase “various ways of finding information” above. The problem for library users is that, up until recently, there was no way of searching across everything the library provides access to. “Everything the library provides” in this context can include (but is not limited to):

  • The contents of the library catalogue (hard copy books of course, but also potentially all sorts of other media e.g. musical scores, theses, DVDs, LPs, CDs etc. etc.) 
  • Journal articles
  • E-books
  • Abstracting & Indexing databases (e.g. Scopus, Web of Science)
  • The contents of the institutional repository
  • Archives catalogues
  • Databases of newspaper articles

Summon tries to solve this problem by building a single index of the library’s holding, and then crucially allowing library users to search across that index in a single place. So, instead of having to first go to the library catalogue to find books, e-books and e-journals at the title level then (say) Scopus to find individual articles, then (say) to the Archives Catalogue to find relevant archival material, users can run a single search that will find relevant material from all these sources of information.

Furthermore, Summon is set up to provide good results from the prevalent “Google search style”. The idea here is that (for better or worse) users are used to searching Google by plugging in a few key words then hitting go and seeing what comes up, then modifying the search to refine the results. This is certainly the way I search when I use web search engines, at any rate, and studies have shown that this is how the so-called Google Generation goes about things too! Summon’s relevance ranking and the ability to “facet” your search results are crucial here, and we will write more on this at a later date once we’ve had a chance to analyse it further.

So there are in our view two main advantages to Summon:

  1. Search in one place for everything; get useful results back.
  2. Use simple keyword searches as you are used to doing with web search engines; get useful results back.

Of course, in reality it’s arguably not as unproblematic as we have perhaps made things seem. In particular, when we say “search everything”, does Summon really allow us to search “everything”? Or is it actually some sub-set of “everything”? And is simple keyword searching actually the best way of finding scholarly material? And given the simplicity of searching for material using Summon, what then for users’ information literacy? These are all questions that bear further examination, and we will look at them (as well as some other perceived weaknesses with web-scale discovery) in later posts.