The Library’s New EdgeCrossing the OPAC’s Threshold

John Blyberg

Nov 17, 2006OPAC 2.0: Reinventing the Library Catalog

NELINET

It’s pretty clear to me that as libraries, we’re pretty much dissatisfied with our OPACs which explains WHY we’re all here today. I know that I’m completely dissatisfied with ours.

So, my job today is really to try to talk about some of the things we should be thinking about as we consider the future of the OPAC.. And that really means asking some fundamental questions about the OPAC itself, such as, why we have it, what purpose does it serve and what form (or forms) should it begin to take...

Why we love/hate our OPACS...

• They did revolutionize the card catalog

• They’ve been the way they’ve always been...

• Don’t know where to begin changing them

• Don’t have the resources to do it anyway

So, you have to give the OPAC credit for one thing, and that is that it did a pretty surgical job of replacing the card catalog. Now there are a lot of librarians that never really thought that was such a great thing, and as time has passed since the first OPAC, we’ve actually identified some ways that the card catalog aided in the discovery of material that the OPAC doesn’t.

Did anyone read Stanley Wilder’s LJ article a few months ago entitled “Baker’s Smudges”? He talks about how the card catalog was actually a good indicator of use because the more oft-used items would accumulate dirt and oil from peoples fingers over time. A very interestig observation.

OPACs have not changed much in the past ten, fifteen years. Sure, at some point they went from character-based to web-based, but I’m not sure that ever really represented a radical change in the way we interface with them. Now depending on how tolerant of change you are, this may be a good thing--certainly a number of our users have a very hard time with change and they may love the fact that the OPAC has changed little, but I think it actually represents a failure to innovate on our part, and to some extent, our vendors.

So when we think about what needs to be done to change these beasts, many of us just get overwhelmed with a sense of not knowing what the hell to do about it. So you get a lot of discussion centered around a) why OPACs, um.. suck, and b) what we might like to see.

I’m going to actually cover both those things so no one here feels gipped, but I’ll hopefully also give you some things to think about in terms of concrete steps you can take to get to the next level in this process.

Also, many libraries simply don’t have the resources to do anything about this even if they wanted to. So their ILSs are really no better to them than the old company store. And this is where I keep saying that libraries who are able to need to step up and lead the way, and SHARE their successes, whether it be code/software, processes, or expertise. We are a community--we ought to act like one in this regard.

OPAC shortcomings• They’re Web 1.0 in every way

• Effectiveness hasn’t improved

• Not very customizable

• Unattractive

• Not extensible

• ILSs do not accommodate user-driven improvements

Ok, so I promised some trash talk.

[dog]

The results we get from our OPACs hasn’t gotten any better. This goes along with what I was saying about OPACs being how they’ve always been. And when you consider the fact that the OPAC is really the only way patrons can find material (short of talking to a librarian), you’re really saying that access to information and material hasn’t improved at all for over a decade--perhaps two.

They’re also not very customizable. Much of the HTML that comes out of the OPAC is often hard-coded into the system, so that even when a particular system offers a “templating system”, it’s very limited in scope. The result? Ugly OPACs--it’s that simple. We can put as much perfume on these pigs as we like but that doesn’t change the fact that they just not attractive at all.. They’re all tables and font tags, with limited or no CSS. Forget about XHTML and some of the newer javascript tricks that are bound up in technologies like AJAX.

Furthermore, they’re not extensible systems. They do what they do and nothing more. There is no cross-vendor specification to allow for user-driven improvements. And this really gets to one the the major problems in the library-to-vendor relationship. And bear in mind that there is plenty of blame to go around here--it’s not all on the vendors, so don’t make that mistake--I’ll talk a little bit about that later.

And what about our websites?

• Unattractive

• Outdated

• Static

• Non-interactive

• Made by “Bob” down the hall...

So you would think that if we really had very little control over our OPACs, we would break-out the heavy-hitters and put together some superb websites. After all, that is within our control, right?

Well, I’m sad to say that we haven’t stepped up to this task. Our websites are ugly too! Ok, so not all of them, but most of them are really just stinkers. They’re boring, self-important, and, to 90% of our users, serve as just another click or two between them and the ugly OPAC.

The “content management system” (or CMS) has been around for awhile now, but the library industry is slow to adopt that technology. Why? verious reasons I suppose--lack of expertise, political issues, lack of interest, or maybe some of us just don’t know how to go about it.

Anyway, the result is that many library web sites are still just static, flat HTML files that need to be updated by hand. Very little database integration or management of news, events, or the like. They certainly have no way of soliciting feedback and interaction from users.

And let’s be honest, many of our websites were put together by some poor, kind-hearted soul who volunteered to do it because they know some basic HTML.

Why focus on the website and OPAC?

• OPAC represents “library” to “patron”

• The website is our front line of customer service

• The “new” OPAC meets people where they are

First impressions are

important!

I think this represents a significant problem.

Imagine, for a moment, if your library invested the same proportional amount of time and talent in its physical infrastructure. What if your front entrances were shabby, plywood-walled rooms and your reference desk was six cinder blocks and a shutter? [room to read]

That really wouldn’t work for us, right? And I don’t think it woud really work for our patrons who expect a certain level of attractiveness. The library should be an inviting place, right?

Well, the OPAC is an electronic embassador for our libraries. It’s where most people go first to find what they’re looking for. It’s where 100% of our offsite users go to find material. It’s where librarians from other libraries go to spy on one another. If you think about it, the OPAC constitutes a fairly large part of the notion of “library” in the minds of our users.

And that makes our websites the first-line of customer service for many, many users. Not all, of course, but I’d venture to say most. We’ve got to get past the idea that our websites are simply ways to tell people where our branches and hours are. That’s overly-simplistic, but I was talking to a woman who is working on a next-gen library website product (I can’t tell you who or what) who said that their research showed that most people go to the library website to check their account holdings--after that, it’s to find out branch hours.

That’s very interesting to me because where some people might interpret that as what our users WANT, I see it as what our users have been conditioned to expect from library websites. And that’s bad news, because it means that not only do we have to revolutionize our web presence, but we need to change user expectations and, in effect, “get them back”.

We do that by putting the OPAC where the user is. We go to them, instead of getting them to come to us. Well, first, we go them, and then we get them to come to us.

Making Web 2.0 work for you

• Hinchcliffe (web2.wsj2.com): Ten ways to take advantage of Web 2.0

• Encourage social contributions with individual benefit

• Make content editable whenever possible

• Encourage unintended uses• Provide continuous, interactive user

experiences

And we do this by taking advantage of the same technologies and strategies that Web 2.0 companies are using right now.

If you’re familiar with Dion Hinchclife, you may have read his blog post on ten ways your company can take advantage of Web 2.0.

I thought it was a great way to start thinking about these types of SOA-oriented questions. By SOA, I mean...

Anyway, I think that its very helpful to tie his ten points back to the online library context and I wanted to do that with you here today.

1) If you’re familiar with Web 2.0, and Web 2.0 sites like Flickr, delicious, and netflix, you’ll know that each of these sites owes its lifeblood to the social contributions it gets from its users. think we need to be careful when assuming that if we, say, add the capability of tagging to our OPACs, our users will simply jump on it and start tagging the collection. We first need to consider how these new types of features will benefit our users.

A hokey kind-of example would be a virtual card-catalog system I wrote for Ann Arbor’s catalog that allows people to mark-up a vintage-style catalog card with comments. In-and-of-itself, it’s kindof a neat little app, but soon after I released it, I added the capability for our users to create their own personal card-catalogs by plucking out the cards they liked and adding them to a personalized collection. From there they could email the card to friends, and even opt to share their catalog with others. I’ve been pleasantly surprised at the number of users who actually take advantage of this service. In essense, by adding that additional bit of functionality, I turned something novel into something practical.

2) You also want to make sure that you empower your users to edit and change content wherever possible. Now, I understand that this flies in the face of traditional librarianship that champions the authoritative record, or information source. So our job here is a little tricky--we want our users to have a seamless experience, but we’ve got so somehow make clear to them, as well, what is authoritative and what is not. I think as organizations, we need to sit down and identify those “hot zones” where content can be opened up to the public.

3) I’ve always said that you cannot underestimate the ingenuity of a determined patron.. or the persistence for that matter. Well, we ought to be encouraging ingenuity among our users. And you may find that you’ve spend countless hours on planning and development of a feature, only to have it used is a way you never intended. Well, that’s life--it’s also ingenuity at work. You need to determine whether this new use is interfering with other users and whether it’s really “appropriate” and encourage it where you can. Often, this is where some of the best ideas come from. It’s natural to feel irritated at the fact that your work is not being used as you intended, but bear in

Making Web 2.0 work for you• Make sure your site offers its content

as feeds and/or web services

• Let users establish and build on their reputations

• Allow low-friction enrichment of your information

• Give users the right to remix

• Reuse other services aggressively

• Build small pieces loosely joined

5) I think most people here agree that RSS feeds are a good thing. If you have content, most RSS fanatics agree: make a feed of it.. why not? Libraries and RSS make a great pair.. Together we’re like Butch Cassidy and the Sundance Kid. There are a number of things to keep in mind when developing or rolling out feeds from either your site or your OPAC.

First, determine what should go in the feed. RSS is a lightweight protocol, so ou want to figure out what data is suitable for syndication. [RSS feed of search as example]

You also want to determine how the data in the feed should be formatted. Often times, the was information is displayed on a web page is not the same way you’d want it to be displayed in an RSS reader. I think a good example is an RSS feed of checked-out items or items on hold. Each item would, presumably, be the item checked out with pertinent holds info. On our web page, checked out items are simply displayed in a table layout. In the RSS feed, each item is displayed with additional bibliographical information and cover image. It looks great in an RSS reader, but is not appropriate for our website.

Another consideration is how often to update your feed. Will it update nightly, hourly, or in real-time as content is being generated. This will all depend on what the feed is of and how often items are added to the feed. You may want to consider “digesting” some things together in a single feed items.

You also want to discuss whether you’ll allow previously published news stories to update an older feed item or whether a new story will be issued for the update.

6) Moving on from RSS, Hinchcliffe touches on reputation systems. In the geek world, the most famous reputation system is that of slashdot.org--it’s also one of the first. Reputation systems allow users, staff, and programs to attribute relevancy, quality, and importance metrics to certain users and their feedback. This means that a system can do a good job of self-policing

It also tends to provide motivation to users who want to achieve more and more reputation points.

7) “low-friction enrichment of information” - You’ll have to be ready to accept the fact that social software systems generate an inordinate amount of crap. Just look at You tube if you don’t know what I’m talking about. The idea, however, is to not obsess over the clarity, conciceness, and content of all the stuff that gets put into your systems. Instead, you’re going to want to allow it to be in a state of constant change--and this is important--the tools to change (and hopefully improve) that content should be simple, easy-to-use bits of software that do not interfere with the patron’s browsing experience. That’s one of the reasons Ajax is so popular--it overcame that reluctancy of users to browse to a page they were not intending to.

Fundamentals of Library 2.0 web design

• Single sign-on

• Open standards

• Open source

• Integrated OPAC

• Social software

I think it’s important to follow Hinchcliffe’s principles with a set of fundamentals of Library 2.0 website design. It’s all well and good to understand how we can take advantage of Web 2.0 technologies, but if you’re going to be serious about putting up a Library 2.0 website (and that includes the OPAC), you need to adhere to a few non-negotiables.

First, is the ability to support a single-sign on environment. Single-sign on is not simply about convenience, but is really an essential ingredient for a cohesive online experience. Our websites should strive to be a destination unto itself, not just a place to get information. We have got to stop asking for a barcode and pin every time a user tries to put an item on hold. That means that somehow the OPAC and web site have to share credentials somehow. This is no easy task, but it is doable.

Our vendors may not go out of their way to support and use open standards. Web-based open standards give us the flexibility to promote and extend vital services both internally and externally.

Open source software is also not only a responsible alternative, but again maximizes our ability to access and use our own data. Philisophically, I think adopting open source in libraries is he right thing to do. If we’re able, we ought to be developing applications on OS platforms, then turning around and making our own applications open and freely available. I say this because we should act like libraries, not just in the stacks and at the circulation desks, but in our server rooms and IT departments as well.

The idea behind the “integrated OPAC” is based upon the tendency of library websites to exist separately from the OPAC. This makes it virtually impossible to build an application set around the OPAC because, in essence, you have the OPAC on one server and the web site on another. If you do opt to put your web site files on your OPAC server, you’re back to the same issues I was mentioning before. Ideally, the OPAC would be embeded within the framework of your site so that you have access to all the site data and functionality during page parse.

The last L2 website component would be the social elements of Web 2.0 we’ve been looking at here.

Beyond the website

• “Design for Innovation”

• APIs

• Community Development

• Mashups, personal apps, website integration, etc.

So, looking beyond the website, we’re faced with making these changes mean something to our users, and ultimately our communities.

We do that by “Designing for Innovation”. That means that we don’t just think about how our systems can enable us to innovate and create interesting new content and functionality, but also to think about how our users can too.

Ann Arbor has been an ideal community for this. We have a very energized user base and a group of top-notch library students just up the road. We actually have one individual who is a self-named “superpatron” -- Some of you may know Ed Veilmetti from his blog. He’s been one of these people who has really helped to steer us in this direction.

APIs, or Application Programming Interfaces are these open standards-based gateways that allow programmers to interface neatly with other systems. Generally, these come in the form of web services. That means that programmers anywhere can develop against our systems.

That, hopefully, promotes what I like to call “community development” -- a group of users who begin using your system in non standard ways. If these people are succesful, like Ed, they can turn around and share their successes with others.

They succeed by integrating our systems where they previously were not. Mashups are a good example of this. Mashups really illustrate that we can never fully anticipate our users needs. The mashup can be a dramatic new application or a very simple little widget--there really is no “right” or “wrong” way to go about creating them--they just need to mean something to their creator.

Beyond the website• The rise of the gadget

• Emergence of IPv6

• Cell phones, PDAs, PMPs, PGDs, smart homes, smart cars

• Knowing technology = knowing how to take advantage of it.

• Incorporation of other services

• Google books/maps/gadgets, Amazon, Greasemonkey, etc...

The mashup is also what begins to draw us out from behind the obvious boundaries of our website and into the world. For example, mashups can be found on and written for our gadgetry.

I say “the rise of the gadget” with a little tongue-in-cheek, but really, the gadget is really the next frontier in personal connectivity. Almost eveyone has a cellphone nowadays--many of them integrate with PDAs. Personal Music Players and Personal Gaming Devices are par for the course. The proliferation of these devices is one of the driving forces behind IPv6, which I really wanted to touch upon only to illustrate the type of growth we can expect.

Today’s internet is actually IPv4. If you’re familiar with what an IP address is, you’ll know it looks something like 141.213.156.1. IPv4 IP addresses are 32-bit addresses and public address space is quickly being exhasted because there are only so many iterations of these four octals.

IPv6, on the other hand employs 128-bit addresses which means that it can accommodate many many more devices. n fact, its unlikey that IPv6 space will ever be filled.

So we need to stay aware of these new technologies as they emerge because we have to know how to take advantage of them. We really ought to be retraining our though processes to think about how we can stay AHEAD of the curve, not behind it.

We also can become less library website-centric by learning how to incorporate other services. You see here an example of the Google API being used to display the top items at AADL. This is actually one of a suite of Google gadgets I wrote for the Talis mashup contest this past summer. It interfaces with an API specification I’ve written called PatREST. If I have time at the end here, I’ll demonstrate how easy it is to instantiate this particular mashup.

I’ve also written a mashup that links our AADL hitlist to the book-view in Google books for items in our catalog that have been digitized by Google’s book project.

Other tools, such as greasemonkey, allow users to customize their web experience. A famous example of this would be the “this item is available at your library” links from amazon.

Stepping beyond the OPAC

• Don’t get hung up on the “search”

• Focus on “discovery”

• Test new technologies

• Stay aware of current trends

• Know your community

• Be creative

If we’re looking at the OPAC specifically, There are a few things to keep in mind.

First, we don’t want to get hung up on the “search” capabilities of the OPAC. 2.0 is more about discovery, so we need to concentrate on finding new ways for our users to discover material and information. Again, judicious use of social networking tools can help to facilitate this.

It may not be the same in academic libraries, but most public library users are looking for advice and reccomendations. If they can get that inside out OPACs, they’re user experience will be much more fruitful.

It’s important that we also learn to play around a bit. Technology can be very fun and interesting, and we ought to try to keep it that way. So if we stay on top of the hottest new tech, and, literally, get our hands on it, it’s a very energizing experience. You’ll be constantly discovering new ways to take advantage of these things.

You got to also know who your users are. Social networking tools may not be right for every community. You’ve got to be in touch with what your users want and need. As I mentioned, Ann Arbor is a college town--so we can take advantage of that. If you’re a manufacturing town, or a city suburb, you will probably find that your users have a different relationship to both technology and libraries. Ultimately, you’re the experts because it’s your library. There is no one-size-fits all, so you’ve got to be the ultimate judge of what youll ry and what you wont.

Finally, be creative.. think outside the box and be willing to take some risks.

“Promoting the edge”

• Outreach

• Education

• Staff

• Public

• Policy

• Foster a “culture of innovation”

We need to also think about how were going to promote this new OPAC to our patrons and communities.

For that, you really need to mobilize your outreach and education programs to develop the programs and curriculums that are necessary to get awareness of these tools and technologies out there.

And by “out there” I mean both staff and public. I think it’s really important to make sure that your entire staff is at least aware of the significance of what you’re doing, if not the technical details. Obviously, not all staff members will understand or even take to the technology, but they need to know what’s going on and where to direct queries from the public.

As far as educating the public.. Like I sad before, I believe that our users have been conditioned to expect a certain level of service from our websites and OPACs. If we dramatically improve that level of service, we need to let the public know somehow. Part of that solution is marketing, but another important element to this is education--offering “tours” of your OPAC and website that highlight some of the less-known features.

These are some pretty radical changes we’re talking about here, and you may find that your existing policies governing internet and web usage are outdated. For example, we needed to change our policy at Ann Arbor to accomidate blog comments. Our policy strictly forbid the public to change or “enhance” the website in any way. A silly little technicality, but changing our library’s policy to reflect your intentions sends a message to your staff, and to any patrons who actually read your policies, that you’re serious about your commitment to these changes.

And again, I like this idea of a “culture of innovation”. Lower the barriers to creativity, whether it be by implementing social software on your website, opening up some kind of API, or even inviting some of your public to participate in the ongoing planning process. Ed Vielmetti, our “superpatron” is also on the library’s technology advisory board--a group people from the public we’ve invited to occasionally review our use of technology in the library and, hopefully, suggest new ideas.

Security & Privacy vs. Social Software

• Web 2.0: new notions of personal privacy

• Libraries are held to higher standards

• Libraries are among the least secure

• Privacy & social software - not mutually exclusive

I wanted to touch, very briefly, on some of the privacy and security concerns associated with this idea of “2.0”

Web 2.0 has certainly posed some sharp questions about the idea of personal privacy. I like to use the Facbook fiasco as a good example of what can go wrong. When Facbook started offering RSS feeds of everything their members were doing, it sparked a huge controversy over the practice. The feeds contained nothing that wasn’t already available, but did gather it all together and present it in one place. The argument was, “stalking shouldn’t be this easy”

We need to think about the fact that libraries are held to higher standards when it comes to personal privacy, so we cannot make the same mistakes facebook does. Now, obviously, we aggregate a different set of data, but we do need to be constantly aware of the ramifications of wat we’re doing.

Incidentally, library systems are among some of the least secure networks in the world. One of my mini personal crusades is to get libraries to improve their security. That’s another topic though. I just wanted to mention it here.

Anyway, privacy and social software are not mutually exclusive, however. You just need to find the right balance and implement a fairly granular opt-in system for these features. I suggest and opt-in system as opposed to an opt-out system because, as libraries, it better to be safe than sorry, I think.

Getting real...

• Money?

• Staff?

• Vendors?

• Ongoing maintenance?

Ok, so in the real world, there are are real problems standing between libraries and, as we’re dubbing it here today, OPAC 2.0.

Money is a real issue. It may be that you need to hire additional staff, purchase additional hardware, or licence additional software. Theres no two ways around this, money needs to be spent. You need to first identify what the one-time costs are going to be, as well as any potential ongoing costs, then, in lieu of what I and everyone else says here today, make a decision.

Part of that decision will probably involve staff. The face of librarianship is changing. I think this is actually in industry that is going to have to start defining itself as an industry of change. That means changing the make-up of your staff. Do you need a programmer? It depends on what yours plans are. If you want to do anything substantial with your online presence, you probably do.

Vendors are a huge part of this equation. I was at an ILS symposium in Windsor this past Wed and it was one of those situations where I couldn’t even get a cup of coffee because so many people were stopping me to gripe about their ILS.

The din of dissatisfaction is growing, but it’s not quite loud enough yet. And I’ll admit that some vendors are better than others. We need them to open up their systems and provide some of these open, standards-based APIs I’ve talked about.

[?? Evergreen]

And finally, there’s the issue of ongoing maintenance. Who will take care of it, how much will it cost, what happens if something breaks--what happens if the person who designed and built it gets hit by a bus, or leaves the organization?

None of these are easy questions to answer or problems to solve.

First steps

• Make a commitment

• Admit you’re powerless against creating a crappy website

• Intercept user feedback

• Enlist the Pros

• Get to work

But.. Whenever I’m overwhelmed by a daunting task, it always helps to figure out where to start.

I think we all need to start by making a commitment to change. We need to acknowledge the fact that we cannot achieve what we want without changing the way we do things. If that means making some unpopular decisions like pulling resources from one place and putting thm in another, so be it. We’re not in the business of making ourselves happy. We need to think about and discus these things pragmatically and make decisions accordingly.

Then we need to admit that we’re completely incapable to creating a good website. That’s not our business. Thats not what we do, it’s not part of our expertise. We can’t just let “Bob down the hall” put together our site.

So what do we do?

We enlist the help of some pros. I’m a bit proponent of going outside the library to find people who really know what they’re doing--who understand how to intercept user feedback and turn it into a user interface that works for your users. When we were developing our website in Ann Arbor, we did hire some professionals to do the web design. It wasn’t cheap, I’ll admit, but it was money well spent.

Finally, if you still are unsure where to start, just start somewhere......

Thank - you!

Questions?