rusq: Vol. 53 Issue 4: p. 291
A Hybrid Approach to Discovery Services: Reflections on Implementing both Primo and Summon
Eric Phetteplace, Jeremy Darrington

Jeremy Darrington is Politics Librarian, Princeton University Library, Princeton, New Jersey
Correspondence: Correspondence concerning this column should be addressed to Eric Phetteplace, Emerging Technologies Librarian, Chesapeake College, 1000 College Circle, Wye Mills, MD 26179; email:

Web-scale discovery is a vexing issue for contemporary libraries. Everybody is doing it differently and no one seems satisfied. For all the various conference presentations and journal articles, it can still be difficult to find takeaways that will suit your own library. Jeremy Darrington’s column is unique in that it not only catalogs Princeton’s unique experiences and offers broadly applicable advice on implementing a discovery layer. Whether your library has already chosen a product or is still debating whether any of them are worth it, I hope this piece assists you in managing change.—Editor

Over the last few years, changing user expectations and new technologies have led libraries to rethink their approach to helping users more easily discover the breadth of print and electronic resources offered by the library. As a central component of this rethinking, many libraries have chosen to subscribe to one of the new web-scale discovery services provided by various library vendors. These services are designed to search “quickly and seamlessly across a vast range of local and remote preharvested and indexed content, providing relevancy-ranked results.”1 Princeton University Library (PUL) has also chosen to go this route but with a twist: we have adopted a hybrid combination of Ex Libris’s Primo and ProQuest’s Summon services. As a member of PUL’s Discovery Implementation Group (LDIG) and Website Steering Group, I have been involved with this effort for more than three years. I believe our experience can prove helpful to other libraries implementing a discovery service.


In February 2010, PUL convened a Library Discovery Assessment Group to assess the landscape of these new discovery systems and recommend whether the library should adopt one. Ultimately, the group recommended adopting Primo, primarily because it felt that Primo offered the best option for updating our aging catalog interface. Since PUL uses Ex Libris’s Voyager ILS, Primo held out the promise of a smoother transition and better integration of circulation functions and other features. However, there was some hesitation. Primo Central had only just been launched in beta testing in January 2010, and there were no live installations that the group could examine.2 Also, there were concerns about the amount of content in Primo’s unified index, especially compared to Summon, which at the time had broader article coverage and boasted a significant body of news content. In the end, PUL opted for a hybrid approach: using Primo (without its centralized index) as the new discovery interface to Princeton’s local content—cataloging data and other repositories, like senior theses and finding aids—while also subscribing to Summon to leverage its unified index of article and news content.

In fall 2010, PUL created the LDIG to implement this hybrid solution. Over the past three years, LDIG’s work has gone through three main phases.

Phase 1: Configuring and Preparing to Launch

The first phase of implementation involved becoming familiar with and configuring the new discovery systems. This primarily meant Primo, as there were numerous configuration choices necessary to prepare and normalize the Library’s local data for ingestion. PUL contracted with Ex Libris to integrate the Summon content into the Primo interface via Summon’s API, so Summon required little set up beyond turning on our full text packages in the ProQuest knowledgebase.3 The new system was hosted by Ex Libris on a custom domain, and the Library branded this new system SearchIt@PUL.

LDIG initially planned for a public beta launch in early 2011, but that timetable proved too ambitious. LDIG introduced the new system to staff in April 2011, while the public beta launch was pushed back to the beginning of the fall 2011 semester. Various issues contributed to the delay. For one, it took time to learn how PUL’s MARC records mapped to Primo’s new PNX records, and figuring out which fields were being displayed and indexed for search often required investigation and experimentation. We also ran into significant challenges trying to tailor algorithms for search, deduplication of records, and FRBRization in Primo to work well with our large and diverse collections. For example, there were numerous issues related to the indexing and retrieval of records in foreign characters, especially Chinese, Japanese, and Korean, which was of particular concern because PUL has a highly regarded East Asian library.

Working through these and other issues was time-intensive for LDIG members. During this phase, LDIG often worked with Ex Libris’s support staff, who were very responsive in answering questions and assisting the group’s work. Ultimately, though, Ex Libris was unable to solve some of these problems. Perhaps the most critical of these was the integration of Summon into Primo. After many attempts, LDIG decided that trying to incorporate results from Summon into the Primo interface was counterproductive. Results didn’t blend, the different levels of detail were confusing, and filtering options for the two systems were too dissimilar. While LDIG was still committed to using both systems for discovery, the group decided to take a different approach in preparation for launching the system to users.

Phase 2: Public Beta

LDIG’s new approach was to give up the idea of a single search box and interface for catalog and article discovery and instead present users with a tabbed search box on PUL’s homepage for searching Primo and Summon separately (see figure 1). This search box had three tabs: Catalog+, Articles+, and Course Reserves.4 We placed the Catalog+ tab first because we assumed most users would search in the default tab, and our local catalog results would be the data users were expecting to see. When users searched from the Catalog+ tab, they were taken to results in our hosted Primo interface (see figure 2); when they searched on the Articles+ tab, they were taken to results in our hosted Summon interface (see figure 3). LDIG added the new tabbed search box to our library’s homepage in fall 2011.

As users put the new system through its paces, LDIG discovered some problems with our implementation. We soon realized that the Primo interface offered limited flexibility for adding or extending features to improve our users’ experience. Library systems staff began coding workarounds to deal with some of these issues, including better display of records, paging of results, and a more robust item request form.5 We also experienced problems in the connection between Primo and Voyager, such as slow response times, the lack of current holdings information for serials, and the inability to handle serials with very large holdings records (e.g., Science or Nature). In Summon, staff and users expressed confusion over the various options for filtering results, and they had difficulty figuring out what content was indexed in the system. Additionally, because we use Ex Libris’s SFX as our e-resources knowledgebase, we had difficulty ensuring that the right content and journal packages were turned on in the ProQuest knowledgebase, and we had to alter our existing workflow to ensure new content was turned on in both places.

Phase 3: Shifting Focus

By fall of 2012, LDIG’s active implementation work had slowed. A major cause of this slowdown was a new project to redesign our Library’s website, which involved our programmers as well as me and some other LDIG members. Building off LDIG’s experience with our hybrid discovery service, the central feature of the new website was to be a tabbed search box on the homepage integrating both Primo and Summon (see figure 4). In contrast to our past efforts, though, the new website would reinstate an All Search across multiple content sources—Primo, Summon, our website, LibGuides, our finding aids, and more—and to integrate those disparate search results into a single results screen. The results would be displayed in separate silos on the screen in a “bento box” format (see figure 5).6 From these brief lists of results, users would be able to click through for full results to the native interfaces of the separate systems (Primo, Summon, LibGuides, Finding Aids, etc.).

The Website Steering Group arranged for multiple rounds of usability testing of the new website, something LDIG hadn’t done in its earlier implementation work. In the initial tests, most users praised the new All Search for its ease of use and also for the “bento box” approach of grouping results by category. They felt that this clarified the results they were seeing and made it easier for them to pursue different avenues of inquiry. Additional testing after the site had been live for several months exposed a divide between less-experienced and more-experienced library users. Lower undergraduate users gravitated to the All Search and were satisfied with their results, while advanced users, like graduate students and faculty, preferred searching separate databases and the old Main Catalog because they provided advanced functionality or required fewer clicks to get to their desired information. Although some of this reaction reflects an aversion to changing habitual workflows, we did see that some tasks are harder to do in the new systems. Finding the right balance between the needs of both less- and more-advanced users has bedeviled LDIG’s implementation work from the beginning.

The new website, which went live in summer 2013, has been a positive step forward in PUL’s efforts at improving resource discovery. However, it hasn’t addressed all of the underlying concerns about either Primo or Summon, its two major components. In the near term, PUL is likely to continue its hybrid approach. But given the rapidly changing discovery services landscape, PUL is keeping its options open and might shift its approach as new developments arise.

Reflections on PUL’s Experience

Looking back over the past three and a half years, I see several lessons for libraries considering or beginning to implement a discovery service. The first is simply a recognition that “implementation” may be somewhat of a misnomer—our “implementation” is still ongoing after more than three years with no end in sight. Whether it’s one or a combination of services, implementing a discovery service is an iterative process necessitating ongoing testing, tweaking, evaluation, and communication with staff and users. Like other aspects of a library’s web presence, discovery services require a continuing commitment of time and oversight to ensure they’re meeting the needs of users.

Clarify Project Scope and Goals

Since implementing a discovery service entails real costs in terms of money, time, effort, and attention, libraries should clearly state why they want to implement a discovery service, who the primary audience for the service is and how they will assess outcomes. This seems obvious, but project teams in libraries and other organizations seem to skip this step with surprising frequency. In our case, LDIG’s lack of clarity about the primary audience for our discovery services (e.g., novice vs. advanced users) has complicated efforts to prioritize feature development and evaluate the success of our implementation. While articulating assumptions and goals requires more time up front, it is an investment that will yield a more productive and responsive implementation.

Be Flexible

Even with careful planning, it’s important for libraries to stay abreast of changes and keep their options open. Technology, user expectations, the publishing market, and scholarly communication are all experiencing profound changes, and discovery services are evolving rapidly in response. It’s difficult for an implementation team to keep up with all those changes, let alone communicate them to users and staff. One benefit of rapid change, though, is that it makes it less risky to experiment with new approaches to discovery because users are growing more accustomed to this pace of change on the web. To facilitate experimentation and to preserve options for adapting to changing needs, libraries should look for discovery services that can be easily customized and which provide robust, well-documented application programming interfaces (APIs). Even if a library initially plans to use a vendor-hosted service “out of the box,” it may find itself changing course—like we did—one or more years down the line. Whether for a new library website or a new use case, as-yet-unimagined, libraries will want to have the flexibility good APIs and customization features provide. Libraries should investigate this thoroughly before signing on with any vendor by looking at existing installations, listening in or asking questions on product electronic discussion lists, and talking with other libraries about their experiences with customization and implementation. Even after subscribing, libraries should keep pushing vendors to provide more flexibility in using and customizing their services.

Communicate Effectively

Effective communication is essential to the success of implementing a discovery service. Implementation teams need to communicate with multiple audiences both outside the organization (with vendors, product user groups, and other libraries) and within the organization (with staff, users, and other stakeholders). Because discovery services change quickly and can be complex—both in content and function—libraries should look for vendors who communicate clearly and frequently with their customers about how their services work and who are responsive to customer feedback and support requests. Libraries should also engage with product support communities and other libraries to share and solicit ideas, feedback, and guidance in tailoring discovery services to meet their needs. Implementation groups should frequently communicate with staff and key stakeholders the purpose, plan, and progress of their implementation projects. At the earliest stages of the project, they should also provide clear channels for staff and users to provide feedback. However, implementation teams shouldn’t just wait for feedback; they should actively solicit user input through various forms of usability testing. The project will be better for the insights discovered from listening to staff and users as well as observing them use the services. In addition, if an implementation group can demonstrate that it’s considering users’ needs (both patrons and staff), the project will likely satisfy more people in the end, even if the group chooses not to act on all the feedback it receives. Clear delineation of project goals and how they align with the library’s strategic vision is invaluable in this process because it can help implementation groups know when to act on feedback, when not to, and how to justify both decisions.

Reckon with Time

Implementing a discovery service requires a great deal of staff time. Time spent on configuration, customization, troubleshooting, and training can be significant, especially in the early stages. Libraries would do well to estimate the amount of staff time such a project will require before beginning, so they can craft realistic project timelines and calculate the true cost of launching a discovery service. Like many libraries, Princeton approached this project by forming an implementation committee composed of members drawn from various departments in the library. This can be a valuable approach because these diverse perspectives can help to identify weaknesses or gaps in the project as well as help to ensure that the final product will meet the needs of multiple constituencies. But the committee approach also takes time—time to bring members up to speed on various issues, time to ensure clear communication of tasks and responsibilities, and time to build consensus on decisions—all while competing for the attention of committee members who are preoccupied with their primary work duties.

A Proposal

Based on my experience with LDIG, I believe that libraries implementing a discovery service should consider hiring a discovery services or user experience librarian to oversee the implementation. Having a librarian with primary responsibility to oversee discovery services or focus on the user’s experience would have helped LDIG in many ways. In the first phase, a discovery services librarian could have helped our group to articulate and clarify our project goals and keep them prominent in our early discussions about design and configuration decisions. A discovery services librarian also could have helped to keep us on schedule in the first few months by helping to distribute the workload and follow up to ensure tasks were completed in a timely fashion. During the second phase, having one librarian in charge of discovery services would have made it easier to solicit and respond to feedback as well as to communicate LDIG’s progress and any known issues. He or she would also have been invaluable in managing LDIG’s growing list of bugs, support requests, and future enhancements by helping to prioritize them, communicating with our vendors about them, and ensuring that the group revisited them as necessary. The discovery services librarian could also have helped LDIG to conduct usability studies to inform our continuing work. Finally, in our most recent phase, a discovery services or user experience librarian would have been helpful in working with the website redesign group to integrate our various discovery services as the design for the new website unfolded.

While Princeton University Library’s particular solution to resource discovery—integrating Primo and Summon—may not be helpful to most libraries, all libraries can learn from LDIG’s experience in implementing this solution. Considering questions of planning, flexibility, communication, and staff time can help libraries ensure that their investment in a discovery service returns the most value for both the library and its users.

References and Notes
1. Jason Vaughan,  “Web-Scale Discovery,” American Libraries 42, no. 1/2 (January 1, 2011): 32.
2. “Ex Libris Announces the Beta Launch of Primo Central,”, press release, January 14, 2010,
3. “Serials Solutions Takes the ProQuest Name,”, Serials Solutions, What’s New (blog), January 24, 2014,
4. Catalog+ was later changed to Books+.
5. In addition to the option for recalling items through our ILS, which Primo supported, we had separate request forms for in-process items, interlibrary loan, two separate off-site storage facilities, and Borrow Direct (a consortial lending arrangement).
6. This design and its name were inspired by the work of our peers at NCSU Libraries and elsewhere. See Cory Lown, Tito Sierra, and Josh Boyer, “How Users Search the Library from a Single Search Box,” College & Research Libraries 74, no. 3 (May 1, 2013): 227–41.


Figure 1

Tabbed search box on PUL’s homepage, circa 2012

Figure 2

Catalog+ (Primo) interface, circa 2012

Figure 3

Articles+ (Summon) interface, circa 2012

Figure 4

The new Princeton University Library site, Fall 2013

Figure 5

The new Princeton University Library All Search results screen, Fall 2013

Article Categories:
  • Library Reference and User Services
    • Columns


  • There are currently no refbacks.

© 2017 RUSA