Pimp your Primo!

26 08 2015

Christmas came early when we implemented Primo from Ex Libris. A system to learn and a new API to play with. What’s not to like? In the real world though, where there is still a day job to do, we needed to prioritise our developments.  The first 12 months or so was mainly spent of bedding down the system which is branded here as IOE Library Search. Our first challenge was to get the data pipes which feed Primo from our local systems working. We managed to get our SirsDynix Symphony LMS to fuly synchronise (including deletion of records which was I believe a first). You can read about that in a presentation which I participated in here . What I want to talk about in this post are the little things we were able to do to improve our service.

The Libanswers widget:

We had always intended to bring together the support side of our website with the content in order to provide context sensitive help, and had felt that in theory this should be achievable with Primo. Our online support service software is Libanswers from Springshare. It helpfully has an API and we have been able to create a javascript widget which takes the search terms which the user enters and returns relevant libanswers. You can see it in action here:



Integration of local systems at full record level:

Holdings for the LMS, EPrints etc are viewed via an embedded version of the record in the actual (remote) target system. This can cause some screen clutter as it includes the header from that system and possibly repeats the bibliographic information. The holdings themselves may only be visible by scrolling down the page. In order to make things clearer, we used a simple css technique to hide the irrelevant parts of the record. For example, in SirsiDynix, if you look at the full record in a standard view, it looks like this:



But by adding replacing the parameter user_id=WEBSERVER with user_id=PRIMO, it changes to this:


How was this achieved? First we cloned the user environment WEBSERVER on Symphony (calling it PRIMO) as we only want to lose the header if the record is called with that parameter. In Symphony, it is possible to point different environments to different custom css files, which is what we did. In a file called primo.css, we simply took a number of the irrelevant sections of the page and used the css clause display: none. This worked well enough but a few extra tweaks were needed to stop various side effects. If your webcat has an automatic timeout, it defaults back to the WEBSERVER version of the page. Also, you need to check that clicking through for particular services that should be shown on your page still works as expected. For example, clicking reserve, logging in and reserving the book. These were resolved by forcing a new window to open in certain cases, effectively “breaking out” of the Primo box. It is not perfect, but neither was the original scenario. It is nevertheless a great improvement in the user experience for Primo sites not using an Ex Libris integrated LMS a their back-end system.


Next step. Integrating the floor plan system so it is more visible on the Primo interface.