De-mystifying Content Management, Part 2

by Sean Cribbs

It’s been a while since I posted Part 1, so I thought I better get on with it.

In this installment, I’m going to give an overview of many types of content management systems, primarily to demonstrate the wide breadth of options available and thus the vagueness of the term “content management system”. This list is by no means comprehensive or in any semblance of order, and I invite you to inform me of other types you have encountered. So let’s get started.

Blogging

Blogging software is one of the most recognizable forms of CMS available today. The focus of blogging software is that of periodic articles which are organized by date, usually reverse-chronologically (most recent first). Many blogging softwares also provide support for non-article pages. Blogging software often comes as a hosted solution. Here are some of the more popular variants, in no particular order:

As with all of the categories, not all of the software listed above will fit neatly into the category. I’ve tried to focus my categorization on the main theme of the software.

Blogging software is best if you want to create a journal site, news site, or other site that is focused on date-oriented, periodic content. You probably should not use blogging software if you need to organize content in a fashion that isn’t date-oriented. Some blogs like Mephisto allow “static” pages, but you may have more difficulty creating them than with other software.

Community Portal

Community portals aggregate content generated by visitors to the site. Site visitors create content by using the various modules made available to them. These might include:

To contribute to the community, most portals require visitor registration, and include the ability to moderate contributions. Here are some examples of community portals:

Community portals excel at creating sites where visitor interaction is key. If the focus is communication between members of a community, choose a community portal. However, if your site is mostly content from a single source or small group of people, and interaction with visitors is not desired, a community portal is not the right choice.

“Enterprise” Portal

I use “enterprise” in quotes because I disdain the word. This is mostly because it doesn’t usually end up being associated with good, clean, well-designed software, but with ugly, obtuse, opaque, feature-bloated software. That said, the “enterprise” portal does represent a distinct group of softwares that might be classified as CMS.

“Enterprise” portals, like community portals, focus on delivering information from several modules. However, these modules do not typically allow contribution from the site visitor, but pull their information from other systems like accounting, records, and other enterprisey data sources. They often include a personal login which can be tied to a common authentication system, or SSO (Single Sign-On). The visitor who logs in is often presented with the opportunity to customize their “landing page” or “homepage” to suit their needs, usually with some eye-candy drag-and-drop scenario.

Ugh, I feel all dirty just having written that paragraph.

“Enterprise” portals are usually not turn-key affairs but require lots of customization to work with existing data sources. They are also usually very expensive and have complicated licensing schemes. Having not researched them thoroughly, but seen a few in action, the only example I can come up with is (surprise) Microsoft’s SharePoint portal. However, many software packages that can be bought from third-party vendors use SharePoint.

“Enterprise” portals excel at delivering customized, targeted information from sources that are distributed across an organization. They make good “intranet” sites and “ERP portals”. They are not appropriate for sites that deliver primarily static, web-based content.

“Enterprise” CMS

There’s that word again. I hesitated to even discuss this form, but it seems necessary. There is no cut-and-dry classification for this term, but I may be able to shed some light on some softwares that might receive this moniker. Some are asset managers, with a focus on organizing media like pictures, audio and video. Others are document workflow tools (Alfresco for one) that focus on a documentation repository with configurable approval processes. And there are still others I’m not aware of. Some of these produce web-accessible content, some do not.

If you’re considering purchasing an “Enterprise” CMS and have the money to do so, more power to you. You know who you are. However, I can’t be much help in this arena, so you’re on your own.

Page Builder

I am coining this term “Page Builder” because it seems the best way of describing this class of CMS. Page builders often present the content editor with a structured interface for constructing a given “page” in the system (which usually represents some page accessible via URL). When I say structured, I mean that most markup (HTML), if not all, is abstracted away from the content editor. The editor usually interacts with widgets that construct markup for her, or with WYSIWYG editors in some cases. Oftentimes, content can be edited by clicking a button on the live page that invokes editing. Page builders sometimes include “wizards” or “templates” to get the editor started. Here are a few examples:

Doodlekit and TYPO3 represent poles in the spectrum of available Page Builders (and the only two I am intimately familiar with). In my opinion, Doodlekit is much better for simpler sites that your Grandma could write. TYPO3 is a much more complicated solution with features for larger sites, and also leans toward another category which we’ll discuss later.

Overall, page builders are great if you want to start a site with little knowledge of how web standards like HTML work. They can be difficult to work with if you need fuller control over the structure and design of a given page.

Content Management “Framework”

One person I have had the opportunity to work with said “All CMS are frameworks.” In a sense, that is true. If you have access to the code, you can customize it for your own needs, and it becomes a “framework”. However, some CMS are more “framework” than others and focus on providing more flexibility to the software developer than end-user features.

Consider the whole rest of the section flamebait as I’m going to say things that will make people angry but come from my own experience.

These frameworks are usually open-source projects that are not accessible even to experienced developers who are familiar with OSS. They usually include unnecessary abstractions that in the end amounts to code masturbation and a steaming heap of uselessness. The amount of effort needed to create a useful and manageable website is immense in comparison to other available packages. Documentation about them is unclear or non-existent, primarily because of the complicated abstractions inherent in the code. Sometimes they do things like implementing their administration interfaces in the framework, if they even have one. Sorry, that worked for Smalltalk, but not for content management. Sometimes they include their own scripting/macro language or configuration registry; yes, that’s another language you have to learn to understand the thing.

Here are some examples of Content Management “Frameworks”.

I would argue that with excellent low-pain web development frameworks like Rails and Django available, it’s easier to write a custom web application than to decipher one of these “frameworks”. If you’re willing to spend the time and money it takes to figure one out, you might as well build it yourself. Although I’m a Rails guy, Django seems particularly suited to create content-oriented sites with its built-in admin tool.

Site Generators

Site generators are a class that I encountered while working at KCKCC. Before we were forced to choose Radiant (in the end a wise choice), we had requested the purchase of a $50k CMS called Cascade Server. The focus of this CMS, and a few others we evaluated, was generation of a static site using a dynamic tool. The content was highly structured — usually XML that is translated to HTML using XSLT. They avoid the whole dynamic application latency issue by using rsync or a straight file export to update the site, while your webserver serves static pages.

Site generators provide a high level of flexibility in the content and integration with other services. However, they often have a larger learning curve as well, and XSLT is not for the timid. Their performance is nearly unmatched, however, because speed is dependent on the web server, not the CMS. Existing dynamic applications can either feed XML to the CMS or integrate independently.

Every site generator works slightly differently, so close evaluation is necessary. Like "CMF"s they can be adjusted to almost any need, but require extra effort.

Wikis and Fora

I hesitate to put these in there (mostly because they are covered in the community portal), but many would consider them to be CMS.

Wikis are sites with visitor-editable versioned pages. They typically use some naming scheme like CamelCase for new pages. There are a wide variety of wikis in use, the most notable being Wikipedia. Wikis excel at managing collaborative writing and community documentation.

Fora (colloquially, “Forums” or “Bulletin Boards”) are discussion-oriented sites in which categorized conversations occur in streams called “threads”. A thread represents the timeline of individual messages from various participants responding to an original message. Examples of fora include:

Fora excel at facilitating asynchronous discussions, but are weak at or incapable of static content.

And others…

There are many other ways of classifying CMS software. RadiantCMS, the CMS that serves this site, defies most of the classifications I have presented above, or perhaps creates its own classification. There are many other CMS that I have not yet encountered that could create new classifications.

Next time

In part 3, I will discuss why I started writing this series in the first place, and what my take is on the CMS issue in general.

© 2006-present Sean Cribbs — Github Pages — Tufte CSS