Content Management Systems

Content Management Systems (CMS) are web programs that make it easier to add and update content on web sites. Instead of learning HTML, FTP and web server commands, once a CMS is set up and a template “look” is defined, others can usually add material very easily without learning any of the above.

  • Groups to Watch
    • OSCOM Open Source Content Management Org.
    • At this point, MIT OCW is monitoring six: Zope, Red Hat, Midgard, OpenACS, OpenCMS, and Bricolage. By 2004, most experts agree that one CMS provider will become the clear, open source leader in this industry sector. MIT OCW will track the progress of key open-source CMS providers during this accelerated maturation.
  • Commercial Solutions
    • MIT OCW senior management, working with the Sapient Corp., developed a short-list of vendors, and the individual vendors gave presentations to the team. In the end, MIT OCW selected a commercial CMS, Microsoft Content Management System 2002. The reasons for the choice of Microsoft 2002 were manifold: Microsoft made a serious commitment to the MIT OCW project, the total cost of ownership of Microsoft CMS 2002 was significantly lower than the other vendors in consideration, and the Microsoft product offered a high-level of usability for the end-users, MIT OCW’s faculty liaisons and MIT’s faculty.

July 2, 2004 at 10:26: SoEditor — great WYSIWYG editor, available for free in the lite version — Works with ColdFusion, .Net.

January 4, 2006 at 09:11: Jim Williamson (OID): I’d like to comment on two of the links above. I was the project lead on OID’s implementation of Plone and take exception to Jeffrey Veen’s two articles on the troubles with CMSes. Obviously, individual cases differ, but Veen’s blanket statements (“Most open source content management software is useless.”) don’t always fit.

Here are my comments:
First, the “Why CMS Fail” article:

  • We kept the staff informed of what we were planning to do through formal meetings with managers and informal discussions with staff so when we introduced Plone, they were aware of what direction the website was going. Thus, the statement, “It�s foolhardy to unveil a mammoth, nine-month project to an unsuspecting user community and expect adoption” did not apply in our case.
  • We were answering a problem voiced by many people in the organization, not just management. OID staff disliked the website, felt the editing process was unwieldily and broken; Plone fixed that for us.
  • The article has a basis that we could not afford: “Over and over I�ve heard the same complaint about these projects, ‘Turns out, after all the budget and time we spent, we really didn�t need a content management system at all. We just needed some editors.’” OID could not afford to hire an editor and a team of writers to go out to the various units and generate web content.

Second, the “Making a Better CMS” article; answering the main bullet points of the article:

  • Was Plone easy to install? It could have been easier; we purposely chose a more complex path (like integration with Apache, etc.)
  • Was Plone easy? Yes. Some users “got it” without any training at all.
  • Our documentation was both “fact-based” and “feature descriptive”
  • Plone does separate admin from content management
  • Public should not be able to log in: whatever; the author has got a bug about this.
  • Jargon is everywhere: whatever.
  • Plone is flexible — we don’t have columns
  • CSS? Our Plone site looks nothing like Plone OOTB.

Despite our ignorance of Mr. Veen’s positions, we managed to use common sense and technical sweat to roll out a VERY successful CMS to our staff. Plone has met all our needs and has performed very well; it is flexible, powerful, and customizable. Best of all, staff and our top management love Plone and how it empowers them. We have received numerous comments on how happy they are with the choice.

This article was originally posted on the UCLA Programmers Wiki.