Content Management for the Library

At MPOW we’re hoping to migrate the library’s static HTML web site to the Drupal CMS. We’ve been using Drupal successfully for a year and a half for an offsite affiliate project and for a SEPA grant-funded project.  We have access to develop the current site using .NET when we want, but we don’t have the resources to do any significant development. Lack of PHP (and MySQL) support on campus is the only thing that has kept us from making the jump to Drupal.  While we have an ample ‘Nix VPS to host it on, I’m concerned that we don’t have the resources to maintain and update Apache or the PHP and MySQL frameworks.

Our current Drupal projects are hosted on inexpensive shared hosting which has been mostly sufficient for what we need including shell access, SVN, CVS, and Apache .htaccess capability. I don’t have to worry about updates to Apache, PHP, MySQL, or the OS.  If we were to host the library’s web site offsite as well, I’d want the best of both worlds: reliable support, a managed environment, dedicated RAM and processor cycles, but also full access to Apache’s httpd.conf.  Pair Networks is attractive for all these reasons. Also, our current host doesn’t support Java/Tomcat/Jetty which means we’d still have to host Solr separately on campus and manage access to it from other applications. Tomcat or Jetty support on the same host would be nice, but it’s not a deal-breaker.

Why do we want to migrate to Drupal? For many of the same reasons hundreds of other libraries and thousands of organizations do:

• a huge, and growing, user community,
• an overwhelming number of user-contributed themes and modules that extend Drupal’s core functionality,
• Drupal’s flexibility for modeling and displaying content,
• Drupal’s taxonomy and tagging support.

But these are all means to the end. In the end, we want our web site to deliver information well and make it easy for people to find what they want or learn how to get what they want.  David Lee King, Topeka’s Digital Branch Manager, recently offered 10 reminders that we strongly identify with.

Based on our experience with Drupal so far and conversations we’ve been having for a long time, here are some things we want to do.

• Make it easier and more enjoyable for our staff to post or update content to the web site.
• Improve how we provide news about library resources and services. Patrons can subscribe by email or RSS to various “channels”, e.g. type of content, subject, author.
• Advertise “featured” content and give our “marquee” an extreme makeover that showcases what’s happening.
• Create subject guides and more audience-oriented channels of content without unnecessarily duplicating content. Example, “you’re into pathology? Here are the best available resources for you. Oh, and here’s what’s new in PubMed and here’s a librarian to contact. In the hospital? Sure. Here’s the set of online clinical resources, image collections, and what we have on the shelves.”
• Integrate metadata from Voyager, the institutional repository (DSpace), and Serials Solutions using the Extensible Catalog Drupal toolkit to create a better discovery layer across all our resources, i.e. open up the silos.… And to put it into context with the rest of our content.
• Integrate content from other sites.
• Manage FAQ’s.
• Improve library instruction, i.e. “where-to-find, how-to-use”, without duplicating content.
• Encourage conversation and feedback by giving patrons the ability to comment on the web site or in whatever social network(s) rule the day.
• Distribute content between multiple “affiliated” sites, between the Library web site and project/partner sites.
• Support mobile devices.

We’re confident we can accomplish them with Drupal (and yes, Solr) in a relatively short amount of time.