Ex Libris recently did a complete overhaul of the user interface for their Primo discovery layer. They did a great job and developed a UI that is responsive, modern, and (mostly) easy to use.

In this article I’d like to first look at some key innovations of Primo’s new UI and then discuss the process of implementing local customizations and some of the challenges involved.

The New UI

I’m not a big fan of tabbed interfaces and was always bothered by the distribution of item information across tabs in the old Primo interface (e.g., Locations, Details, and Browse). As a user, I found that even when I saw exactly what I wanted in a list of results, I still had to spend a second thinking about where I needed to click next (assuming I wanted more than just a call number).

Old UI item view. Location info not immediately visible. Actions are under a menu.

The new UI displays everything in a single panel, so anything you want to know about an item is only one click away from the result list. Actions are arrayed across the top rather than being listed in a menu.

New UI item view. Location info is visible. Actions are visible without activating a menu.

With the new UI, Ex Libris made huge strides toward mobile usability. The old UI was usable, but not very pretty. Some features, most notably facets, were not usable. The new UI is a tremendous improvement. I’m especially fond of the facets menu as a sticky footer, a design choice that will keep the possibility of refinement in the user’s mind as she scrolls through results.

Old UI on iPhone 6s, Safari.

New UI on iPhone 6s, Safari.

As with any complex UI, not everything is perfect. The product is still in development and Ex Libris is actively making improvements, many based on input from librarians via the Primo listserv and the Ex Libris Ideas platform. They recently ditched the unpopular “infinite scroll” results list in favor of paginated results, based on accessibility concerns from customers. They’re still addressing a problem with the new UI in “private browsing” mode on iOS.

The speed of the new UI is not good. It seems to have improved marginally with the most recent release, but it still feels slow. This slowness is especially apparent when a facet is applied to a search, requiring a complete redraw of the screen. If you accidentally click on the wrong facet, then have to remove that facet and choose another one, that’s three redraws, and probably at least one expletive.

Possibly related to the speed problem is the number of animations. For the most part, these are subtle, professional, and not distracting. They make the interface feel interactive and modern. But there are an awful lot of them and I wonder what cost they exact on performance.


For those of us who like to customize and add functionality to library systems, a new interface can mean a lot of work. The new Primo UI was no exception.


Very early on, the Primo community learned that the new interface would be based on Angular JS, a JavaScript framework mainly maintained by Google. This seemed like an odd decision on the part of Ex Libris. It isn’t surprising that the Ex Libris developers wanted to work in Angular — it’s a popular framework. For developers.

What surprises me is that they expected librarians to work in Angular. An “average” library, whatever that is, almost certainly has some internal expertise in CSS, basic JavaScript, and jQuery. But Angular? Not as likely.

At my library, there was no internal expertise. So it was off to the Internet. There are many great tutorials out there on Angular JS, and the framework itself has excellent documentation. But the tutorials are generally project based: “Build an X with Angular JS,” where X is some variety of search/display interface on top of some JSON data.

So despite the knowledge I’d gained from the tutorials, I still had no idea how to make even simple modifications to the new Primo UI.

It turns out that the key to inserting content into Primo is something called an Angular “component,” a concept barely touched upon in most tutorials and books. Ex Libris liberally sprinkled their new UI with Angular “directives” (i.e., custom HTML elements) to which developers can add code by creating a corresponding component. The component, in turn, may optionally refer to a “controller,” which is where you can insert your own programming logic. For most things, it’s not terribly difficult once you get used to that model, but it feels very restrictive. What if I want to do something in a location where there isn’t a pre-defined directive? And what if I want to alter existing content rather than create something new?

Editor: Ron gave me the okay to duck-in for a moment to elaborate. An Angular component can be a little weird if you’re predominately coming from jQuery. Think of a component like a custom HTML element, that has styles and functionally baked into it. For instance, you could make a carousel using an arrangement of <div>s and images, and wherever you want to place a carousel you must copy all that markup. Or, you could write it just once and tell Angular to — from now on — recognize the <slider> element instead. Components are both useful for substituting a little code for a lot of code, and also a way to sanitize and streamline how people — like librarians customizing Primo — use it.  — @schoeyfield

The Development Environment

Ex Libris was nice enough to provide a development environment via GitHub so that developers can have a local sandbox for the new interface. This includes a ready-made Gulp workflow to deal with things like minification, concatenation, and bundling the whole thing up into a package that can be uploaded to the Primo Back Office for live implementation.

Again, this is nice if you’re familiar with the technologies, but I get the impression that not all librarians are finding this as approachable as its creators intended.

The Customizations

Ithaca College Library has implemented a few additions in the current version of Primo: a “text this call number” feature, a “not on shelf” (trace request) link, a “notify me on arrival” feature for on-order items, and a map highlighting a physical item’s location.

We’ve managed to implement all of these features in the new UI, but it has been a long process, with a lot of false starts. Once I figured out that I could often drop existing code into an Angular controller with only minor modifications, things went a lot faster.

Lessons Learned

The work we’ve done at Ithaca College so far would have been impossible without the support of the Primo listserv and the Slack group that formed following an Ex Libris-sponsored webinar. There are people in these groups who are far better programmers than I am, and I’ve learned a lot from them. I can’t think of another project I’ve worked on where success has been so dependent on the kindness of strangers.

While I enjoy extolling the generosity and creativity of the many Primo-using librarians out there, the dependence on informal information sharing points to the inadequacy of Ex Libris’s documentation. As with any product, quality documentation in a single location goes a long way toward meeting the needs of customers.