A few years back my company had to implement a new Web Based Content Management System (CMS). We used everything from basic meetings, flow charts to MS Project and JAD.

Delimiting our needs for a next generation web environment is complicated by the fact that our current mainspring application, WebSpinner, provides an editing solution, a means of moving files to the server, and a management interface for providing access to pages. So, any solution that supplants WebSpinner, even in the short term, has to provide a replacement for all three facets.

What precisely is a Content Management System? For one thing, it is (or should be) transparent to the users of the web site. We are talking about something that affects how the web site is stored, edited, and worked on. Static web sites are large groups of various files, arranged in directories, which are served to clients on requests. This is referred to as "dynamically-generated" content.

A Content Management System is an application that enables web authors to add and edit content to a web site, stores this content inside the application rather than as HTML files, and then generates and serves this content on request.

Content Management Systems come in many shapes and sizes. Many of the larger ones, often referred to as Enterprise CMS, are full-blown publishing, document management, editing, and workflow enabled applications costing up to the low millions, suited for running the web publishing and document management needs of a large organization. At the low end, there are many simple CMS, sometimes built with nothing more than PHP scripts and a database backend, or adaptations of blogging or wiki software to allow access to and editing of web pages. Most of these are OK for building small sites from scratch but are less able to handle large existing sites.

Of more interest to us are "mid-sized" Content Management Systems, and especially the open source ones.

There are a number of these, for example:

• Lenya 
• Plone 
• OpenCMS 
• Mambo 
• Joomla

Another option some libraries have already followed is to build their own CMS, using technologies such as PHP, ColdFusion, ASP, and others.

Some recent looking into what others are doing yielded some interesting results. Many libraries, while perhaps more advanced in the amount of dynamic content on their web sites, are also looking at Content Management Systems. One library (Kent State) developed their own, reporting it took two of their technical people eight months. Virginia's library is developing their staff web site with Lenya, an open source product from the makers of Apache. They hope to port it to the public side if successful. Most libraries seem to have CMS in mind, but are not yet actively implementing.

MIT did a campus level review of Content Management Systems, their final report is available here in PDF format: MIT CMS Discovery Project Report (PDF).

A Content Management System is no panacea, of course. The ones with enough flexibility to meet our needs have complicated infrastructures, and are not trivial to implement. Several of the products that would seem to be a good fit have steep learning curves that have to be surmounted before implementation. An implementation project like this will consume development resources. Because a CMS has to be implemented from the back end first (i.e. we need to have a working CMS before a single page is served from it) time needs to be invested before any practical benefit is realized. While we are working on it, WebSpinner and static pages will continue to drive the site, and potential "one-off" applications will not get development resources.

After a successful implementation, the question of conversion comes up. To fully realize the benefits of a CMS, thousand of existing pages will need to be ingested by the CMS. While much of this can be done programmatically, many of the reasons we want a CMS (uniform and standard site coding) are the very reasons this will be time-consuming and difficult, due to the very uneven code of our site.

Also, since this will necessitate a change in the way that our web authors do the business of maintaining and editing web content, staff will have to be trained on using the new system.

We basically used prototype analysis while getting user input at each phase. This was done with every CMS we could find. Once we have all the information such as the pros and cons of each we limited the choice down to 3 and did an employee based vote. I have to be honest the actual winner was over ruled due to an issue with the eCommerence section but this process proved to be fun and effective.

Most of the coding phase was only done if custom pages and functionality was needed. Joomla out of the box had 90% of the functionality we needed. The company spent about 4 weeks programming and customizing logos. These code changes where used in the main pages of the site as well as the intranet portion. Custom pages included time off requests and employee directories. The logos where changed to related to the companies trademarks and positions statements.

The testing phase was very rigorous and time consuming for the staff. We found many issues with the out of the box install. Many of these issues where fixed in the next release and/or beta software patches. This phase also shed light on more customization that was needed. The overall time spent was 4 weeks.

The installation phase was streamlined due to the nature of a packaged CMS system. These systems come with installers that make for fast deployment. Since the testing phase worked out the bugs and sealed the deal on any scope creep the installation phase only took 1 week. Installation documentation from the testing phase was reviewed and perfected. Installation on production with customizations and software patches where all lumped up in one installer. This made redistributing the site for load balancing very easy.

The documentation phase is an on-going project. Documentation was started from the very first meeting and will not end till the system is released. End user documentation took about 1 week. This manual targets end users who needs a quick start guide to using the system features. This manual can also be used for a quick refresher of commands and command paths to get tasks accomplished.

The training phase lasted about 2 weeks. The whole staff was training using web demo technologies as well as Power Point presentation. The main user group was trained hands on and the manual and FAQ pages where updated based on the responses.

Support is very easy for the system since it is web based. Many clients use the system but the system is being run from one single set of code pages hosted on the web server. This makes updates and customizations very easy for the administrators. IT updated all end users with Internet Explorer 7 and that basically covered any of the client issues. Connectivity issues fell in the Networking Administrator’s hands. Those issues where solved as needed. When there is a security or bug update we simply update the web server and the next time the end user logs in everything is up-to-date.

In conclusion, the main reason we went with a CMS system over custom coding from scratch was the ease of use and functionality that was already present. A web application was chosen for the simplicity on the client side. Updating the application from one location vs. each client saved much time and money. The only down side to the CMS system is the lack of visual customizations based on a set off rules you have to follow. If you don’t follow the rules you could complicate the updates as well as make the whole system unstable. The end result has been very positive from the end users. The management is happy about the cost savings on using and open source solution.

Works Sited
Wikipedia:

http://en.wikipedia.org/wiki/Object-oriented_programming

CMS Matrix:

http://www.cmsmatrix.org/

SWIK Blogs:

http://swik.net/Comparison+CMS