Review of "LibData to LibCMS: One Library's Evolutionary Pathway to a Content Management System"

Review of "LibData to LibCMS: One Library's Evolutionary Pathway to a Content Management System," by Paul F. Bramscher and John T. Butler, in Library Hi Tech, Volume 24, Number 1, 2006.

In this article, Bramscher and Butler chronicle and analyze the evolution of the University of Minnesota Libraries (UML) website during the period 2003-2005. In 2003, the UML website was no longer comprised of static HTML pages, but based upon a data repository of 40 relational database tables. The software application used to manage this repository was LibData. The UML developed a succession of software applications ("authoring mechanisms") with which content could be created from the databases and published on the UML website. The first of these authoring mechanisms (Research QuickStart) allowed authors to utilize relational database functionalities, but provided limited options for content presentation. The second authoring mechanism (CourseLib and PageScribe) added course-support functionality, and style options through cascading style sheets. The third authoring mechanism (LibCMS) allowed for a greater variety of content to be published, including HTML, server-side scripts, XML, and RSS.

The authors refer to evidence in the literature that the failure rate of content management systems (CMS) is high. (Of course, the failure rate for information technology projects generally is high. See the Chaos Report of the Standish Group at http://www.projectsmart.co.uk/docs/chaos-report.pdf.) The authors caution against having unrealistic expectations for a CMS as a cure-all for a library's challenges or "slam-dunk transformative technology." Similar caution was echoed in John Blyberg's Drupal presentation at the Summer 2007 American Libraries Association Convention. The authors state that a CMS should be expected to facilitate the customization of web pages, the management of the uniformity of web pages, and the publishing of content (especially by staff without web developer expertise.)

The authors ingeniously formulate a triangular relationship diagram from the term "content management system." Using this formulation, they diagram tensions and dynamics inherent to the development and management of a CMS. Such tensions include those between content and systems (database normalization and certain cases of query efficiency,) and those between management and systems (the ecology of other systems, including operating systems, server upgrade cycles, and organizational security and authentication requirements.) Other challenges seem to fall outside the "content, management, system" triangle. Understanding the realities of the local social context (for instance, who performs what work) is important for the successful implementation of a CMS.

The authors detail the factors considered in determining whether to use an open-source CMS or to buy or outsource one. The factors considered will be familiar to those acquainted with the issue, and I will not detail them here. Generally, the arguments for open-source related to flexibility and control, and the arguments for buying or outsourcing related to convenience.

The UML CMS project began with the identification of requirements for the system, resulting in a list of less than ten core requirements. Core requirements included a versioning mechanism, a draft area, a simplified publishing routine, server-side and client side programming language support, breadcrumb navigation and sitemap, a self-indexing mechanism, secure sockets layer (SSL) protocol support, and ease in building application programming interfaces (APIs.) Weakness analysis was performed to identify deficiencies or non-desirable features of system models. The CMS the UML chose was LibCMS.

The UML made several design choices in the development of LibCMS. One design choice was to leave the root node of the system unused, which allowed for the system to be scalable to other libraries in the UML system. Another design choice reducing the occurrence of broken URLs was to disassociate URLs from file system structure. LibCMS incorporated server-side markup routines using PHP and Apache server to display links to navigation, associated pages, database resources, and other CMS. LibCMS was designed to convert all page source code to Base64, an encoding scheme which allowed the databases to process a great variety of characters, including foreign character sets, quotes, and double quotes. The description of the self-archiving feature of LibCMS was interesting. LibCMS opens an HTML socket to retrieve web pages it sends as they would appear to the clients. LibCMS then strips the pages of HTML tags and client-side scripts, compresses trailing and leading spaces, and inserts the results into a database field.

I think this article effectively detailed many issues involved with planning and developing a CMS in a large research library. The complexity and scope of issues involved might give me pause when inclined to criticize a library website. Many of the technical concepts presented were challenging but particularly interesting.