I wish I could show you examples of exemplary academic library Web sites, but I can't. There aren't any. Yet.

Sure, some sites are pretty good. I frequently suffer from Web site envy. But our sites still follow a model developed a decade ago.

I've already weighed in on the ideal library 2.0 academic library Web site. In a nutshell, this would be a wiki-based site that also included blogs as well as regular Web pages.

I would love to see a piece of software that handles all of this within a single, full-featured content management system. I don't know of such a package. There might be some out there that are vastly expensive - which is why I don't know about them. On the open source front, Plone, Drupal and their ilk are strong in some of these modules, but are incomplete.

The scenario I envision is an obvious departure from years of accepted practice, and we librarians have a thing for accepted practice. This is a major reason why the concept of Library 2.0 has gained traction: we're hidebound and need to get ourselves moving in order to stay relevant with today's users. Look around you. Our library sites are all pretty much the same. Some may be better designed than others, some may offer more useful services, and some may feature a certain level of customization, but none are community-oriented, participatory Web 2.0 sites.

Transforming our Web sites will be far from easy. Based on a decade of Webmastering in academia, I've got a few thoughts on moving forward now.

• Look outside the library world for forward-thinking models. Models for interactive, participatory, community-based Web sites won't be found in the library world. Go out into the Web 2.0 world for inspiration.
• Lighten up about your site. This may seem like an odd thing to say, but think about it. Sure, our sites are a branch library, a front doorway, our public face to the world. But we take our sites too seriously. When we do that, major changes to the site become too important. When something becomes too important, positive change can get discussed to death, compromised, delayed, or nixed. We've got to relax. Most of our users are comfortable with sites that undergo frequent change, are informal, and tolerate - if not feature - experimentation. Why should our sites be different? You can tell me that library sites are about serious business, and I'll reply that a hands-off, spiritless Web site does nothing to enhance use of the library.
• Introduce new initiatives in beta. Beta can be the secret to your success. Conversely, a standard of near-perfection can sink your momentum. A Web site presents us with the essence of a technology-based service that invites experimentation to meet our users' evolving expectations and needs. Betas invite feedback, and feedback encourages our responsiveness to users. If something doesn't quite work out, so what? The ramifications will be far less dire than you imagine. Get feedback and fix the problems, or take the thing down. But learn from your experience and move on.
• Fight off campus-wide design mandates. I'll admit, this is easier said than done. You'll need intrepid leadership from your dean/director to fight this off. There's nothing worse than being forced to constrict your design to something thought up by marketing staff who have the mistaken notion that if everything looks the same, then their campus is branded and the money will flow in. Ironically, if they'd let their library fulfill its mission and take its site into the future, their fund-raising efforts would be that much easier.
• Put your Web pages in a content management system. Most of our sites are complex enough to need hosting on a content management system. Template-driven site management is the way to go for efficient, modular upkeep. We shouldn't be creating Web pages from scratch within an integrated Web site. It's a waste of time. Contributing to the Web site should be as easy as creating a blog entry. I agree with Jack Maness that Webmasters will be replaced by blogs, wikis and RSS in a Library 2.0 world. I would also add, by other types of content management systems, too.
• Stop worrying about your code. I've fallen into this trap as much as anyone else who is code-happy. A baseline of XHTML 1.0 Transitional is not difficult to achieve, and use of CSS is recommended for flexible design and ease of updating. Most content management systems already offer this. Beyond this, don't fuss. If you enjoy the challenge of learning new coding techniques, and have a good reason to use them, fine. Otherwise, take it easy and concentrate on new services and content.

• Design your site for mobile computing. When it's time for your next site redesign, make this a priority. It will take you into the future. I'm also hoping for mobile-enhanced blogs and wikis.
• Ease into change. Not ready to turn over some of your public Web pages to a participatory wiki? Put your staff site on a wiki first. Not sure about blogging a service? Blog a staff service before blogging a public one. But then move on and use these initiatives in the public sphere.
• Maintain nimble and effective policies. Policies for staff Web developers are important, because we need standards for professional publishing of any kind. Keep you policies simple and flexible, and update them frequently. It's unhealthy to let problematic or outdated policies fester without addressing them. This can easily degenerate into a blame game. The site is about our users, not about us. We need to keep our eye on the ball.
• Put your most innovative staff to work on the site. You probably know who they are. Find the creative, the knowledgeable, the skilled, the forward-thinking and the brave, and ask them to coordinate the site. Departmental or branch library representation is irrelevant. Go for individuals.
• Acknowledge the limitations of the library's site. That's right. Until our sites are transformed, you can't expect them to be our users' first choice as a research tool. Accept this, and do something about it.