We were asked to skim a special issue of Library Hi Tech on content management systems (Vol. 24, issue 1, 2006), pick an article, summarize it, and discuss it.
First a few notes about the special issue: almost all the articles contained case studies of libraries and their processes in selecting a CMS system (either open-source, proprietary, or developed in-house), and then implementing that system. I was rather dismayed to find that most of the libraries large and small ended up developing a CMS in-house, because other systems were either too expensive, not flexible enough, or would require the library to jettison too many established workflows and/or already-built in software. The reason this dismays me is that designing and installing a custom CMS in almost every case took extensive programming knowledge and resources outside of the library staff. That tells me that although librarians are increasingly expected to be involved in designing and selecting CMS for their libraries, and although there are many CMS packages out there, implementing a workable CMS without significant outside help is still far beyond the capabilities/resources of most library staff.
For example, Matt Benzing’s article “Luwak: a content management solution” documents how the Rensselaer Research Libraries in Troy, New York, were able to adapt and extend a piece of software that had already been developed at its associated institution, Rensselaer Polytechnic Institute. Prior to adapting that software, the libraries had been using DreamWeaver to develop its web pages, which provided some “design consistency” but did not provide enough flexibility in content management nor enough access control to avoid the occasional “misstep by a librarian new to HTML” resulting in the accidental erasure or overwriting of web pages (9). The software that they adapted, an “XML-based application” named Luwak, had already been developed elsewhere at the institution “as a solution to the problem of how to adapt web pages for users of PDAs and other handheld devices without having to maintain multiple copies of the same information.” This software already contained the types of functionality the library staff were looking for, but just needed to be extended to the particular uses of the library.
Luwak was implemented using open-source software, written in Java and utilizing a MySQL database. It had already been deployed to manage the campus newsletters and a campus-wide information system. Its ability to control content creation and site maintenance through user roles, to separate content from format and reformat content on the fly, to validate content before posting to the site, and to allow timed updates made it useful for the library as well. The developers were not the librarians, but the technical staff at the Institute; the IT librarian developed the style sheets for the site. Since the new system resided on a separate server, they were able to develop the new library site in Luwak without disturbing the old site. The other librarians were quickly on board with the switch, as most of them just wanted to generate content and did not want to be involved with the formatting or site design. The implementation and switch over went smoothly. The article concludes that “Further work needs to be done on providing a useful on the fly stylesheet for handheld devices, and in exploiting some of the design and functionality capabilities of the system, such as providing collapsible hierarchies of links, multiple page skins, and the importation of library news bulletins into an RSS feed. The website as it now stands is more flexible, efficient, and consistent than it has ever been” (13).