Features vs. Model: Understanding the Scope of an “Editor-Friendly” CMS

The thing with selecting a content management system (CMS) is that there are, apparently, 750,000 individual choices to make. There are big choices — PHP or .NET? Enterprise or open-source? — and there are small choices. Vendor selection is big business, and making those (estimated) 750,000 choices is an entire industry all on its own, because vendors never truly know which of those choices is the deal-breaker.

But one thing you don’t hear too often is that most CMSs, at their base level, are way more similar than they are different. It seems like there might be 750k decisions to make, but in reality there are only a few features that differ across every content management system — things like proprietary tools, or unique content modeling, or even industry-specialized features.

Which, in a way, means we more often fall back to one of the most misunderstood and vague features in modern content management: Is the CMS editor-friendly?

Two decisions, not one.

Being editor-friendly means building to an established workflow. It means providing as little resistance to publishing as possible, while still maintaining structure. It especially means being clear and organized so the transfer of content from a human to the CMS isn’t dragging through mud.

In other words, “editor-friendly” isn’t a feature. It’s not something you can shop for. In most cases, making a CMS editor-friendly is not solely the job of the CMS vendor.

Ultimately, there are two decisions buried inside “we need a CMS our editors can use.” The first is the one you buy: the platform. But the second is the one you build: the content model — how your pages relate to each other, how content is re-used, and how you balance structure vs. free-form. While the platform obviously sets the ceiling on how good the editor experience can be, the content model and the work done during implementation represents the floor — a strong platform sitting on a bad model is still a bummer of an editing interface.

The assumption is that this content modeling work comes after the platform is chosen, and in most cases that’s exactly what happens — IT or someone in the C-suite push for a vendor selection because it seems like the logical first step of a web project. I’d argue that while this is normal — and building a content model based on a chosen tool is a pretty standard practice — that does not mean it’s the best idea. You can’t really evaluate a platform for your editors until you have at least a rough idea of your content model, because the model is what tells you what editor features you even need in the first place.

Without a model, you end up grading every platform on a relatively generic feature list, while with a content model you can walk into a vendor demo or selection process with a few pointed questions — questions that will surely come up no matter what once your editorial team takes up the new tool.

Building a rough model.

Now, this sounds like a lot of work. In reality, it’s just a rearranging of the work you’re already going to do. Your content model does not need to be perfected or vetted by 100 stakeholders, and you certainly don’t need a field-by-field map. You DO, however, need enough of a sketch to figure out the harder questions.

Here are some examples of what “enough” looks like:

• If you run an association, you may have individual chapters that run their own events. Are these events part of a single chapter calendar? Or is the hope that every event is part of a larger calendar that’s filtered at the chapter level? This determines if the event model relies on a parent-child relationship or if event feeds are populated from a pool of events.
• If you’re managing web content for a credit union, you will be deeply invested in how blocks and reusable content work. Can you create a single editorial block for a disclosure and post it across the site, creating a single space for edits? Are you looking for more advanced central governance like token replacement? How the CMS manages blocks and reusability is important, but it depends on how your team will be managing reusability.
• If you’re working on a hospital site, you’re going to have a pretty deep pool of physician profiles, and each physician is going to be connected to multiple clinics. That’s a many-to-many relationship. Will you need to assign every location to the provider? Or is it easier to assign every provider to the location?

All of these questions require at least a rough model, but that rough model then unlocks what can be learned from demos and vendor vetting. As we say at Blend, the best sites happen when the thinking comes first — and this is a classic example. Sometimes we need to adapt our strategy to match the technology at hand, but that doesn’t mean we have to give up all of our choices to the whims of the technology itself.

What the model controls.

So, with this rough model sketched out, let’s talk about what can most often be adjusted by the implementation team.

Every CMS has a set of content types. General use pages and articles and article feeds and events and profiles and other very specialized types that may be wholly unique to your industry. We have expectations on how this content relates to each other, which means it’s important to build the model around how editors themselves think.

The CMS should match the work they know, while also providing enough structure to keep things standardized across a larger team. Examples include:

• Structured content — The decision around what fields are more open vs. which fields are locked into place to preserve schema and layout is a decision made as a part of the content model.
• Relationships — When a user makes a change to a page that connects to others, more than likely the change needs to be reflected on the other side of those relationships.
• Accessibility and performance — The CMS can only go so far in applying accessibility fields like alternative text, or building a page to load quickly. These are most often content type level decisions, not full-site CMS decisions.

For most teams, the model is what makes or breaks the editor experience. Every time an awkward relationship is built, or a block struggles to look right across different templates, the editorial experience degrades.