Final report

Web Content Management Discovery Project, Dartmouth College — 2002

Executive Summary

Introduction

Over the past two months, an ad hoc group of Web production staffers from Computing Services and the Library have gathered to research and evaluate Content Management System (CMS) products and services that could help us automate the Web site maintenance process.

We found that there are two primary methods used by Content Management Systems to deliver a Web experience to users. Some CMS services gather “chunks” of content, such as text and media, and store them in database repositories. Then, they assemble those content pieces on demand when requested by a user’s browser.

The other commonly-used method is to post text, images, and other media files on a standard Web server that responds to requests and delivers those files to the user. Content authors make changes to those files via an intuitive interface that masks the complexity of the underlying technologies.

Using the first method — assembling information from multiple enterprise databases such as Banner and Advance via a single Web presence (“portal”) — is an excellent use of dynamic Web page assembly and many systems.

Nevertheless, the dynamic assembly of Web content is expensive, complex to implement, takes time due to custom programming requirements, often maintains content in proprietary formats, and requires special techniques to make sure the speed of page delivery isn’t reduced. Although Computing Services staff members are currently investigating this type of content management for a portal for internal audiences such as students, faculty, and staff, there is currently no firm time frame for deployment.

Given our short timeline (implementation within six to nine months) and a tight budget, our discovery project focused on systems and tools that would support the second method: providing a simple user interface to file-oriented Web delivery. This kind of tool would allow content to be easily created and maintained on standard file servers in formats that can be integrated into a dynamic delivery process in the future. The costs are also much lower.

Also, although the group concentrated on the needs of Computing Services and, to a lesser extent, the Library, scalability to a larger number of clients was always kept in mind, with the assumption that the successful implementation in Computing would pave the way for expansion to other sites under management by Computing, the Library, and the Office of Public Affairs.

Evaluations

We evaluated four vendor products that fit into the desired price range and feature set. All four provided a very similar level of administrator functionality, interface simplicity, and Web standards support, rating from 80 percent to 87 percent of a potential perfect score. We were prepared to recommend one or two for an in-depth presentation to the area representatives group.

Resources

Based on information from vendors, we estimated the start-up costs and sustaining personnel requirements for the first year of site redeployment for the following options:

• Licensing a Web page editing tool
• Licensing an Off-campus Commercial
• Installing an On-campus Commercial CMS Appliance
• Developing a Custom CMS Application

The deployment costs ranged from $17,000 to $172,600. When we included approximately 300 hours to re-architect and integrate current content into a new site, the totals ranged from $52,000 to $207,600.

Introduction

Over the past six weeks, an ad hoc group of Web developers from Computing Services and the Library have gathered to research and evaluate Content Management System (CMS) products and services that could help us automate the process of creating and maintaining Web sites for our clients.

Since we are aware that other campus Web groups are suffering from the same manual-production bottlenecks, we evaluated scalability, as well as features. A successful CMS implementation in Computing will quickly increase demand for such a system across the campus. We would select a CMS that could handle the added load of between fifty and one hundred additional departments and users.

There are two primary methods used by Content Management Systems to deliver Web experiences to a user. One method is to post text, images, and other media files on a Web server that responds to requests and delivers those files to the user. The second method is to assemble pieces of content — text and media stored in databases or other data repositories — on demand when requested by browsers.

Using this second method to integrate information from multiple enterprise databases — such as Banner, Advance, and Resource25 — into a single Web presence (“portal”) is an excellent use of dynamic Web page assembly, and such systems, including Campus Pipeline and the open source uPortal, excel in this area.

Nevertheless, this dynamic assembly of Web content is expensive ($1 million or more) and complex to implement, often maintains content in proprietary systems, and requires special techniques including page caching and server load balancing to make sure the speed of page delivery (“latency”) isn’t reduced. Computing Services is currently investigating this type of content management for students, faculty, and staff.

With a shorter timeline in mind (implementation within six to nine months), our evaluation focused on systems that support the first method: providing a simple user interface to file-oriented Web delivery. This kind of system allows content to be easily created and maintained on standard file servers in formats that can be integrated into a dynamic delivery process in the future. The costs are also much lower.

Also, although the group concentrated on the needs of Computing Services and, to a lesser extent, the Library, scalability to a larger number of clients was always kept in mind, with the assumption that the successful implementation in Computing would pave the way for expansion to other sites under management by Computing, the Library, and the Office of Public Affairs.

Process

First, the group brainstormed and ranked a list of features that would be preferred in such a product or service.

Then, the group requested presentations from four vendors who fit into a specific profile:

• The vendor has had at least one content management product or service on the market for over two years with implementation by major clients.
• The vendor’s service costs less than $20,000 a year for 20 users for hardware and software (or for an application service license) and could be implemented within six to nine months.
• The service meets many of the top features that the group determined to be important to the Dartmouth Web community.

In parallel with this process, one of the team members worked with the campus Webmaster to develop a work plan and estimate costs to build a similar service in-house.

Evaluation factors

There were several factors we kept in mind as we evaluated Content Management Systems (CMS), and we list them here in order of priority.

Simple Page Authoring and Editing

We wanted to find a system that uses a cross-platform and cross-browser interface and which is simple enough for novice content authors to create, update, and move pages without knowing markup tags, ftp protocols, or other technical information. This was the area where we found the greatest variation between systems. Our ultimate preference was for a CMS that used simple tools (either wizards or toolbars) to prompt users to input page content (text, formatted text, images, other media). Then the CMS would automatically generate standards-compliant code.

Simple Site Administration

Since we were keeping future scalability in mind, we felt it was important for the CMS to be simple to administer, especially in managing multiple sites/subsites, defining users and roles, assigning access to individual sections, creating and uploading page templates, and checking internal links. Authenticating users via Kerberos was preferred, but if Kerberos support was not available, we considered systems which encrypt user interactions (including user names and passwords) via SSL.

Standards and Accessibility

A very important factor was the ability for a CMS to generate standards-compliant pages — using XHTML 1.0 markup and CSS 2 styling and positioning. For example, although page template designers determine the level of support for accessible page rendering, some systems generate code automatically from their WYSIWYG page editors, so we prioritized systems that created code that supports universal design guidelines for accessibility, including prompting for attributes such as alterative descriptions, keyboard shortcuts, and table headers.

Separated Content and Presentation

The CMS should provide a simple process for uploading page templates and CSS style sheets so that all presentation formatting would be separated from text, which would include only very limited mark-up, such as <p>, <h1,…>, <strong>, <bold>, <a href…>, <img>, <embed> tags. The optimal CMS would parse code from rich text editors into validatable XHTML 1 markup. For example, this paragraph consists of the following stripped-down code and all formatting is applied by the template and CSS style sheet.

The benefit of this separation is the ability to define different ways of presenting content, whether on a computer screen, a PDA, or printed.

Workflow Management

We came across two primary models for managing content development workflows. In our preferred model, a predefined workflow process — for sites or pages — people or groups were added to such roles as author, editor, designer, producer, and administrator on a case-by-case basis. This would allow individuals to work in different roles on different sites or pages.

In the other workflow model, people were granted specific permission levels on an individual basis and then assigned, as people rather than as roles, to sites or pages. This prevented varying roles on multiple sections or sites.

Scalability

Two factors affect the ability for a CMS to scale to a larger number of users. One is the system that handles the management interface and the other is the technology that is used to deliver the pages and other media files to the user. We evaluated the user interface for each of these vendors; more details are included with the vendor summaries.

As to the page delivery technology, we preferred that all of the Web site files themselves (pages, images, other media, style sheets, and scripts) reside on staging and production servers within the Dartmouth computing network. This would simplify the integration of existing sites and make it possible to make temporary or emergency changes on pages hosted on campus servers. We wanted to avoid systems that stored content in proprietary databases, unless there was open access to the database for super users.

Nevertheless, we were willing to consider ASP vendors (“Application Service Providers”) that host the authoring and administrative system hardware and software outside the Dartmouth computing network. The benefit of this kind of service is that costs are spread across all of the vendor’s clients, so license fees can be much lower than on-site system administration. There is, however, one potential problem. If Dartmouth’s Internet connection is slow, then the Web author’s experience of the content management system will also be slow. (Of course, so would the users of Dartmouth’s public Web presence!)

CMS scalability is also determined by vendor support and the development environment. Once a determination is made as to the type of CMS to be pursued (off-campus Web service, on-site appliance, or custom development), we will make deeper inquiries as to the dependability and track record for vendors, as well as the robustness and security of the development environment.

Emerging Technologies and Standards

By keeping content and presentation information separated, we will be better prepared for transformation of text into new formats as needed. By selecting a CMS that supports current Web standards — that have moved to a new plateau over the past year — we are ready for one to two years of upcoming evolution.

Speed of Implementation

A key issue we discovered during the evaluations was the simplicity (or difficulty) of integrating existing sites into the CMS. Super users (the administrators responsible for setting up a site) need to have automated methods for bringing large site outlines into the CMS, populating pages with existing content, and adding large numbers of users without resorting to cut and paste. Alternatively, the systems which provided the simplest process stored content on staging servers and allowed access by power users via FTP or WebDAV transfer.

Wish List

There were a number of other features that didn’t rank at the top of the basic evaluation, but would be of value:

• Release embargoes (“go live dates”).
• Import of Word documents, including stripping of “dirty” markup.
• Customizable code generation for media-element markup (QuickTime).
• Automatic generation of navigation elements: Left-side, pathways (“bread crumbs”), section links, previous/next, a-z indices.
• Nested page templates (for common site-wide elements along with section-specific elements).
• XML import and export.
• External link checking.
• The ability to develop custom modules such as discussion groups, calendars, Web-form to e-mail processing, and news (Bulletins/updates/syndication/RSS).

Special Notes

A Note on Open Source Software

In addition to the hundreds of commercial CMS products and services that have been released in the past two years, we are aware of many open-source CMS solutions that are available. Unfortunately, information that would allow us to evaluate those products weren’t available. (Most of the open-source CMS solutions are still in early development and marketing efforts haven’t begun.) In addition, the required level of knowledge of the open-source server tools necessary to customize these solutions would make a six to nine month implementation unlikely. We will, however, keep our eyes open for those solutions that gain speed in the coming months.

A Note on Long-term Site Sustainability

Staff requirements for system administration, user training, and the additional content development that would likely occur when the process of page updates was simplified are difficult to estimate. We have developed recommendations for long-term resources to support the completely-redeployed Computing Services Web site.

A Note on Custom Application Development

In parallel with this discovery project, one of the team members — a Web application developer in Communications Services — worked with the College’s Webmaster to estimate the costs for developing an application that satisfies all of the group’s requested features.

Vendor Evaluations

In October 2002, we evaluated four vendors that fit our desired profile and could deliver products and services that satisfy most of our preferred features. We participated in personalized Web-based demonstrations from each of the top four vendors and requested and received responses to our follow-up inquiries. At that point, we calculated a total score based on how well each product or service satisfied our features list.

We should note that none of these systems included out-of-the-box authentication via Kerberos or LDAP, although one served all pages via SSL encryption to provide security. Therefore, user names and passwords for authors, editors, and designers would have to be entered manually. Given the estimated number of CMS users in Computing — approximately 20 — this would not be a burden. For a larger, scaled implementation, this task would become more time consuming.

Common to All the Evaluated Systems

• Browser-based administration and editing.
• Intuitive user interface.
• Low learning curve.
• Document check-in/check-out.
• Simple file uploading.
• Content history tracking.
• Content management workflow.
• Metadata support.
• Separation of content from presentation using style sheets.
• View staged site prior to approval.

Custom Development Overview

This estimate is based on some key assumptions about the development tools and available resources as our staff understand them. On the development side, the team’s expertise is in one development environment. Using this tool not only leverages their programming skills, but also allows them to take advantage of the tool’s Web site publishing framework, which has been in stable release since 1995. Use of another programming tool/environment is possible, but they would have to get training in the new tool and come up with a way to mimic the publishing framework, replace it with another one that is specific to the chosen tool, or adequately compensate for its absence. They did not try to estimate the time these steps would take.

On the resource side, the 9-12 months duration is predicated on the assumption that from the time the project is approved, 50 percent of one developer’s time and 30 percent of the other’s time will be solely dedicated to the development of the CMS system. Once the system has been developed and tested, it’s expected that upwards of 15-20 percent of one and 5-15 percent of the other will be needed for administration and maintenance.

A more detailed time estimate will be possible, if the build option is approved, when the full interface for the system has been planned and prototyped. Please see the detailed estimate for the current, raw time estimates that were based on the current interface prototype, and the necessary controls and back-end programming to make it work.

Sample Personnel Request

For Developing and Sustaining a Web Site Through Year One

Sustaining a large public Web presence — such as Computing Services’ constellation of subsites with over 1,000 pages and numerous online documents — involves dozens of people, from content authors and editors, to designers and administrators.

Currently, two production processes are used to prepare and post content on Computing Web sites:

• New content is sent to a Web designer who updates static HTML and image files and uploads the new text and image files to the Dartmouth Web server.
• New content is sent to a member of the Communications Services team who updates the current Web publishing system that uploads the new text and image files to the Dartmouth Web server.

In either case, this process is slow because it adds routine manual steps to a production process that can be automated.

We recommend the development or deployment of tools that can automate this process and allow text to be entered and updated directly by content experts. The time currently consumed by manual reformatting could then be better applied to client services, such as user testing, user training, account coordination, page production, and quality assurance, including page checks on multiple browsers to prevent poorly formatted pages from being published.

Therefore, to accomplish the redeployment of the Computing site as envisioned by the Phase 1 project team, we recommend that personnel and technical resources be slightly refocused and redeployed. The difference CMS tools would make is one of scale: resources could be applied to a greater number of users with less effort than manual production currently allows.

Personnel requirements to sustain the first full year of a new Computing Services Web site fall into four categories:

• Web leadership and project management.
• Content development and editorial services.
• Creative, design, and production services.
• Technical and engineering services.

Many of these functions are already being fulfilled by Computing staff. This document covers each of these areas, contrasting current resource levels [in brackets] with estimates for year one needs. The personnel model for this analysis is a report on [intlink id=”4156″ type=”page”]Building a Web Team[/intlink] that is available in the workflow development track on this project Web site (see “related sites” below).

Please note that the following estimates are averages over the first year, assuming 48 work weeks are available for each Full-time Equivalent (FTE) employee.

Web Leadership and Project Management Services

Although some Computing subsites receive high-level attention and are refreshed regularly, there is currently no overall project management provided for the entire Computing Services public Web presence.

The first Web Redesign team recommended a process for seeking input from senior computing directors and division representatives and integrating that feedback into a new architecture and interface for the entire Computing Web site.

In order to accomplish this goal, consistent leadership and project management would be required on a sustaining basis. Although much of the maintenance work can be undertaken by content and production personnel, the cyclical, phase-by-phase process of developing and integrating new features and services into the site needs consistent overview. Also, maintaining open lines of communication to various computing constituents and stakeholders can make sure that up-to-date feedback will keep the site fresh and useful.

Recommendation: 25 percent FTE (~480 hours/year; ~40 hours/month) for Project Manager.

The project manager/producer is responsible for scoping the work, developing the project plan, scheduling, allocating resources, budgeting, and managing the team. Establishes and directs strategic long-term goals, and policies and procedures for on-line content. Deals with political and business issues.

Editorial Services and Content Development

Currently, text for Computing Services subsites is authored by a variety of content experts. In some cases, that content is edited by colleagues, in other cases, it moves directly into production and onto Web pages. In addition, some areas of strategic importance to computing that do not fit within the specific areas of responsibility of content authors are not being developed for the Web.

The first Web Redesign team recommended adopting a user-centric strategy for content and a consistent voice throughout the computing Web presence. Making that goal come to fruition would be the most resource-intensive objective for the Phase 2 project. The most basic requirement is a toolset to automate repetitive manual tasks that will allow some resources to be reallocated to quality assurance. (This function is more fully described in the “Technical Services” section.)

Even with an automation system, however, additional personnel would be required for the development of new content, above and beyond administering the system and updating existing content.

There are two options, depending on resources. One is to re-architect the entire Computing Web presence before relaunch, a large project integrating over 1,000 Web pages, 28 Bulletin topics, nearly 60 help documents (about 5 pages each), myriad printed documents, and thousands of frequently asked questions. In our start-up costs estimates, we included 2,500 hours of content development and production time to integrate all of these documents into a new Web presence (an average of 30 minutes each, including multiple iterations with content experts and new media production). This is the equivalent of one 100 percent FTE for over a year.

Instead of integrating all existing content into a new Web presence before launch, however, we recommend that content be integrated in a phase-by-phase basis. This would allow the top levels of the site, where most missing content and client services entry points are located, to be updated first. Then additional realms of information would be integrated over time.

Therefore, we recommend a cyclical process of new content development by a Web Managing Editor while sections of existing content are being integrated into the Web site by an Associate Editor and Information Architect (see Creative, design, and production services).

Recommendation: 25 percent FTE (~480 hours/year; ~40 hours/month) for Web Managing Editor.

Establishes journalistic style and designs and develops online content. Maintains brand identity and consistent voice among multiple subsites. Gathers input from various internal departments and creates copy to reflect the combined requirements of all groups. Supervises writers, freelancers, and research assistants. Manages schedules, writing, and editing. Coordinates with the production team.

Recommendation: 25 percent FTE (~480 hours/year; ~40 hours/month) for Associate Editor [currently at 25 percent for materials posted to Computing Services external-audience Web sites].

Writes, edits, proofreads, and copyedits a variety of user guides, technical documents, and frequently asked questions for online distribution. Prepares page layouts to position and space text and screens. Assists with functionality testing, including content review and link checking on various hardware, operating system, and browser configurations.

Creative, Design, and Production Services

In addition to improving the editorial quality and consistency of content updates, the site needs to have ongoing attention to information architecture, graphic design, and media production, as well as the creative direction of new media elements — such as feature stories about creative uses of computing resources told using QuickTime movies, Flash presentations, and other rich media.

Recommendation: 10 percent FTE (~192 hours/year; ~16 hours/month) for Web Producer.

As creative lead, the Web producer determines the creative concept for the site and is responsible for the sites’ overall design. The creative lead may not design the site him/herself, but acts as art director for the site. The creative lead interacts with information architects, designers, the technical lead, programmers, and other Web specialists to determine what is possible.

Recommendation: 5 percent FTE (~96 hours/year; ~8 hours/month) for Information Architect.

The information architect understands how to present information intuitively so users can effectively interact with the site and find the information they need. An information architect guides the site architecture, navigation, search objectives, and interaction design via templates and style documents. The information architect is also responsible for key pages regarding errors, service, technical needs of the site, and privacy messages.

Recommendation: 5 percent FTE (~96 hours/year; ~8 hours/month) for Web Designer [currently at 5 percent for Computing Services external-audience Web sites].

The Web designer creates the look and feel of the site, develops Photoshop prototypes to be tested with potential users and, when approved, supervises the translation of graphic design to standards-based markup code. Web designers have a strong understanding of design principles, including information design and interaction design.

Recommendation: 10 percent FTE (~192 hours/year; ~16 hours/month) for Associate Producer.

Assists the producer, and works with the graphic designer on interface design, creation of graphics, and conversions of documents into HTML. Participates in user testing, quality assurance, and competitive analyses. Develops and maintains new media elements for the site, integrating text and graphics with motion video, still images, animation, music, and sound.

Recommendation: 25 percent (~480 hours/year; ~40 hours/month) FTE for Client Support Lead.

The client support lead is the primary contact with clients, from account coordination and user training to page production and quality assurance. S/he trains and supports new clients and provides quality assurance for all page updates submitted by clients, verifying pages work in multiple browsers on multiple platforms. In a manual production process, this person also often provides page production services using standards-based markup.

Technical and Engineering Services

Basic technical services for campus Web site developers are provided at no charge to all groups or persons who are eligible for DND accounts. These services include:

• Account application approval, setup, and maintenance.
• Web server setup, maintenance, and backup.
• Site traffic monitoring.
• Security assurance.
• Network performance.

Current Computing Web subsites are managed by content partners using one of the following processes:

• Producing their own sites and transferring site files to the campus Web server via FTP.
• Contracting with outside firms and transferring site files to the campus Web server via FTP.
• Working with Communications Services to manually update content in the department’s Publishing System.

We recommend the development or deployment of a new process, using content management tools, that would combine central support for Web standards and consistent identity using common templates, while allowing Web authors to update content in their own areas of expertise.

Regardless of the final CMS tools chosen — through an off-campus service provider, installation of an on-campus appliance, or deployment of FTP-based editing tools — we recommend that support for all Computing subsites be implemented over the next two years, phase-by-phase, with key areas, such as the home page and audience-oriented guides to be triaged first.

Therefore, to provide the highest level of support for computing stakeholders, the following personnel commitment would be necessary for the first year to develop and sustain a custom Content Management System.

Recommendation: 50 percent (~960 hours/year; ~80 hours/month) FTE for Technical Lead.

A technical lead oversees the project from a technical point of view. The technical lead assists the project manager in ensuring that the technical strategy is sound; designs, develops, troubleshoots, debugs, and implements applications for Web sites; and recommends specialized team members, such as security experts, database programmers, and other systems integrators. The technical lead prepares technical briefs and communicates with the project manager and other members of the technical team.

Recommendation: 20 percent (~384 hours/year; ~32 hours/month) FTE for Webmaster.

A Webmaster ensures that Web applications support the campus Web infrastructure, including standards, security, logging, and account management. The Webmaster also monitors site traffic and helps manage server implementation to meet traffic demands. The Webmaster troubleshoots issues with existing or developed applications, and works with the appropriate resources to resolve them.

The above resources would be required for 12-14 months to develop a custom CMS that would serve Dartmouth-specific Web production needs. Other types of CMS options would demand less personnel:

• Installing and maintaining an on-campus CMS appliance might require up to half of the above time commitment to master new technologies and administer systems.
• Managing an Application Service Provider relationship might require up to one-quarter of the above time commitment to coordinate and integrate off-campus services with custom Web applications built in-house.
• The implementation of FTP-based editing tools might require as little as 10 percent of the above time commitment to monitor Web server configurations to support FTP tools.

11/19/02 (JC); 11/25/02 (JC) clarified percentage allocations, at request of SH; 12/2/02 (JC) approved by CMS Discovery Team