We’ve made Summon (branded as CityLibrary Search) our primary discovery route via the Library’s homepage, which I suppose is as near as we’ll get to a formal launch of Summon 2.0, so here’s to it!
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.
I’m pleased to announce that we have opened up our installation of Summon here at City to public beta testing. If you want to have a look at our install you can do so here:
http://city.summon.serialssolutions.com/
Please bear in mind that we’re still very much at the testing stage, so things are likely to change, and we can’t guarantee the service will always be online (though we’re confident it’s pretty stable!) If you have any feedback, we’d love to hear from you: please email summon@city.ac.uk
The next announcement we make is likely to be the name we have come up with for the service, watch this space for that exciting piece of news!
As part of our Summon implementation we will be changing link resolver from WebBridge to 360 Link. 360 Link is another Serials Solutions product and uses the same knowledge base as Summon so we hope that it will give better integration with Summon than WebBridge would.
What does a link resolver actually do? The primary function of a link resolver is to provide a quick and easy way to link a user from a citation to an ‘appropriate copy’ of the article they want to read. ‘Appropriate copy’ in this instance basically means a copy that the user will be able to access for free. For City University staff and students this means articles published in e-journals that City University Library subscribes to.
We have been using WebBridge as our link resolver for nearly 7 years so changing to 360 Link gives us a chance to think about the functionality and branding of our link resolver and decide if we want to make any changes. Out-of-the-box, 360 Link is fully functional and it already has the City University branding applied.
This looks ok but we felt we could improve 360 Link with a few simple changes. The screen is very busy. 99.9%* of the time the only thing a user wants to do when they land on a link resolver page is get to a copy of the article they want to read. The user should not have to think about how to do this. In the screenshot above, there are no less than 17 different links the user could click on (not including links in the header and footer), only 4 of which will take them to the article. The whole of the top half of the screen is taken up with citation information.
Below is a screenshot of 360 Link now. The key changes we made were:
- The citation information now displays in a brief format so it doesn’t take up so much of the screen.
- Databases are de-duplicated so that instead of seeing multiple links to, for example, different Ebsco databases only one link to an Ebsco database will display.
- Content links have been re-designed and re-ordered. The ‘Article’ link is now a prominent red button, designed to draw the eye. All the links ‘article’, ‘journal’ and ‘database’ still work but it is visually clearer that the most important link is the Article one.
- Extra links have been removed to make the page less busy and we have tried to use natural language where possible.
- We have turned on 1-click linking which means when you click on a 360 Link (in Summon, Google Scholar or any other database) you go straight to the article instead of to the 360 Link page, so linking to full text is even easier. 1-click linking also gives the option to go to the 360 Link page in case the article link fails.
We’ll be making the move from WebBridge to 360 Link over the next few weeks and hope it will give a better user experience.
* Made up statistic alert
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’
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:
- Search in one place for everything; get useful results back.
- 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.
Lucy’s previous post gave the background as to why we and other academic library people think resource discovery tools are potentially useful tools for library users. This post reflects on the decision-making process that led us to choose Summon over other available products.
The first thing to say about the process is that it was hard, particularly in negotiating the politics that often come into play when proposing any relatively major change in systems! There was a feeling amongst library managerial staff that a resource discovery tool would in principle be useful and cost-effective, but that feeling was by no means a general one. Some members of library staff (and particularly subject specialists) had quite legitimate concerns about the coverage of discovery tools in general, and of Summon in particular. Discovery tools do well for coverage of STEM subjects, but (arguably) less well with Arts, Humanities and Social Sciences, and there are a few subjects (notably law, a significant area of study here at City) which have gaps in coverage. I won’t write more about these issues at the moment,but they are ones we will return to in future posts.
Once we had decided that we wanted a resource discovery tool, the next question was, which one? We decided to limit the scope of the procurement decision-making process to the current generation of discovery tools (new tools are on the horizon already) which for practical purposes meant choosing between Summon, Primo and EBSCO Discovery Service (EDS).
We started off by visiting a number of institutions (LSE, Middlesex, Brunel) who have recently implemented discovery tools, not so much to see the tools in action (though that was of course interesting) but to get an idea of how they decided between the tools they considered and to find out how they managed the procurement and implementation processes. These visits were invaluable, not least to reassure ourselves that a lot of the issues we were considering were not unique to us. Running parallel to this, we invited each supplier in to present on their product, also inviting a number of colleagues to these demonstrations. This gave us an idea of the functionality and relative strengths and weaknesses of the products.
After the demonstrations, we invited colleagues to vote on their preferred option. We offered the following options:
- I prefer Primo
- I prefer Summon
- I prefer EDS
- I think we should get a discovery tool, but I have no clear preference
- I don’t think we should get a discovery tool
We also invited feedback on the various products and on the reasons for or against getting a discovery tool. The results of this exercise saw a clear majority in favour of getting a discovery tool, but no overwhelming majority in favour of any particular product (though for the record Summon did get most votes).
The final stage of the process was to do a detailed analysis of the functionality of each product, as well as other important factors such as cost and fit with current systems. The result of this analysis (as you might be able to guess) was that Summon was the preferred choice. We felt that Summon and Primo offered pretty similar functionality, but that Summon was clearly a better fit with our current systems (we use Serials Solutions’ knowledge base 360 Core) as well as being priced lower than Primo. We felt that EDS did certain things well (not least exposing EBSCO’s own large dataset of publications), but that it didn’t offer true pre-indexed federated search. We then took a paper to the Library Executive team, who passed the paper.
So now all we have to do is implement Summon!
The library has recently chosen to implement the Summon web-scale discovery service. In this first blog I’ll talk about what Summon is and a bit of the history behind its creation.
One of the problems libraries have been trying to solve for some time is how to make it easier for their users to find information. A university library will usually subscribe to a large number of web based resources including reference databases, abstract and indexing resources, journal bundles and individual e-journals and ebooks. This provides library members with an enormous wealth of information but the sheer number of resources can make the task of finding information incredibly confusing. Where do they start looking?
The first technology created to try and solve this problem was federated (or broadcast) search. A federated search builds connectors to each individual database the library subscribes to and will simultaneously search every database and return results. In theory this sounded great, exactly what we needed. Unfortunately the reality of federated search products did not live up to expectations. Problems with federated searching are well documented. These include slow response times from databases; lack of relevancy of results; clunky interfaces; results are not interfiled, so to view results from all databases search you need to scroll through several pages; the need for constant maintenance to fix broken connectors- I could go on.
In 2009 Serials Solutions decided to try a different approach to this problem and started work on Summon. Instead of using broadcast search to send your search to multiple different databases then try to make sense of the results returned, they decided to pre-index as much information as they could and build one huge central index containing fully indexed articles, abstracts, ebooks etc. This approach has a number of advantages. Searching is much faster. It allows for much better relevance ranking. Summon knows what subscriptions your library has so it can return only results which will result in the full text.
Does Summon deliver on this promise? It certainly has some enthusiastic supporters. We will soon be able to put it to the test.
Summon at City University London 