Now that we’re about done with our Primo implementation, I thought it might be useful to share a few observations …
We resolved the last of the show-stoppers about six weeks ago and announced to staff that our new Primo discovery system was ready. Supported by what proved to be a great in-house implementation group and with solid vendor support (surprised to find that included very helpful weekly WebEx meetings) it wasn’t too hard to deliver a useable service even on an somewhat agressive schedule
The clock began ticking in June
As an aside, I have promised our implementation team that after they did such a great job navigating the really difficult stages of a project, I’ll do what I can to make sure they’re not forgotten when the final stage kicks in.
As I look back on it now, I think I failed to appreciate that in this context the word “disruptive” had a very particular and actually rather narrow scope. It has indeed proven to be a disruptive technology…but chiefly for staff. Based on what I’ve seen, from users it’s more like “what took you so long.”
The work of getting Primo ready began in mid summer. From the moment the ink dried on our contract I felt the sooner we could get it in front of our users the happier (and more productive) they would become. An early and continual concern was making sure we got the introduction of this disruptive technology right. More on that in a bit…
Discovery = Disaggregation = Disruption
So, why is discovery disruptive inside the library? Not really sure but let me offer a theory:
Years ago, we reference librarians were taught to use a series of indexing and abstracting sources and from there to track down information in all sorts of disparate, disconnected places (we should probably just call it “the age of paper” and leave it to today’s humanities researchers and tomorrow’s social historians). As time and technology advanced, online indexes began offering abstracts and eventually direct access to full-text content. Ever embracing the generic, librarians soon began calling these content aggregations databases.
Before long, instead of focusing on individual sources it seemed to make more sense to start thinking about research in terms of using the right database(s). Academic reference occurred within this framework:
library subscribes to database -> user searches database -> database delivers content.
We saw the “value-add” of our role as librarians in steps one and two (our expertise informed the library’s subscription stragegy and we helped users improve their efficiency during the search process). As databases increasingly provided the actual text of an relevant article, we stopped thinking so much about that final step (the actual delivery of content).
Fast forward to the appearance of “discovery” systems. Touted as a way to expand and extend retrieval by breaking down a library’s silos of information (e.g., those darn databases again) the discovery software also upset our now somewhat ingrained subscribe–>search–>deliver model.
A discovery service like Primo or Summon or EDS searches across an indexed aggregation of metadata. When it comes to actual retrieval, each must link out to where the content actually resides (an aggregator’s database, a publisher’s site, or perhaps somewhere else altogether). Where once the search layer and content shared a common environment (quite often literally the same server), with discovery everything seems to exist somewhere else. The discovery “experience” rests on the resilience of URLs.
So, with Primo and any other discovery system, there’s much more action happening in the space between steps 2 and 3 of the old model. In this new environment, knowing how an OpenURL resolver works (or how to fix things when it isn’t working productively) becomes a really critical skill for all librarians.
Independence is in the Details
Primo, more than most other discovery products, has embraced this decoupling of metadata and content. Unlike Summon (owned by ProQuest) or EDS (a product of EBSCO), there isn’t a content provider behind the sale and maintenance of Primo or its metadata index (what ExLibris calls Primo Central).
This offers a number of benefits. A Primo customer doesn’t have to cede any collection development decisions to a vendor (e.g., the discovery/content bundler offers packages of content “the customer can’t refuse”). Moreover, should the library wish to change out one discovery vendor for another, there’s no need to worry about price increases or subscription disappearances/substitutions. The same situation doesn’t apply when busting up a discovery/content-bundler relationship
But there are challenges as well. Content-aggregator/discovery entities like ProQuest and EBSCO now block ExLibris and other competing vendors from access to their particular content aggregations. As a result, ExLibris has to depend on alternative sources for metadata. In practice it usually works like this: ProQuest refuses to share metadata from a ProQuest aggregation with ExLibris, but if ExLibris can find the metadata elsewhere–typically by working with the publisher/rights-holder of the original content–then it can be included in the Primo Central aggregation. Where ProQuest or EBSCO happen to have exclusive e-content rights, well, guess you’re out of luck.
Carl Grant has written about another wrinkle we encountered during our implementation–one directly attributable to way vendors in the “discovery space” view one another. For many reasons, the vast majority of Primo installations also use SFX (another ExLibris product) for their OpenURL resolution services. We use 360Link from Serials Solutions (as part of an earlier consortial procurement in which we were a participant). Primo requires an XML file (same format as the one your library gives Google to support OpenURL linking within Google Scholar) so they know how a particular library’s e-content subscriptions match up against the metadata in the Primo Central aggregation (a DRM measure, really). While happy to give Google a copy of the file, SerialsSolutions refused to provide the file to us–explaining that they would be giving up competitive advantage. Even suggested perhaps we consider subscribing via API to the Summon metadata aggregation.
We finally developed the file ourselves but the incident was instructive (and disappointing) on a number of levels.
Technical Processing too…
I don’t want to leave the impression that this “in-library” disruption was limited to public services staff. No, it ran much deeper and right through the center of our technical services group as well.
As expected, there were disruptions around: MARC -> XML conversion; what I call the “…who would have thought that that obscure MARC field we never worried about in Voyager would cause that to happen in Primo” set of problems, and so on. What wasn’t expected (and I confess I’m indulging my own sense of disruption here) was that our OpenURL resolver’s knowledge base needed a lot of attention.
Fortunately, we have a dedicated group in our tech services area and over the course of several weeks we identified and addressed the most dramatic disconnects (disruptions) that the discovery process, well, discovered. We’re in a much better place going forward.
Know this: while OpenURL resolvers have been in libraries for years, once you implement a discovery system they’re no longer a side-show, an update-it-when-we-can-get-to-it, don’t-imagine-too-many-people-use-it sort of thing. The quality of your OpenURL resolution will determine the reception your discovery service receives.
Launch day approaches
As we got closer to a formal roll-out, we began dropping hints about inPrimo (by now our public services group had come up with a system name) and configuring ways for “early adopters” to get in a give it a try. We added a “test it now” preview link on the header of our classic (Voyager) catalog and added a promotional graphic linked to the inPrimo start page on the library’s home page.
We decided that pointing the home page’s search widget to inPrimo instead of our “classic” system would represent a “formal launch.” Once our new search widget was coded (and thanks to Jimmy Ghaphery down at VCU for pointing me in the right direction with some php code), all that remained was picking a date. We were ready by late October but to put a few weeks between our announcement of a date and the actual event, our implementation group settled on November 26–a little welcome back from the Thanksgiving holiday gift to our researchers.
System working well, data issues mostly resolved, daily sync between Voyager and Primo running smoothly, OpenURL working reasonably well (thanks also to Matthew Reidsma‘s enhancements for 360Link), and so on. In my head it was starting to look a lot like this when I thought about Primo:
Within an hour of notifying staff of our formal launch date, the skies began to darken.
From our public services area I heard, “We can’t possibly spring this on our users during this time of the semester–they’re busy writing papers and we’ll have a meltdown!”
I was genuinely surprised by that reaction. Isn’t it generally accepted that the one problem a “discovery” system can reliably solve is connecting the undergraduate researcher with some articles for a paper? Of course, having spent a few years as a reference librarian, I can appreciate that being on the desk as 30+ screens in the room suddenly show a new search system may not be the way you want to start your Monday.
Initially, I was sure I could defuse concern over this mythical “confused user.” I went back to the coding bench and came up a new widget for the library home page. The new one offered three prominent mentions and two direct links to the classic catalog. Following a colleague’s suggestion I reworked the tabs, making sure the classic catalog had one of its own. Surely that would be enough…
Nope. Best I could get was a “we’d still really like to wait until after exams.“
This is the fourth large implementation/migration project I’ve managed and in that time I have at least learned that you don’t get very far upsetting the public services staff who can otherwise serve as important ambassadors for the system once it is up and running. I can think they’re wrong or worried about the wrong things but I’d be a fool to ignore their wishes.
We’ll wait until after exams (mid December) for our formal launch.
Until then, I’m pleased to see that our Law Library has already made our inPrimo instance their default and our “stealthy” promotion links are generating on average 650 searches a day…the peak thus far being the 984 searches conducted yesterday.