selectiNG A weB coNteNt MANAGeMeNt sYsteM For AN AcADeMic liBrArY weBsite | BlAcK 185 others. The OSU Libraries needed a content management system (CMS). Web content management is the discipline of collect- ing, organizing, categorizing, and structuring information that is to be delivered on a website. CMSs support a dis- tributed content model by separating the content from the presentation and giving the content provider an easy to use interface for adding content. But not just any CMS would work. It was important to select a system that would work for the organization. The focus of this article is the process followed by OSU Libraries in the selection of a web CMS. Other aspects of the project, such as the creation of the user focused information architecture, the redesign of the site, the implementation of the CMS, and the management of the project are outside the scope of this article. ■■ Literature Review Content and Workflow Management for Library Web Sites: Case Studies, a set of case studies edited by Holly Yu, a special issue of Library Hi Tech dedicated to content man- agement, and other articles effectively outlined the need for libraries to move from static websites, dominated by HTML webpages, to dynamic database and CMS driven websites.1 Each of these works noted the messy, unmanageable situation of the static websites in which the content is inconsistently displayed and impossible to maintain. Seadle summarizes the case well when he wrote “a content management system (CMS) offers a way to manage large amounts of web-based information that escapes the burden of coding all of the information into each page in HTML by hand.”2 A CMS provides an interface for content providers to add their contributions to the website without requiring knowledge of HTML; it separates the layout and design of the webpages from the content and provides the opportunity for reuse of both content and the code run- ning the site. These features of a CMS permit a library to professionalize its website by enforcing a consistency of design across all pages while at the same time increasing efficiency by making the maintenance of the content itself less technically challenging.3 The potential of the CMS is powerful, yet it is not an easy process to select and implement a CMS. One chal- lenge is that the process of selecting and implementing a CMS is not a fully technical one. The selection must be tied to the goals and strategy of the library and parent Elizabeth L. Black Selecting a Web Content Management System for an Academic Library Website This article describes the selection of a web content manage- ment system (CMS) at the Ohio State University Libraries. The author outlines the need for a CMS, describes the system requirements to support a large distributed content model and shares the CMS trial method used, which directly included content provider feedback side-by-side with the technical experts. The selected CMS is briefly described. I magine a city that has been inhabited consistently for hundreds, perhaps thousands of years. Those arriving in the city’s main port follow clear, wide paths that are easy to navigate. Soon, however, the visitor notices that the signs change. They look similar but the terms are dif- ferent and the spaces have an increasingly different look. Continuing further, the visitor is lost. Some sections look drastically different, as if they belong in an entirely differ- ent city. Other sections are abandoned. The buildings at first seem occupied, but upon closer inspection all is old and neglected. The visitor tries to head back to the main, clear sections but cannot find the way. In frustration, the visitor leaves the city and moves on, often giving up the mission that led to the city in the first place. This metaphor describes the state of the Ohio State University (OSU) Libraries’ website at the beginning of this project. The website has many content providers, more than 150 at one point. These content providers were given accounts to FTP files to the web server and a variety of web editors with which to manage their files. The site consisted of more than 100,000 files of many types: HTML, PHP, image files, Microsoft Office formats, PDF, etc. The files with content were primarily static HTML files. In 2005, the OSU Libraries began to implement a PHP-based template that included three PHP statements that called centrally maintained files for the header, the main navigation, and the footer. The template also called a series of centrally controlled style sheets. The goal was to have the content providers add the body of the pages and leave the rest to be managed by these central files. This didn’t work as intended. Because of a combination of page editing prac- tices learned with static HTML and a variety of skill with cascading style sheets (CSS), many pages lost the central control of the header, menu, and footer. Also, the template was confusing for many because they had to wade through a lot of code they didn’t understand. One part of this con- tent model was right—giving the person with the content knowledge the power to update the content while centrally controlling parts that should remain consistent throughout the website. Unfortunately, the technical piece of the model didn’t support this goal. It required too much technical knowledge from the content providers. The real solution was a system that would allow the content providers to focus on their content and leave the technical knowledge to elizabeth l. Black (black. 367@osu.edu) is head, web Imple- mentation Team, Ohio state university Libraries, Columbus, Ohio. 186 iNForMAtioN tecHNoloGY AND liBrAries | DeceMBer 2011 and interviews/focus groups with the current content providers. The research was similar to that described pre- viously in the literature review section of this article. The most helpful for this project was a 2006 issue of Library Hi Tech focused on CMSs.10 The most useful of these articles was Wiggins, Remley, and Klingler’s article about the work done at Kent State University, particularly the way in which they organized their requirements.11 A working group of four served as interviewers for the focus groups with current web content providers. They worked in pairs, with one serving as a recorder and the other as the facilitator, who asked the questions. Fifteen interview sessions were held over a period of three months. The focus group participants were invited to participate in like groups as much as possible, so for example the foreign language librarians were interviewed together in a different session from the instruction librar- ians. However, no one participated more than once in an interview. The same set of guiding questions was used for each interview. They are included in the appendix. The results of these interviews became the basis for the requirements document to which the technical team added the technical requirements. ■■ The CMS Requirements The requirements were gathered into five categories: content creation and ownership, content management, publishing, presentation, and administration/technical. These categories were modeled after those used for the project at Kent State University.12 The full list is detailed below by category. content creation and ownership requirements ■■ Separation of content and presentation: the content owners can add and edit content without impact on the presentation ■■ Web-based GUI content-editing environment that is intuitive and easy to learn without knowledge of HTML ■■ Metadata created and maintained for each webpage or equivalent content level that contains: ■❏ Owner ■❏ Subject terms or tags describing the content ■■ Multi-user authoring without overwriting ■■ Can handle a large number of content providers (approximately 200) ■■ Can integrate RSS and other dynamic content from other sources ■■ Can handle different content types, including: ■❏ Text ■❏ Images organization, must meet specific local requirements for functionality, and must include revision of the content management environment, meaning new roles for the people involved with the website.4 Karen Coombs noted that “the implementation of a content management sys- tem dramatically changes the role of the web services staff” and requires training for the librarians and staff who are now empowered to provide the content.5 Another challenge was and continues to be a lack of a turn-key library CMS.6 Several libraries that did a sys- tematic requirements gathering process generally found that the readily available CMSs did not meet their require- ments, and they ended up writing their own applications.7 Building a CMS is not a project to take lightly, so only a select few libraries with dedicated in-house programming staff are able to take on such an endeavor. The sharing of the requirements of these in-house library specific CMSs is valuable for other libraries in identifying their own requirements. In the past few years, the field of open-source CMSs has increased, making it more likely that a library will find a viable CMS in the existing marketplace that will meet the organization’s needs. Drupal is an open-source CMS that was one of the first viable options for libraries and so is widely used in the library community. It was the subject of an edition of Library Technology Reports in 2008.8 Since Drupal opened the door for open-source CMSs in librar- ies, others have entered the market as well. In 2009 John Harney noted, “There are few technologies as prolific as web content management systems. Some experts number these systems in the 80-plus range, and most would con- cede there are at least 50.”9 The CMS selection process described here builds on those described in the literature by integrating their require- ments and methods to address the needs of a very large decentralized website. It builds on the increased empha- sis on user involvement in technology solution building and selection by fully incorporating the CMS users in the selection process. Further, the process described here took place after those described in the literature, after the open- source CMS field had significantly improved. The options were much greater at the time of this study and this article describes the increased possibilities of second generation CMSs. While there still does not exist the perfect library ready turn-key CMS, there are many excellent, robust open-source CMSs available. This article describes one pro- cess for selecting among them, including an in-depth trial of three major systems: Drupal, ModX, and SilverStripe. ■■ Gathering requirements There were two parts to the requirements gathering pro- cess undertaken at OSU Libraries: research of the literature selectiNG A weB coNteNt MANAGeMeNt sYsteM For AN AcADeMic liBrArY weBsite | BlAcK 187 ■■ Meets established usability standards ■■ Dynamic navigation generated for main and sub- sections of website that includes breadcrumbs and menus ■■ Searching ■❏ Search engine for website ■❏ Can pass searches on to other library web servers ■■ Mobile device friendly version (optional) ■■ Delivery presentable in the browsers used most heav- ily by OSU Libraries websites visitors ■■ Page load time is acceptable ■■ Easy search engine optimization Administration ■■ LAMP (Linux, Apache, MySQL, PHP) platform ■■ Good documentation for technical support and end users ■■ Scalable in terms of both content and traffic ■■ Skills required to maintain system are available at OSUL The next step was to take this extensive requirements list and identify CMSs that would be appropriate for a side-by-side test with both content providers and systems engineers. ■■ CMS Trial The web CMS would become a critical part of the web infrastructure so it was important to ensure selection of the best system for both the content providers and the IT team. Between May 21 and August 29, 2008, two groups worked with the CMSs, testing them on criteria taken from the initial requirements documents. The first team included fourteen content providers with diverse content areas and diverse technical skills; this group rated each system on a content providers set of criteria. The second team, which included the systems engineer and a technical support spe- cialist, rated each system on a set of criteria that was more technical in nature. Each participant used a Microsoft Excel spreadsheet containing requirements condensed from the full list. They rated each system on a scale of 1 to 3 for each criterion, where 1 was difficult, 2 was moderate, and 3 was easy. The project manager in the IT Web Team led the trial. The criteria given to the content providers were: ■■ Web GUI intuitiveness ■■ Media integration ■■ Editor ease of use ■■ Ability to add content ■■ Ability to preview content ■■ Ability to publish content ■■ Metadata storage ■❏ Videos ■❏ Camtasia/Captivate tutorials ■❏ Flash files ■■ Content owners can create tables and/or databases for display of tabular data in the web GUI interface ■■ Content owners can create forms in the web GUI interface ■■ Option for faculty and professional staff to have web- pages featuring their work and their profiles ■❏ All staff must have some control over the per- sonal information available about them on the public website content Management ■■ Link maintenance ■❏ Does not allow internal pages to be deleted if linked to by another CMS page ■❏ Can regularly check the viability of external links ■❏ Periodic reminders to content owners to check their content ■■ Way to repurpose content elements to multiple pages for content such as: ■❏ Descriptions of article and research databases ■❏ Highlight or feature content elements ■■ Access controls ■❏ That allows content owners to only edit their content ■❏ That allow web liaisons to provide first line sup- port for their departments ■❏ Integrates into our existing security structures (Shibboleth) ■■ Robust reporting features ■❏ Integration with quality web analytics software ■❏ Content update tracking ■❏ System usage ■❏ Customized report creation Publishing ■■ Ability to preview before publishing ■■ CMS can produce RSS feeds for dynamic sections of content ■■ Page templates and style sheets are used to control page layout and design centrally ■■ Display non-roman scripts using Unicode ■■ Extensible—can incorporate non-CMS content into the site ■■ Ability to add personalization options for site users Presentation ■■ Meets ADA and W3C accessibility requirements ■■ Code validates to current HTML specifications 188 iNForMAtioN tecHNoloGY AND liBrAries | DeceMBer 2011 on the technical requirement that the system be easy to extend and integrate. A simple website served as the hub for the CMS trial. The site included links to each CMS instance, a link to the project blog for updates from the project team, and a link to a wiki space where trial participants shared ideas and thoughts with one another. The web team’s issue tracking system was integrated into this site so participants could easily ask ques- tions of the technical team and report problems. Time was set aside each week to handle all reported issues. Of the sixteen participants who started the trial, thirteen completed a criteria spreadsheet. The project manager totaled and then averaged the scores provided by each group to determine the overall content provider score and the overall technical score (see figure 1). In the end, both the content providers and the systems engi- neers agreed that SilverStripe was the CMS that best met the requirements. ■■ SilverStripe SilverStripe was released as an open-source CMS in November 2006 by SilverStripe Limited. They had devel- oped the CMS as part of their business of creating websites for clients. The company was founded in 2000 and is headquartered in Wellington, New Zealand. The company continues to use the CMS for their website busi- ness and also offers paid support for the CMS. The testers agreed that SilverStripe provided the best match in the areas of easy content creation by multiple authors, handling multilingual content, management of different types of content and content files, search engine optimization, and meeting web standards. A strong and growing open-source community and strong documenta- tion were additional keys to the selection of SilverStripe.14 Use by high-profile clients, such as the 2008 Democratic National Convention, provided proof that SilverStripe could handle high traffic. The content providers praised SilverStripe for the intuitive user interface, the system’s ease of use, spe- cifically the ease of previewing and publishing content. They also noted that SilverStripe handled the metadata supporting the pages as well as tabular and form page content better than the other systems. The technical evaluators noted SilverStripe’s modular structure, which makes it flexible enough to integrate easily with existing web applications and accommodate local customiza- tions without modifying the core system. SilverStripe includes a template language, which fully separates the content from the presentation. In practice, this means that even informed users cannot spot a SilverStripe website through simple web browsing, as is common with other CMSs. ■■ Ability to “feature items” ■■ Ability to add RSS feeds ■■ Ability to enter tabular data ■■ Ability to create forms ■■ Testing area for new features The criteria given to the systems engineers were: ■■ Installation ■■ Maintainability ■■ Technical documentation ■■ Active developer community ■■ Structure management (subsites/trees) ■■ Access control/permissions ■■ Link management ■■ Ease of extensibility ■■ Interoperability (data portability and web services) The CMS requirements document was used in con- junction with the CMSmatrix (http://cmsmatrix.org) website to select five CMSs to participate in a trial.13 The five systems selected were Drupal 6.2, MODx 0.9.6, SilverStripe 2.2.2, Plone 3.0.6, and TYPO3. The systems engineer installed all five CMSs on a development server and did a simple configuration to make each operational for testing. It was at this stage that Plone and TYPO3 were dropped from the trial because they took too long to con- figure and set up. The goal was to do a simple installation of the base CMS, without any modules, but some systems were not functional as a CMS without some modules so we added modules selectively. At the point of the selection of the systems for the trial, the project leaders noted that the entire list of require- ments could not be met by an existing CMS. They also noted that the majority of the key needs could be met with an existing system. Therefore the goal remained to select an existing open-source web CMS with the emphasis Figure 1. CMS trial scores selectiNG A weB coNteNt MANAGeMeNt sYsteM For AN AcADeMic liBrArY weBsite | BlAcK 189 Web Guides in a Content Management System,” Library Hi Tech 24, no. 1 (2006): 29–53; Yan Han, “Digital Content Management: the Search for a Content Management System,” Library Hi Tech 22, no. 4 (2004): 355–65; David Kane and Nora Hegarty, “New Web Site, New Opportunities: Enforcing Standards Compliance within a Content Management System,” Library Hi Tech 25, no. 2 (2007): 276–87; Ed Salazar, “Content Management for the Virtual Library,” Information Technology & Libraries 25, no. 3 (2006): 170–75. 2. Seadle, “Content Management Systems,” 5. 3. Huttenlock, Beaird, and Fordham, “Untangling a Tangled Web”; Kane and Hegarty, “New Web Site, New Opportunities”; Salazar, “Content Management for the Virtual Library.” 4. Holly Yu, “Library Web Content Management: Needs and Challenges,” in Content and Workflow Management for Library Web Sites: Case Studies, ed. Holly Yu, 1–21 (Hersey, Pa.: Information Science, 2005). 5. Karen Coombs, “Navigating Content Management,” Library Journal 133 (Winter 2008): 24. 6. Yu, “Library Web Content Management,” 10. 7. Goans, Leach, and Vogel, “Beyond HTML”; Salazar, “Content Management for the Virtual Library”; Rick Wiggins, Jeph Remley, and Tom Klingler, “Building a Local CMS at Kent State,” Library Hi Tech 24, no. 1 (2006): 69–101; Regina Beach and Miqueas Dial, “Building a Collection Development CMS on a Shoe-String,” Library Hi Tech 24, no. 1 (2006): 115–25. 8. Andy Austin and Christopher Harris, Library Technology Reports 44, no. 4 (May/June 2008). 9. John Harney, “Are Open-Source Web Content Management Systems a Bargain?” Infonomics 23, no. 3 (May/June 2009): 59–62. 10. Library Hi Tech 24, no. 1 (2006). 11. Wiggins, Remley, and Klingler, “Building a Local CMS at Kent State.” 12. Ibid. 13. CMS Matrix, “The Content Management Comparison Tool,” http://cmsmatrix.org/ (accessed Aug. 16, 2010). 14. SilverStripe.org, “Open Source Help & Support,” http:// silverstripe.org/help-and-support/ (accessed Aug. 16, 2010). ■■ Conclusion An academic library website is a complex operation. The best ones use the strengths of the organization to their fullest: give web content authors direct access to maintain their content without burdening them with the require- ment of technical expertise in HTML. Excellent sites also offer a consistent user experience facilitated by centrally managed presentation. A web CMS facilitates this model. The selection of a web CMS is not solely a technical deci- sion; it is most effective when made in partnership with the web content providers. The process followed by OSU Libraries described here provides an example of one such selection process. ■■ Acknowledgements The author thanks James Muir and Jason Thompson for their thoughtful contributions to this article and their exceptional work on the project. None of it would have been possible without them. References 1. Holly Yu, ed., Content and Workflow Management for Library Web Sites: Case Studies (Hersey, Pa.: Information Science, 2005); Michael Seadle, “Content Management Systems,” Library Hi Tech 24, no. 1 (2006): 5–7; Terry L. Huttenlock, Jeff W. Beaird, and Ronald W. Fordham, “Untangling a Tangled Web: a Case Study in Choosing and Implementing a CMS,” Library Hi Tech 24, no. 1 (2006): 61–68; Doug Goans, Guy Leach, and Teri M. Vogel, “Beyond HTML: Developing and Re-imagining Library Appendix. Content Provider Focus Interview Questions Each group interview included a series of questions, which could be modified depending on the direction in which the interviews progressed. These are the questions provided to the interviewers: 1. Who is your audience? 2. How do you teach/communicate with each audience? 3. What types of information are you trying to communicate? 4. How dynamic or static is the information? 5. What are the most important resources in your discipline? 6. Who do you teach most frequently? Undergrads, grads? 7. Where do you start your instruction: with library.osu.edu or the department? 8. How do you connect the users/audience to your resources? 9. What message do you want to deliver? 10. What is unique about your discipline/ needs/ department? 11. What would make things easier for you?