Checking the Box: How CMS Feature Support Is Not a Binary Question

I really hate CMS feature matrices. You see these in RFPs all the time – “Check the box if your CMS does X.”

The problem: support for a CMS feature is often not binary. Read that again. Here, I’ll indent it for you, just to make sure you don’t miss it:

Support for a particular CMS feature is often not binary.

The problem with a feature matrix (or, honestly, sites like cmsmatrix.org), is that they try to “flatten” what can be a nuanced question into a simple yes or no, and this is detrimental to anyone evaluating a CMS. You can’t stick a square peg into a round hole, and you often can’t answer “Do you support X?” with “yes” or “no.”

A couple years ago, I wrote this on a post about writing CMS RFPs:

A feature matrix reduces everything to a simple binary question: yes or no. Sadly, in content management, there are few things that are either yes or no. As with the scenario situation above, it’s often a question not of whether a feature exists, but how it works.

To try and flesh this idea out a bit, I sat down and through about all the different ways a feature might be “supported” by a CMS.

Here’s my list. I hope this is useful the next time you encounter an Excel document that’s 1,000-rows long, but only three columns wide.

(Thanks go to Seth Gottlieb and Tony Byrne for some helpful discussions around this post.)

1. Supported Out-of-the Box

This is a good one – the requested feature is just supported, period. This is the time when checking the box on the feature matrix feels so good. It’s an expected feature, everyone agrees on the label and the functionality, and it just works. Awesome.

Check the box, we’re good here.

2. Supported Through Configuration

In this situation, the requested feature doesn’t run out of the box, but the site can be configured to do it without having to develop for it.

Need to store and display the author’s current mood with your blog posts? Well, that’s not supported out-of-the-box in Drupal, but you could create a new field for it, and configure it to display, and with some CSS – voila! – you now have it.

Is this out-of-the-box? I don’t think so. Someone with an intimate understanding of how Drupal works has to go in and configure the system to do what you want, but at the same time, no one had to write any code, so it’s pretty good.

Can you check the box for this type of support? I think so, perhaps with a footnote or something.

3. Supported Through an Existing Plugin

Here, the CMS may not support the requested feature, but the problem has been solved before and wrapped up into reusable plugin that does support it.

CMS developers tend to a share a lot of code. For many systems, there are libraries of modules, plugins, extensions, and integrations (many word for the same thing) that can be added to the base system to enable all sorts of features. If a CMS was built with this in mind, it supports a lot of extra functionality through these plugins.

Can you check the box for this? Probably, though you need to mention that you’re not completed the feature matrix in the context of CMS X, but rather CMS X Supported By Plugins A, B, and C. In some cases, that unique combination might comprise a unique product in-and-of itself.

4. Supported Through Expected Development

In this situation, the feature is support through development that is expected with the average CMS integration.

Probably 99% of CMS integrations require some development. At the very least, templates have to be written, and they often contain logical processing, beyond just spitting out data. Some systems are more configurable than others, but for every Drupal, there are systems that present nothing more than an API you have to develop against.

This is what I call “expected development.” It’s development that you know you’re going to have to put in when you integrate a system. You’re going to have to write templates, you might have to write some code for a workflow or two, and you’re going to wrap some logic around the special navigation scheme you want. This doesn’t exist out-of-the-box, and it’s not something easily configurable.

But, at the same time, you’re not re-inventing the wheel. This is development that you or your integrator knows is coming, and the feature is not difficult to put together. The CMS was likely designed with this situation in mind, and integration points exist to support accomplishing exactly what you want to do. Furthermore, you’ve done this same thing in the past, so it’s a known quantity.

(So, if this is so common, why is it not supported out-of-the-box or through configuration? Because it comes up so seldom, or is so nuanced in every situation, that building it wouldn’t be worth at, and trying to make it configurable would be too confusing. Simply put, light development is the easiest, most efficient way to enable this feature.)

Can you check the box for this? Well…I think so, but I’m an integrator, so I know what’s coming – I know there’s going to be development involved. But an argument could be made that CMS X doesn’t support this, but CMS X and an average integration surrounding it supports this. If the client knows development is involved, perhaps they’ll understand, but with a feature matrix being evaluated in isolation, checking the box here could be considered deceptive.

5. Supported Through Custom Development

In this situation, the feature isn’t supported, and you have to do significant development to make it work.

Oftentimes, clients want something that’s not planned for by the designers of the CMS. They want to do something really out there or they want to integrate with something very specific to their organization (an internal, custom system, for instance).

This is what I call “custom development.” These are instances where you really have to break off some time and dig deep into the API. In some situations, I’ve called this “heroic development” because pulling it off can make you feel like the knight on the white horse, riding back into the village to the sounds of cheers and marriage proposals.

In no way can your CMS say it “supports” what you just did. Indeed, there’s no way the designers of your CMS could have ever dreamed of someone doing what you just did, so how could they build in support for it?

However, your CMS can make your life a lot easier or harder in these situations. The quality of the API really shines through at times like this. A great API can make this really satisfying and victorious, while a bad API can destroy the morale of the team and render many desired features simply unobtainable.

So, an you check the box here? Not a chance. You can pimp your API and try to get the client to understand how flexible your system is, but you can’t check the box.

6. Supported Through Integration With Other Systems

Often, a desired feature is not supported in a CMS, but could be supported through usage or integration with some other system.

Do you want advanced analytics? Well, some systems are building this in, but will it really be much better than Google Analytics? Perhaps your system can embed a GA widget somewhere in the admin interface which solves this problem. Need forms? Perhaps using Wufoo might be smarter instead.

Can you check the box here? I don’t think so – not without significant explanation, at least.

7. Supported Through Process or Workaround

Perhaps the feature the client wants is not really what they need. Perhaps there’s a question-behind-the question that, if solved, would eliminate their need for this particular feature.

Example: the client says they need a “sophisticated workflow system.” However, they really just want to make sure the CEO gets an email every time a press release is issued. Well, maybe simple subscription would work better here. Or maybe the CEO just needs an RSS feed in his Outlook. Or maybe a Twitter notification is the better answer.

In addition to situations where the client just doesn’t know what they really need, you have situations where the system can’t support something, but there’s a workaround that’s really not that odious.

Perhaps the need for collaboration can be solved by roughing out content in Google Docs, then creating a page in the CMS for further review. Perfect? No. Clunky? Yes. But if the system solves every other problem nicely, it would suck to throw it out because of this one thing that it doesn’t solve.

Can you check the box for this one? Nope. You just have to leave it empty, and hope you get a chance to make your case.

(Thanks to Seth for this one.)

8. Not Supported

Sadly, sometimes it’s just not supported. An argument can be made that anything can be supported with enough development, but that’s not an acceptable answer.

Sometimes you have to just hang your head and leave the box empty.