We’ve gone ‘live’ (sort of) with our Blacklight-based (which means it’s Solr-based) ‘next generation’ public catalog. I say ‘sort of’ because it’s a phase we’re calling ‘public beta’ or ‘OPAC alternative’ — the legacy OPAC is still the primary catalog linked to on our web pages and other services, but the Blacklight-based catalog is available as an alternative for a public beta-test period. Eventually, the plan is, the legacy OPAC will go away and be replaced by this new one.
We brand our local Blacklight-based catalog Catalyst.
This is the result of a whole bunch of work put in by me, others at Hopkins, and other Blacklight developers. I think we’ve done pretty darn well with it, I’m proud of it. Although it’s definitely got it’s share of bugs, problems, and lack-of-features, some harder to fix than others. Nothing’s perfect, and our work isn’t done yet. (In general, I think in the current environment we will never be done with any user-facing library software. “The library is a growing organism”, and our systems, like all of our user services, must be as well.).
Satisfying the simple without sacrificing the sophisticated
Some “next-gen” type catalogs I’ve seen seem in my opinion to go the route of ultra-simplification. With Catalyst, I’ve tried to take a different approach, trying to serve the needs of both simple searches and complex or sophisticated searches or searchers. As Alan Kay said, “Simple things should be simple, complex things should be possible.” I’ve tried to create an interface which does not “dumb down” anything, but is also very easy and quick to use for the neophyte with a simple question she wants the system to answer.
One example of this is our item page. Some of the ng-type catalogs I’ve seen trim down the item information to the bare essentials. But contrarily, almost every part of a MARC record is displayed on our page, in fact in some cases even more than was displayed on our legacy OPAC. (Well, “almost every” may be saying too much, there is so much in a MARC record, esp if you start looking at fixed fields, much of it ignored by almost all traditional OPACs, and some of it of mysterious purpose. But there’s a lot).
However, those details are organized and displayed somewhat differently, and hopefully more digestably, than they were on the legacy OPAC. If you don’t need some of those details, they should be easy to ignore (and in fact for many use cases, the entire item detail page can be ignored — we try to put the fundamentals on the search results screen) — but those details should still be there for those who do. (We may trim it eventually, or reorganize it, but I suspect it will remain more exhaustive than some).
I don’t quite have this metaphor right yet, but I envision the ideal research interface to provide a “ladder of sophistication”. Right away, it should be obvious for the newcomer to understand how to use it to answer basic questions, quickly and easily. But when that person wants better results or to answer more complicated questions, there should be tools right there for them to ‘graduate’ to, moving up the ladder step by step, in a very gradual and pain-free process, to increasingly sophisticated use of the catalog.
There shouldn’t be an entirely different ‘power user’ interface — that’s too much of a break, people will be reluctant to move to it from the ‘basic’ interface they started with. There should be one integrated interface. But that one integrated interface needs to be very easy to use without any training — otherwise it scares people away right off the bat.
The interface should present a low barrier to entry, but provide tools the user can gradually, one at a time and little by little, when they are ready or in need, incorporate into their search repertoire. Ideally these ‘power user’ tools should be immediately apparent to the user un-aided, but if some of the ‘power user’ tools need to be pointed out by a librarian, that’s not the end of the world either — as long as the user can sit down the first time and get started with basic and common everyday tasks right away without training.
Users are diverse
On the one hand, this ideal of an interface will meet the needs of both basic and sophisticated searchers. And our local research into our own users show we have some users who want as simple and easy a search as possible, and other users who want sophisticated tools. This research was just qualitative, not a statistical quantitative sample, so I can’t say how many of our users are which. But I’m not sure how much it matters — it’s probably safe to say that most users most of the time want the simple approach. However, it is still part of our function, mission, charge, and role as a library (academic library especially, but really I think any library) to provide sophisticated research tools for sophisticated searchers and users — even if they are in the minority.
I also think many users will sometimes want a very basic quick easy search and other times want more sophisticated tools, most people don’t stay in just one category.
But in addition to serving diverse users, I think an interface with a very low barrier to entry but with more powerful tools seamlessly integrated into it as well — will help users who start out as basic users scared of complexity become more sophisticated searchers, one step at a time. As they become comfortable on one level, they can add additional tools into their repertoire. This is what I’m trying to get at with that “ladder” metaphor, that isn’t a very fleshed out metaphor at the moment.
Sometimes easier said than done
Still, sometimes easier said than done.
I think we’ve done a pretty good job of providing that low barrier-of-entry interface, that will give many users what they want much of the time very easily.(Although there are still a couple UX gotchas still in there, I think, which I think we’ll probably verify through some user testing and try to fix before we go out of ‘public beta’).
And I think we’ve actually done a pretty decent job of providing some ‘power user tools’ — some long-time users of traditional OPACs are somewhat averse to change, but I think if they give it a chance, the tools we’ve provided in Catalyst can meet some pretty sophisticated needs, in many many cases in fact better than than the traditional OPAC. (Initial reports are that even sophisticated searchers of the old OPAC can sometimes find things in Catalyst relevant to their research needs that they simply would not have found in the traditional OPAC).
However, I think there’s still a lot of room to grow in the ‘power user tools’ area. Adding more rungs to the ladder, for a higher view, if you will. (There, I did something with that metaphor!). There are all sorts of interesting sophisticated tools I can think of adding, but they’re all a bit challenging to add, and will take time to develop. The particular tools I can think of may or may not be the appropriate ones to spend development time on, to get biggest cost-benefit for our users. We will see. But I suspect we might need a few more tools to meet some of the most sophisticated or special case uses — which we will want to meet — as well as the legacy OPAC.
However, I’m also pretty confident that what we’ve got now (possibly with a bit of tweaking in response to what we learn from the beta) will work better, easier, and quicker than our traditional OPAC for the majority of users the majority of time. And without ‘dumbing it down’. That would be a win.
Remember: It’s not just search
It’s also worth pointing out that our ‘catalog’ is NOT just about search. In our existing OPAC, one of the most used pages is not about search at all: It’s the page to see what items you have checked out, and when they are due. Some users may spend more time checking their due dates than they do searching!
We have integrated Catalyst very closely with our back-end ILS to seamlessly provide patron account features in an interface that I think is indisputably better in all ways than the legacy OPAC. Here’s a screencast of our user account features, since you can’t see them without a login to our system.
One thing I’ve added since I made that video is ‘relative time’ display on due dates: “Tomorrow”, “Three days”, “Two weeks”, “About a month”, etc. This was pretty easy to add using the Rails distance_of_time_in_words helper (modified a bit for the use case), but I think it’ll actually be a huge benefit to our users — that’s what the user wants to know “how long do I have to return this”, why make em consult a calendar? Less than a day of my time, huge benefit. (Even if you don’t use Rails, the algorithm distance_of_time_in_words uses isn’t actually very long (although it would have taken me a while to come up with it from scratch), and it’s open source — you could port it to the environment of your choice, which might be a worthwhile thing to spend a day or two on.
I’ve also integrated the ‘holdings’ (locations, call numbers, etc) and ‘request’ functionality very tightly, they’re there right on the page, same as they were in our traditional OPAC.
This tight integration of back-end ILS features is something I don’t see in two many purchased proprietary ‘next generation discovery layers’, it’s difficult to provide off-the-shelf-just-works-for-any-ils, and is difficult to add with a clean interface to a closed-source black box product. I think we’ve done better with Catalyst in this area than we would have done had we chosen an off the shelf proprietary product, and I think it’s a pretty big win for the users too. Even if you can find what you need very quickly and easily, if it takes you 2-5 more confusing clicks to see it’s availability or submit a document delivery request for it (or see when it’s due once you check it out), that’s a pretty terrible situation.