Live with Blacklight-based ‘next generation’ OPAC

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.

(Here’s a brief instructional/promo video  created by colleague Sean Hannan, which is surely the slickest library promo for a catalog I’ve ever seen.)

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).

Ladder metaphor

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.


15 thoughts on “Live with Blacklight-based ‘next generation’ OPAC”

  1. Well done – it looks fantastic! You’ve put a lot of great work in to it.

    Did Sean use Jing to make the video also?

  2. This looks brilliant! Great work! I like to think this shows the power of open source — that none of the ILS vendors have come up with anything as good as this, in spite of all the revenue they are raking in.

  3. Outstanding!!
    Caveat: I looked at it in both newly installed Firefox 4.0 (looks brilliant), and IE (looks terrible……). Here’s hoping everyone is using Firefox!

  4. Nicely done. The screen cast is good, too, and the intro video is simple and stylish.

    The circ status and request links on the index result display are good. The format information in that same display is good content-wise “Musical Recording in Slovak, Polish, 2002 ,” “Book in English, 1979”. But the information about format is not highlighted–as it often is–by use of icons or other technique. So I missed it at first (missed the highlighting). After a bit, though, I thought it was just an artifact of my expectations. Icons are often not clear in themselves and not precise as desired.

  5. Matthew: I have been thinking that some additional highlighting of format is needed too. We’ll see if our user testing has anything to say about it.

    Joe: At one point it worked fine in IE, but I’ve gotten other reports of it not being right in IE too, have to find time to get to the bottom of it. That’s why we call it a public beta! What version/OS of IE are you using?

  6. Windows Vista, IE8, looks fine to me, just the same as Firefox/Chrome/Safari (but that IE8 can’t do rounded corners). But reports are its’ an IE7 problem. I have no idea how to get IE7 installed on my computer to debug that. Ah, Microsoft.

  7. You are right….I looked with IE8 and it looks good. Our campus IT folks still have the mainstream browser as IE7 on Vista.

  8. Yeah, we’ll get it fixed for IE7, although it’s a pain, didn’t mean to leave it out. Public beta! (But they’re about to come out with IE9, why doesn’t anyone ever upgrade their IEs, I don’t get it?)

    There is no project plan or timeline for a mobile html interface, but it probably makes sense. The existing interface works tolerably on a fancy phone.

  9. It turns out they IE9 final release actually is out, as of a couple weeks ago. I hear that it’s actually pretty decent, and really even IE8 is a tolerable browser to develop for. But I don’t know why it seems like there’s some ‘enterprise’ rule that all businesses run at least two versions behind on IE.

  10. Enterprises don’t update their standard loads until they’re certified to work with the necessary business applications. That’s why it took so long to move to IE7 from IE6 – a standard facilities ticketing system (among other business tools) wasn’t compatible.

    I demo’ed a prototype somewhere last February that was still on IE6.

    If nothing else for IE7 it would be great to get the logo there – otherwise it basically works.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s