Much has changed in the last year with respect to the notion of a "library website". It's as though the clear, glassy surface of a morning bay has been turned and cast about by steel, unforgiving turbines. Many unsuspecting libraries are now caught in that turbulent wash, casting about for something, anything to hold on to as they begin the daunting task of "the redesign". The problem is, where do we even begin? If there was no gold standard before, there still is none, but we now acknowledge two things: Traditional library websites drain the life-force from patrons. Our OPACs finish the job.

So where do we go from here? Is there anything, anything at all we can use as a modus operandi as we, once again, begin the process of re-provisioning the obligatory library website?

Let me suggest five directives that may help get your creative minds turning. I want to talk about these not only because they represent common sense, good design, and patron convenience, but also because by using these directives as a kernel in your new project, you are sure to come out the other side feeling highly rewarded and sporting a new website that will invigorate your inner-geek for years to come.

Social software, as you are probably aware, was born of the read/write web. Partially due to persistent connections, newer software, higher bandwidth, and plain old human acceptance of the machine, the social web is a beautiful lace spun with minds, machines, and information. It is who we are as humans--it is community. just like the public library is community. So to ignore social software in the context of our library websites, is to ignore our communities. We need to find a prominent place on our mantle for it and ensure that our websites invite humanity in and give it right back. The point here is to extend the boundaries of the library, perhaps blurring the edges like watercolor so we're not quite sure where the library ends.

There are many ways to incorporate social software into your sites, not the least of which is the use of mash-ups, or the judicious use of an open source database like MySQL in conjunction with a little PHP, running on Linux, served up by Apache. Adopting open-source platforms and technologies in a library is not just financially beneficial. Philosophically, it's the right thing to do. We ought to be developing on open-source then turning around and making our work freely available to one another. We are libraries after all, we ought to act like it, not just in the stacks and at the circulation desks, but in the server rooms and IT departments as well. Don't forget the intrinsic benefits of supporting and pursuing an open sourced development program. Eric Raymond writes in The Cathedral and the Bazaar:

...we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Joy truly should be an asset as you continue to plug away at your web project. If it is, the final product will reflect it. Open source allows success to be contagious as code is reused, changed, improved, forked, spawned into radical new ideas. That sounds like something a public library ought to be involved with, doesn't it?

I think it's time libraries took the notion of single sign-on seriously. We need to get away from the model where patrons are required to have their library cards handy every time they reserve an item. Who wants to have one set of credentials to access the OPAC and yet another to make a blog comment, or fill out an ILL request? Why not be like the rest of the world and simply require a username and password? Let me take this one step further, as well, and suggest that your new websites support session-based single sign-on--a useful little bit of web technology that has been around since, well, almost forever. When I create an account on a site I use frequently, I expect that I'll not have to keep re-entering my password every time I visit. Otherwise, I won't be visiting that site very frequently.

Single sign-on is not just about convenience, either. A unified user management system is a vital ingredient in the foundation of a cohesive online experience. Think about what your users will be doing, especially in light of the fact that you're going to implement all those great social software features. As I've mentioned before, the library website can be so much more than just a resource--it can, and should be a destination--a community touchstone. You can't do that if there is a functional disconnect between what you're offering and how you're offering it.

Single sign-on will prove to be a more difficult implementation than you may be thinking at the moment. As you scratch the surface, you'll see why, what will all the disparate software you'll be gluing together. After all, it's not like our vendors are going out of their way to offer and support open standards. We ought to, of course, for many of the same reasons I've outlined for open source. Open standards, however, gives us the flexibility both internally and externally to promote vital services in a timely and easily accessible manner. That sounds good, right? Adopting W3C standards will ensure that we've provisioned for any eventuality. Need to export? No problem. Someone wants to get Greasemonkey all up in your site? Go right ahead, Ed. RSS feeds? Absolutely essential. Want to offer a web services front-end to your OPAC? Why not use SOAP and throw in some WSDL so that potential coders can hit the ground running? Open standards, open minds, open doors.

Then there's the white elephant. Your OPAC--that malignant growth that looks nothing like the rest of your site and appears to have been coded by a CS 101 student who is contemplating switching majors to say, English. Insist on an integrated OPAC. Again, this may be a technical challenge, but nothing is impossible. If you find a way to tame the beast, you're going to completely transform the way your website operates. Ideally, the OPAC should be embedded inside the framework of your site so that you have access to all the site data and functionality during page parse. Once you've got control over what, where and when your OPAC displays, you'll find that a world of opportunity has opened up to you. While pondering a way to achieve this, you may find yourself, again, at your vendor's doorstep, whimpering, "please sir, may I have some more?" Unless the request is in an RFP, however, good luck. All we can do is chip away at them, in the meantime, there are ways of getting around that technical hurdle, but they probably require a programmer--a position libraries should consider adding anyway.

All this is an oversimplification of an arduously complex process, I confess. Sometimes, however, when you're not sure where to begin, it helps to consider all your options within a set of parameters. If I were to launch into a library website project right now, these are the "must-haves" I'd start with. For my part, these comprise an ideal that will stand a project in good stead as we continue to cast about in a 2.0 world.

[tags]Library, Libraries, L2, Web Design, OPAC, Development, Programming, Coding, PHP, HTML, HTTP, AADL[/tags]

The first ever mashup camp drew to a close yesterday. It was the brain-child of David Berlind and Doug Gold. Essentially, It was a collection of mashup authors from around the country and, ostensibly, the world who gathered to share their creativity and brainpower. Notably, among them was Ann Arbor's Ed Vielmetti. He's reported back on the "camp's" progress--be sure to check out his blog.

But what does this have to do with libraries, and why should we be paying attention to this? Well, beside the fact that mashups are the new, hot technology and we should be keeping up with all new, hot technology, mashups have enormous potential to redefine he library boundary both in terms of the technology itself and the people creating it.

Immediately, we can see the potential on our own sites by bringing in highly-polished, powerful tools in ways that enhance the information we already have to offer. A good example that Stephen Abram cited, was the ability to use the Google Maps API to provide very specific, very user-friendly directions to library branch locations. What makes mashups so exciting is that creativity and innovation are the key elements at play in the construction of these things.

The fact that new, high-level scripting languages and development engines like Ruby or Ruby on Rails, even, are being developed make the assemblage of Web 2.0 APIs a fairly easy endeavor. As a result, we're starting to see our patrons get into the groove as they begin to spin their own creations. Ed Vielmetti's Amazon mashup is a great example of this. He's written a Greasemonkey plugin that sneaks item availability into an Amazon record. The subversive nature of these things really tickles my fancy--it allows us, as end users, to do things that would mortify any sales team. We need to laud the use of our data wherever our patrons decide it should be.

Mashups are about individual empowerment. As libraries, we need to be able to step right in and lend tools to our users that will allow them to start creating these unintended uses. Again, this requires us to have... that's right, suitable APIs! The PatREST project I'm working on strives to do just that and I'm so grateful that Dave Pattern at Huddersfield has joined me. We've been able to create a bilateral push for this by producing near-identical results using two very different systems.

The mashup also poses some fundamental questions about the library's reach--where it begins (from the patron view) and where it ends (from our insider's view). By enabling users to spin our library tendrils into any place they like, we're creating a very ambiguous border on our OPACs, which, in turn, causes the entire ILS to recede into the background and play a significantly different role. Increasingly, it's just the business logic we want.

And so, as a whole new generation of Frankensteins are born, can you say that your ILS ready? Can you deal your data out under the table? With sleight-of-hand, we're going to make the library insidious.

[tags]Mashups, API, Web 2.0, Library 2.0, Programming, Coders, Superpatron[/tags]

This latest maneuver against our vendors' flanks consists of several posts in addition to Sarah's. She links to a post from Steve Oberg who, in turn, links to a very interesting post at It's all good.

Sarah has every right to express the frustration she does with vendors. They are still, in many ways, serving to stifle some great innovation at a time when innovation is both vital and time-sensitive. I think that's the impetus for this frustration, now. Working with existing systems is outright infuriating and the promises we get from our vendors are like those you might get from an addict who owes you money: "I'll have it for you next week, I promise!"

I found Steve Oberg's observations to be particularly keen, though I do take issue with one point: "By and large, lack of deep pockets and resources to research and quickly implement new products or features". I believe the problem is not money even though vendors may see it that way--they are looking at the marketplace which is generating a perpetual demand for widget X, Y, and Z. Ultimately, I see this as a problem that is internal to our libraries and not with our vendors. Oberg almost touches on this with another point, "More attention [is] given to librarians’ needs than library users’ needs". Except, I would phrase it, "More attention is given to librarians' needs than the needs of those who work intensively with the ILS." In other words, the tech staff. Libraries have been incredibly reticent when it comes to letting technical people make the technical decisions. The result? Vendors who are given laundry lists of nonsense by folks who really don't know what they're asking for.

Alane at It's all good has a marvelous paraphrase of Pat Sommers, CEO of SirsiDynix:

Pat was responding, if I recall correctly, to a question from the floor about why ILS vendors don't innovate more quickly. Pat remarked that his company spends $10 million a year tweaking their systems to respond to requests from customers, and that left scant time and resources to make big changes. Robin rephrased this to describe all that activity as "building twiddly bits."

I'm glad Pat Sommers called us out on this. We are ultimately responsible for giving flight to an albatross that draws both vendors and libraries away from the marriage between our vision of tomorrow's library and 21st century technology. In reality, all we really need is the simplest of solutions: the ability to innovate on our own. But what will that take?

First, librarians need to stop asking for silly little twiddly bits. Libraries should be listening to their IT departments and vetting requests through them. If you don't have an IT staff, then a part of the solution is reevaluating your staffing needs so that you have some technical people on-board--this can be as simple as canvasing your existing staff, looking for someone who wants to make the move into geekdom. I believe that a coder-on-board sign is simply a characteristic of most 21st century libraries--it's not enough to employ the best librarians you can find, you need to get passionate, interested techies as well. Ideally, library schools ought to be considering the merits of a CS track. Courses need to be developed that synthesize coding skills with library science. The more technical know-how that is mixed in to their customer-base, the better chance vendors have at getting sensible feature-requests.

But it's not just us. ILS vendors need to wake up! An entire new business strategy needs to be extolled. What should that strategy look like? Vendors need to enable library staff with tool-sets in the form of standards and APIs. Of course I've been over this time and time again, but the fact is, most vendors are not hearing this. Maybe I'm feeling the fatigue that sets in after months of subverting the intended use of our system, but quite frankly, I hold little hope that our vendor will decide to pursue a strategy that champions community dev. In fact, during a recent visit to AADL, we were told by a top III executive that we have all the APIs we need. Apparently, he seemed unfamiliar with the entire notion. What we've accomplished is in spite of our ILS, not because of it. He was visiting under the pretense that they were very impressed with what we'd done with their system--I thought, "great, this is encouraging--a chance to open a dialogue". As it turned out, he was just using AADL as a sales venue for another customer. The irony makes me grit my teeth. It's a good thing I was on vacation that week--I might have told him that we've done things to their system that would make Paris Hilton blush. (I would have thought it, at least.)

There is real frustration among the people who are working with these systems, but it should also be said that some vendors are making an effort and seem to be truly "getting it"--or at least trying to get it. It's not entirely fair to castigate them all. They are not just some dark uber-force, brooding "out there" among the turbines of a ravenous capital market. It's important to take a good look at your own ILS and vendor to determine whether they really have your best interests in mind. You may just find that they do. If that's the case, use every ounce of that good fortune to your advantage because many of us are not so lucky.

But before I go any further, I need to disclose several tidbits about this whole endeavor.

First, this was a "black-ops" project. That is to say, I consulted no one before launching into this. I did not go to the public and ask their opinion. I did not go to my colleagues and solicit their input. I did not float this in committee. I didn't get any official authorization to do it. In fact, the whole thing flew under the radar from its conception through to fruition, which took exactly four days. In many ways, it was a spur-of-the-moment project that I did to keep busy during a few relatively quiet days. Sometimes, you need to throw caution to the wind and just do it.

Bear in mind that the only place this service was advertised was on this blog (where, admittedly, it was subsequently picked up by several others). I did not announce it to AADL staff--I let them discover it on their own. Many probably still don't know it's there. When you look at the numbers, know that they reflect those who either read about the cards on a blog or stumbled across it during their course of regular business.

It was a very fun little project, but the real value was that I could slip it into production very quietly and let it act as a proof-of-concept for some very real, very large changes I want to do to our OPAC (which I definitely need authorization for). Essentially, I wanted to answer a very simple question:

Is the public ready for a social OPAC?

What I found indicates something very special, indeed. In fact, as time progressed, I began double-checking my methods which consisted of a simple laundry list of basic queries, which I'll describe. As you can see, I only have 7 collection dates and they are not at regular intervals so the growth rates represented are a little deceiving, but as I've said before, this is very unscientific--I'm definitely no statistician! The results, however, are real.

The first graph here (above) is the simplest of all. It's the total number of marginalia comments in the system over time. The query was simply:

SELECT COUNT(*) FROM cc_marginalia

The count for each date, respectively is: 35, 107, 160, 413, 593, 634, 790. You can clearly see that the number or cards being marked up is experiencing a steady climb. I actually am not terribly surprised by this, but for an unadvertised service, it's still much higher than I had expected or hoped for.

Now, marking the cards up is one thing--it's a fire-and-forget process, it doesn't even require a user to be logged in. Adding a card to a collection is another. Adding a card requires that a user be logged in to a valid account and represents, what I consider, a higher participation factor. This means that users are not only adding marginalia, but they are taking advantage of the ability to build card catalog collections. To me, this is really exciting stuff because it tells me that a) the service is useful and b) there is a market for this kind of stuff in a library setting. FYI, the query for this data is:

SELECT COUNT(*) FROM cc_savedcards

The data for the preceding graph dates is 8, 43, 66, 82, 216, 320, 388.

If you're interested, you can take a look at my saved cards. In addition to knowing how many cards were being added to collections, I needed to know how many people were collecting cards. This is where I really started to feel my pulse quicken. These numbers told me that, despite a lack of advertisement, a substantial number of people were building card catalog collections. I have to be honest and say that I was expecting only 20 to 30 users participating after three weeks. As of 2/11, however, there were 75 users building collections! Check out the growth over time: 2, 6, 22, 42, 58, 62, 75 for each date respectively. Of course, to put that in perspective, we have 20,955 registered users on our Drupal site as of 2/14--our regular users are an extremely small fraction of that, however. To get this data, I ran the following query:

SELECT COUNT(DISTINCT(uid)) FROM cc_savedcards

So... How many of those users not only started to build card catalog collections, but opted to share their collections with the world? I was blown away by these results. Simply amazing: virtually every person to create a card catalog collection also opted-in to sharing it. To me, this speaks volumes about the types of services our users want and it tells me that a good number of our library users want to interact with each other--a vital ingredient if you want a social OPAC. It also sheds a little light on the sophistication of our users--a lot of them are already Web 2.0-aware and will be sensitive to new services like this. Our commercial counterparts are doing a great job of softening the market for us--now all we have to do is provide the tools on our systems.

There is a very good chance I'm overlooking something here--if there is a metric you'd like to see me add, please ask for it and if it's feasible, I'll do my best to provide it.

Our users are smart, clever, interesting, positive, intuitive, and social. They may not know it yet, but they're waiting for their public libraries to be a catalyst for the community. There is something wonderfully special and intimate about shared experience--that is why Web 2.0 is so successful. When those experiences are centered around books, movies, and music and they're aggregated at the local level, the product becomes highly personal--how inspiring would it be to have patrons who are proud of the job they've done for their library?

NOTE: The above graphs were created using the open source graph library, jpgraph.

[Update 4/16/2006 2:42PM]
Somehow, this post got flagged as "private" .. Odd. Very odd, but fixed now.
[/Update]

[tags]Web 2.0, Virtual Card Catalog, Library 2.0, Programming, Library, AADL[/tags]

First, this code is written for use with III's XMLOPAC and requires my PHP XMLOPAC class. That said, an astute PHP coder could easily port this app and make it usable on another system (I heartily encourage that). Someday, I plan to make it completely generic so that all you need to do is pass it the data itself. I'm a little busy at the moment, however.

I am not releasing the card stock images that AADL uses. There was no license info associated with the original images. Until I can contact the folks at UPenn and find out what the deal is, I'm not going to make them available. It'd be very easy to create your own stock, however.

Same deal with the fonts. I was able to freely download them--so should you.

At present, this code is really meant for developers, it is not a "package" that will work out of the box. You must know what you're doing in order to get this going.

I'm releasing it under GPL for all the world to use freely, forever and ever.

Included in the tarball is a README file with some basic instructions. Be sure to read that before emailing me your questions.

Enjoy. I'm looking forward to some possible creative uses. Please email me if you get it working as I'd love to see what you're doing with it. If you come up with a particularly interesting use, I'll be sure to showcase it here.

[tags]PHP, Programming, Virtual Card Catalog, AADL, Web 2.0, Library 2.0, Open Source[/tags]

In addition, I've included an XSLT file written by David Walker which I've modified slightly. It allows me to easily extract subject headings from the XML, so yes, this class now will return an array of subject headings!!

So, be sure to download the latest version. As always, you can grab it anytime from the files section.

When last I wrote about this, it was little more than a working proof-of-concept, but I've been working on it a lot this week--partly driven by DaveyP's experiments and Ed's tinkering, but mostly because I've been planning to do this for a long time now.

So, to cut to the chase:
PatREST now provides an easy, RESTful URI to do searches on quite a few fields. Essentially, you will plug the search key into the URI, followed by the search term. You can also request optional paging for keyword, author searches by appending hits-per-page and page-# to the URI. It looks like this:

http://www.aadl.org/rest/search/[searchkey]/[searchterm]/[hits-per-page]/[page-#]

The following search keys are available:

title
author
callnum
keyword
subject
gvtdocnum
stdnum (ISBN/ISSN)
titlekey
controlnum
barcode
record (Bib #)
bibnum (Bib # - Same as record)
itemnum

Go ahead and try this keyword search. It'll look something like this:

You'll notice that the XSLT stylesheet presents it nicely, all the data may not be displayed, but the XML is sound. Go ahead and view source to examine the schema. I've departed quite a bit from my original schema in order to provide a little bit of metadata for processing purposes. The XSLT allows you to click on a title which will take you to another RESTful record:

You'll notice that the URI for this record looks like /rest/record/1035670/ ... It's /rest/record/[bibnum]/. The XSLT allows you to click on either the title or cover image to go to the regular OPAC record. Again, view source for the XML schema. This schema has changed little and you'll notice that I'm taking advantage of OCLC's xISBN service.

The real treat in all this, however, is the ability to access your personal records RESTfully. To do this, I make use of the RSS token that is provided to every cardholder who has registered for an online account. This is the token that authenticates RSS readers against our system. It is a 32 character MD5 hash that looks something like "316928e0d260556eaccb6627f2ed657b". Accessing personal data is as easy as using the following URIs:

For checkouts, you would use /rest/checkouts/[token] (ie http://www.aadl.org/rest/checkouts/316928e0d260556eaccb6627f2ed657b). You'll then get output at looks something like:

For holds, the URI is /rest/holds/[token]. Output looks like:

Both of those results allow you to click on the bibnum and access the REST record for that item. Again, check the XML schema with your browser (no point in putting it here).

Please hack away at this and send me your comments/suggestions. You're absolutely correct that it doesn't adhere to any existing standard, but that's because I didn't want it to.

On a slightly less geek-oriented note...

I've gone several rounds with Talis's Richard Wallis before, so I want to call your attention to a post he made the other day in which he suggest that a) DaveyP and I collaborate and b) I/we consider using industry standards. I'd like to respond by saying that Dave and I have been communicating extensively. Ed Vielmetti has been involved as well.

Richard writes:

I encourage John, Dave, and those that follow them to take a look at these standards like we have

I can't speak for Dave, but I'm very familiar with these standards and so is Ed. I think Richard is completely missing the point of this whole project which is to put a friendly, accessible, and useful development interface into the hands of patrons. Ed offers just a small example of the type of features that existing standards don't readily make available:

Already there is a lot more useful function in it than you can get in SRU, e.g. permalinks for card records and a sensible way to get item availability.

Bear in mind, that comment was made prior to my work with RESTful holds and checkouts, which, as far as I know, don't even have a standard XML schema--I don't think it's been done before! (I'd love to be corrected on this) This project will also evolve to the point where holds can be placed RESTfully, items renewed, fines paid. It'll also extend to our other features like checkout history, wifi device management, personal card catalog management. Adding this functionality is not only going to allow the public to develop highly useful applications, but it'll be a framework by which we ourselves can build new services in-house. Vendor's obviously haven't stepped up to this, so we are--and we believe in our patrons. They deserve this kind of access to their public library.