Patrons in the driver’s seat: Giving advanced tool-sets to library patrons
Friday, April 14th, 2006
John Blyberg
Ann Arbor District Library
http://blyberg.net/
As I’m writing this, Newsweek is running an issue about Web 2.0 entitled, “Putting the ‘We’ in WEB”. Beside the fact that the mainstream media now thinks it’s safe to start spinning the web as they did during the dotcom era, there really is something to this new phase of evolution in information access. Tim O’Reilly calls is “harnessing the collective intelligence” which sounds ambitious, as Newsweek’s authors cede, but there it is: ripe for the plucking.
As libraries, we can look at sites like Flickr, deli.cio.us, and MySpace and see that they are wildly succesful. We can even take advantage of their services and APIs to enhance and grow our own portfolio of offerings, but the question remains, can we do this for ourselves? I believe that we can because we have several factors going for us that our commercial counterparts do not. First, we have local communities, second, we’re not after advertising dollars, and third, we’ve got physical spaces. The trick is assembling the right components to create unique, immersive experiences for our patrons both online and off. By adopting a long-term strategy of creting an infrastructure that promotes open access to information, AADL has had a fair measure of success in creating personalized “spaces” for patrons. These space are not portals, because, unlike portals, AADL’s offerings act more like a control panel for the library experience.
Warning: I am going to use some technical jargon in this presentation, but I’m using it while being mindful that you, reader, may very well not be a techie. As such, I’ve linked them to their respective explanations. My hope is not that you’ll understand the concepts, but that you’ll be able to file the terms somewhere in the back of your heads with a little bit of context so that when you encounter them again, you’ll enjoy some measure of understanding their context.
Getting your house in order
I mentioned that AADL’s was a long term strategy–one that began several years ago with an initiative to completely overhaul both the network and server infrastructure and a commitment to adopt open-source tools wherever feasible. By ensuring that our environment was condusive to modular growth, we put ourselves in a position that allows us to bring enhancements and features “to market” very rapidly. It was clear to me, when I joined AADL, that the attitudes and environment of library culture were very condusive to extreme programming and I am lucky enough to have a supervisor who is on the same page. Cohesion is only part of the solution however. Putting together a development environment takes some forsight and bringing any of the features I talk about today to fruition requires a fluid, viable development environment.
In AADL’s case, we opted for an entirely open-source set of tools: Linux, Apache, MySQL, and PHP (an assemblage sometimes referred to LAMP). Being familiar with these technologies is vital because simply getting them installed can be a challenge for the uninitiated. In addition, a development program needs to encompass version control and delineation between live and testing as well as the roll-out process. Taking the time to do this properly ensures that the best possible product is presented to the public.
Where to begin
Long before launching our website, I spent a good six months testing and playing with various open source content managment systems (CMS) and finally settled on Drupal because of it’s intrinsic API, taxonomy system, unique and lightweight approach to content delivery and large support base. Of course, ADD MORE HERE
Because we want to create an environment that is unique as well as functional to the library patron, single sign-on is essential. Without it, the patrons’ online experience immediately becomes a fragmented mess. The problem we ran into is probably the same problem other libraries will as well–it was the fact that we chose Drupal as our CMS, but our automation system, III’s Millenium, provides only the most basic authentication APIs and does not provide an API at all for conducting business within the OPAC (online public access catalog) such as fetching checkouts and holds or requesting material. This will pose a challenge. In our case, a piece of middleware (an invisible piece of software) actually performs a “reverse proxy” against the III server, meaning that we are able to hijack all traffic going to and from it. The middleware utilizes PHP’sCURL implementation and does the trick nicely. Once we were able to solve the single sign-on problem, all the tools were in place to begin creating any service we could concieve of.
Designating a control center
To begin, a major section of the website was dedicated to managing user affairs. If you look along the top navbar of the AADL website, you’ll notice the rightmost option is the “My Account” area. Clicking on this will take a logged-in user to the accounts section which is, in essence, a dashboard view of that user’s account. Much like other library systems, patrons can view their holdings and requests here. They can also customize the view so that they see only a few items, sorted by due date. From this page, patron’s have the option of renewing items, removing material from their holds list, changing their default pickup locations, visiting their checkout history, viewing their “virtual card catalog” collection, or managing their wireless devices. Most of these advanced features go unnoticed by many users, but a growing group of die-hard library patrons are begining to rely heavily on this library control panel. It allows them easy access to virtually every aspect of their online library experience both on and off the premisis.
The basics
The default pickup location was something we added in order to enhance III’s hold process. Out-of-the-box, Millenium’s hold process requires that a requestor specify a pickup location for every item. This can become a tedious task if a large number of items are being requested. By using the solution developed for single sign-on, we can provide patrons with the an option to select which pickup location should be pre-selected for each request. As with many of our services, this is an opt-in selection, meaning that there is no default and selection is not mandatory. This particular option does not neccesarily carry with it any privacy concerns.
You’ll notice in the screenshot, that the library card number is configurable field. This is because new Drupal accounts do not require a card number by default. We want to give anyone the opportunity to create an account on our website, no matter where they are from. Because we’ve created our services to be fairly ubiquitous, they can be enjoyed by pretty much anyone. I think that’s an important consideration when developing your new website policies. Bear in mind that the more participants you attract to a service, the better it becomes.
Keeping track
Checkout history, on the other hand, does. III’s built-in checkout history is an opt-in system and we were able to piggyback some advanced features onto their system while integrating the option toggle into Drupal’s framework. The checkout history (or “record check-outs” option) allows users to maintain an inventory of items they have previously checked out. Unfortunately, III’s implementation only allows users to view a tabulated list of their histories. In anticipation of some very large histories, we wanted users to have the option of searching and filtering. After all, what good is the data if you can’t find what you’re looking for. The result is a system that gives the patron complete control over their entire history. Patrons can search, sort, and filter results. If they wish to delete one or all records, they can, with the assurance that the data is dispatched from our system permanently.
Opening the front door
I can’t begin to approach the topic of library blogs as well as Michael Stephens can. I’d suggest that readers become familiar with his work to evangelize library blogs as his coverage is complete. Early in the website design process, we made the decision that blogs would constitute the nucleus of our dynamic website content. In addition, we wanted to enable commenting on those blogs. We really had no idea what kind of response we would get–of what form that response would take. Just a brief look at our Director’s Blog will illuminate the fact that the blogs promote a constant two-way dialogue between our director, Josie Parker, and the public. Of course, making this succesful requires a director who is courageous enough to regularly face the public head-on. But if you’re not ready to go there, be sure to take a look at some of AADL’s other blogs that are staffed by some very clued-in, bright minds. Virtually every material type garners it’s own blog. New blog entries are added several times a day. Often, blog entries serve to promote what, otherwise, may be obscured by the bigger names. In essense, blogging your material taps into the long tail by putting oft-overlooked titles in front of eyeballs.
Feeding frenzy!
Bloggers know that RSS feeds go hand-in-hand with blog content as a means of syndication. Over the past months, we’ve worked to provide a number of useful feeds, not just for our blog content, but for patron and catalog data as well.
One of the major benefits of modular programming with APIs is the ability to reuse code frequently and easily. We were able to do just this when we write the code that creates a feed for patron checkouts and holds. These particular feeds were interesting and required a little bit of tought as to how we would handle authentication. We, rather quickly, determined that a token-based feed would be preferable because it would allow users to share the feed if the so wished. The feeds can be very helpful in tracking material due dates and hold queue positions.
The catalog search feeds proved to be a little more of a challenge to produce, but have yeilded some very intersting results. Each feed is essentialy it’s own, self-contained, custom syndication. Creating a feed from the catalog is as easy as doing a search, then subscribing to it via the RSS button that appears on the top of each hit-list. Because results are sorted by catalog date, any new material matching that search will appear at the top of the feed, allowing subscribers to be alerted to new items in the catalog. We’ve discussed using this feed itself to offer a service that will automatically place holds on items for patrons. Many times, a feature like this will open the door to new posibilities you may not have previously considered.
If our patrons aggregators aren’t full enough by now, they may find some satisfaction in our top and new item feeds. These are updated nightly and are vital tools for disseminating that information. These feeds tend to be our most popular and show up on Ann Arbor residents’ websites. If your library makes this information available, creating an RSS feed can prove to be a relatively simple excercise. Many PHP tools, like MagpieRSS, exist to do just that.
Embracing nostalgia
What started as a side project to kill a little time, quickly grew in scope and resulted in a popular virtual card catalog service. There are essentially two components to the card catalog system. First, are the cards themselves. I’ve written a full description of the cards on my blog. Essentially, I wanted to gauge community response to social interaction within the OPAC and social software in a library setting. Each catalog record can dynamically create a vintage-looking catalog card on-the-fly. By themselves, they do look quite authentic, but accompanying them is a tool that allows users to write marginalia comments on the cards. It’s a fun little service. The second component gives the user a measure of control over what happens to those cards. Users can add cards to a personal card catalog for later retrieval. Once card are added to a personal catalog, they may be viewed any time and even sent via email to anyone vith an attached note. As the project grew in scope, patrons were given the option to share their card catalogs publically via a unique URL. In some ways, the service hails to LibraryThing’s published catalog service. In the future, RSS feeds and the ability to search, sort or filter the cards will be added.
The Card catalog service has been extremely popular, garnering thousands of marginalia entries and just under a thousand card collections. Given the fact that it is an unadvertised service, those numbers are quite remarkable. Those numbers also support my theory that library websites can become a destination as well as a resource and the OPAC can play a key role in making that happen.
Cutting the cord
Shortly after I began at AADL, we were given the green light to go ahead and implement system-wide WIFI coverage. Knowing this, and simulatneously charged with the job of redesigning the network from the ground up, I was put in the serendipitous position of being able implement an infrastructure that was condusive to guest access, development, future expansion, and software development for the enterprise. At the heart of our network is a linux firewall utilizing a very powerful piece of open source software called IPTables. Because IPTables is open-source and insanely configurable, it slid right in to our development agenda and allowed us to write our own guest access system with PHP and MySQL.
When a device that is unknown to the system tries to access a web page for the first time, it is redirected to an authentication screen–much like you would find at a hotel hot spot. Users are prompted to enter their library card number (guest numbers are available from our information desk clerks), at which point they are free to use the service. Devices registered by card holders are registered for a full year. During that time, they will never need to enter their card number again. Guests are registered for one month. The process is painless and, given the thousands of registered users, we have very few support requests for it.
There are limitations to this model, however–limitations any library that offers wifi should consider. If you follow Engadget, you’ll know that, with increasing frequency, new devices are being produced that take advantage of wifi, but do not neccesarily have a web browser. These devices range from gaming platforms like the Nintendo DS to Skype VoIP phones. While some libraries may ban such devices outright, we believe that we should accomidate them, but their lack-of-browser limitation leaves them out cold with our default registration system. Enter the Advanced Wireless Device Management console.
The WIFI device management console is a tool that is presented to our cardholders on our web page. The tool allows users to view a list of all their registered devices, add a description for each, delete them, and even renew their registrations. Perhaps its most useful functionality, however, is it’s ability to add new registrations manually
Game on!
Our IT manager, Eli Neiburger, has been the brains behind what is possibly the most succesful library gaming programs in the country. The spectacular aduio/visual experience we provide to the teens, however, couldn’t happen without the software to back it up. Of course, that software has a web component.
If you’ve ever tried to put on a gaming tournament, you’ll doubtlessly be aware that registration and scoring can be a very complex process. When you draw over one hundred participants, you need a way to manage the chaos. Our AADL-GT software is now is its third iteration and can be seen on the AADL-GT website. A quick glance at the GT page will show how blogs, scoreboards, and registration all come together to build an experience that lasts well beyond the day of the event. One blog entry triggered over 460 comments! The question you need to ask is, how often do teens spend this much time on a library website?
Picture Ann Arbor
The Picture Ann Arbor (Picture A2) service is a little like Flickr in that it allows users to upload their own photos. The online service is occasionally coupled with scanning sessions on the library premise. The purpose of this service is to begin building an archive of Ann Arbor photos from both past and present. Picture A2 is run on the open source project, Gallery 2, utilizing a Drupal plugin as the glue that binds the two projects together.
Putting data in physical spaces
AADL-GT is a prime example of how ubiquitous data can add value and immersion to the web site experience. How about putting it to work in physical spaces? Electronic signage is something we’ve been serious about for several years now. The project has been dubbed “Greetsaver” and began as a flash application using an open source middleware library called AMFPHP. It looked very much like a dashboard, pulling together news, local weather, and library events. With our recent Pittsfield Branch opening, came a second iteration “written” or created, rather in Apple’s Quartz Composer by Eric Klooster. The new version slides eloquently through event listing and takes advantage of the aformentioned top and new items feed to display new and hot material. As visitors enter the branch, they are greeted by this software running on a large LCD panel where they can glean some cursory information from it before they head off into the stacks. What’s important here is that there is zero barrier to entry for this service as far as the patron is concerned and it is both useful and, once again, let’s our data play out in the library experience.
Movie #1 - Welcome Screen (mp4) :: Movie #2 - Book Display (mp4) :: Source download
For the geeks
Ann Arbor has its fair share of techies who tend to respond to techie interfaces like that of our REST interface. REST (Representational State Transfer) is a way of allowing software to talk to other software via friendly XML. Essentially, it’s a computer programming tool that talks to our systems. Our REST interface sits atop our catalog and within the Drupal framwork and allows developers to create applications, plug-ins and mashups with our data. You’ll see an example of this with Ed Vielmetti’s wall of books [link to his presentation], and some of his other Superpatron projects. An XSLT-formatted example would look like this.
Providing developer tools to the general public represents a completely new attitude toward library boundaries. For instance, if a library has a number of developers hacking on a REST interface, producing software that can sit in a task bar or bezel, and that application is passed around, suddenly, the library becomes immersed in a user’s computing environment. This effectively blurs the edge of our reach. I believe this murky area holds a tremendous amount of promise as a venue for library interaction.
What’s next?
It’s been an exciting time at AADL as several years of work has finally culminated in a product that resonates with an atetntive public. We can’t, however, lull ourselves into a sense of complacency and believe that our offerings will suffice indefinately, or even over the next few years. Becuse the nature of our online world changes constantly, so must our approach to delivering service. How we go about assembling the product should also be an important consideration. At AADL, we’ve chosen to abide by the tenets of the open source philosophy because it’s very compatible with the philosophy and mission of libraries themselves, not to mention the flexibility it affords.
We are also keenly aware that AADL is blessed with the financial and human resources required to pull off the results that we do. By sharing our experiences, our knowledge, and our code wherever possible, we hope to lower the barrier for entry into this arena.
Just as each library community is different, so should our deliverales be, but at the heart of it all should be the idea that we’re building and fostering a community. In return, our users wil be stewards of an online palace of information that fronts for tangible material–books that illuminate, movies that stir, and music that moves us.
