"This is my website. There are many like it, but this one is mine..."

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]