CMS Feature Analysis

Why is this?

“Fitness to Purpose”

In evaluating anything, we tend to think in terms of relativity.

If we say that some thing is “on the left side,” we’re implying that some other thing is to the right of it. You can’t be on the left side of nothing, after all, so the concept of leftness only exists because something else is on the right.

Likewise, content management systems exist only in clear relation to a problem they need to solve. Their competence can only be evaluated in terms of their distance from what is needed for your particular situation.

The correct answer for a content management question lies in an intersection of dozens of factors, including:

• The type and goals of the website
• The shape of the content being managed (see Content Modeling)
• The output and publishing requirements (see Output and Publication Management)
• The sophistication of the editors (see Editorial Tools and Workflow)
• The business environment, decision-making process, and budget

These are just five factors. There are likely hundreds more, and the weighting of the individual factors will be different for every organization.

When comparing systems, it’s easy to look at two features and say, “This one is better.” In doing this, the unspoken end to that sentence is “for the particular requirements I’m thinking about right now.” What’s right for one set of requirements could be clearly wrong for another.

Furthermore, some applications simply don’t need certain features. If you’re the only editor of your web content and you know for certain there won’t be any other editors in the future (this is more common than you might think), then concepts of workflow, collaboration, and permissions become largely meaningless. Noting that a system is bad at those things might be an accurate observation, but it’s not relevant.

A content management expert once declared that the single criterion for CMS selection should be “fitness to purpose.” That phrase describes an intersection between:

• The capabilities of a system (“fitness”)
• The requirements under consideration (“purpose”)

I doubt a better standard of evaluation exists.

“Do Everything” Syndrome

Content management systems, like other software, tend to try to include as much functionality in one package as possible. No vendor (or open source community) wants to say, “We don’t offer that feature,” so they’re motivated to handle every possible situation or eventuality. If an editor has to go outside the system, that’s considered a failure .

As a result, content management systems are getting more and more complex every year. The industry has steadily crept outward from the clearly defined core of 15 years ago. We’ve already discussed the drift from content into community management, and now we have systems managing social media, offering powerful marketing suites, and even trying to act as general application development frameworks.

The price we pay for this is complexity. The list of features you’re going to ignore and try to find ways to disable can easily be longer than the list of features you’re actually going to use.

As systems become more complex, they tend to become more generic. Developers working on any system for too long drift into larger architectural concepts and frameworks. They become what Joel Spolsky has called “architecture astronauts:”

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don’t know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don’t actually mean anything at all .

Hypothetical conversations like this actually happen when discussing content management:

If we can manage web pages, then we can manage general content too! In fact, let’s just manage random strings of text – if the user wants to make a web page out of them, she can do that! And why even text? Everything is comprised of bytes in the end, so let’s just manage sequences of bytes and let editors select an optional text encoding or file type! How elegant is that?!

Remember: a system designed to do everything tends to do nothing well, and you should only evaluate the features you actually need.

When extended features outside core content management are added, they’re often added poorly. In many cases, the vendor is trying to “check a box” that it’s seen on customer requirements lists. Just because a feature exists doesn’t mean it’s done well.

Form-building tools are a classic example (more on this in Other Features). Many systems have them, as they’ve become a de facto requirement to compete in the marketplace. However, I’ve never evaluated a form-building system that was developed at the same level as the core content management tools. In almost all cases, this was an add-on feature that had to survive only as long as a sales demo.

We have a natural desire to think that one system can solve all of our problems. However, the solution might lie in multiple disconnected systems and how you use them together. Do you love the collaboration features of Google Docs? Why can’t you use that to work on content, then just paste the result into your CMS for delivery? Clearly, this is a bit rough around the edges and has some disadvantages, but many organizations would be better served by this plan than by a full-blown CMS implementation to solve a single problem.

But we often look down at simplicity. We like to think that we’re burdened with very difficult problems that require intricate solutions, and that the complexity of the solution is a direct reflection of the sophistication of the underlying problem. Breaking this habit is difficult.

Going outside of your shiny new CMS is not necessarily a failure. It might be exactly the right decision, rather than suffering through using a poorly implemented feature out of nothing but a desire for one product to “do everything.”

The Whole Is Greater than the Sum of Its Parts

Content management systems are complex and full of moving parts. The effect of all these parts working together forms a whole that might not be representative of the parts that make it up.

It’s understandably hard for a system made up of poorly designed features to rise above them, but sadly it’s not uncommon to have: a portfolio of features that are stellar when evaluated individually, but just don’t quite come together as a whole.

This can be caused by poor usability in the intersections between features – a workflow system that offers a stunning array of functionality but simply doesn’t interact well with editors when they’re creating content is not much use to anyone.

Another problem can be misplacement of priorities, when one feature is over-developed compared to others. The perfect templating system in service of content that can’t be modeled accurately won’t help you much, and the end result is like a Ferrari in a traffic jam – lots of power with no place to go.

The only way to effectively evaluate the whole is by subjecting it to as long a use case as possible. Don’t just pick small snippets of functionality to compare (“Can we select an approver when starting a workflow?”), but rather complete a full cycle of interaction (“Let’s publish a news release from initial conception all the way through distribution”). Scenarios like this can poke unexpected holes in systems that seemed sound from the feature level.

Implementation Details Matter

The value of a CMS feature is not just in the final result. It also matters how you get there. Just because different systems can check a box on a feature list doesn’t mean that the feature was implemented equally well in both systems.

Usability matters. Many features are conceived, designed, and built by developers, and this may result in interfaces and user models that make little sense to editors. Developers tend to be more forgiving of rough edges, and more concerned with ultimate flexibility rather than usability.

Beyond just the interface, does the mental model of the feature make sense? When an editor is working with it, is it easy to describe how it works and theorize ways in which it can be used? Simple features can be made obscure by idiosyncratic philosophies and ideas that made sense to the person who designed them, but no one else.

Some features can be hopelessly complex, either through poor design or just because they are, in fact, very complex. Consider the Drupal Views module – this is a system designed to let editors build aggregations of content. That seemingly simple goal is extremely complex in practice, and even though the interface has been labored over for years and refined to an extremely high degree, it’s still going to be somewhat overwhelming.

Other features might be built specifically for developers. A workflow system might be very powerful, but if it has to be configured in code, then compiled and deployed, this drastically limits its utility for anyone other than a developer or teams that have developers on hand for future changes. Similarly, templating systems that are not extractable from the core code of the system limit their utility to only people who have access to that code.

Some features might require additional software. It’s very common for vendors to “partner” with other firms to provide plug-in functionality. This functionality looks great in a sales demo, but requires extra expense and often a separate purchase and license from the third-party company.

The lesson here is that just because a feature exists, that doesn’t mean it’s any good. When you have a list of boxes you’re trying to check – either an actual list, or a mental list – there’s seldom room to say, “Yes this feature exists, but it doesn’t work very well.” In most feature-matrix spreadsheets, there’s a column for “yes” and a column for “no,” and nothing in between.

It’s a very cynical observation, but vendors know this. They realize that someone evaluating their software is wondering about functionality and just assuming it works well. It’s very hard to dive deep enough into a software demo to uncover all the warts. The vendor might be counting on this, which is why you’ll often hear: “Sure, we do that. Now, lemme show you this other thing we do…”

Do not evaluate features based merely on their existence or on a cursory examination of the result. Find out exactly how the feature is implemented and ensure that you’ll be able to use it to achieve the same result.