Repouring the Foundation: The Perils of Content Modeling on the Fly

I teach “Introduction to Content Management” in the Content Strategy program at FH Joanneum. I talk about content modeling quite a bit, and in the final lecture, I have a slide that just says this:

Content models are foundational.

And they are. Your content model is the base on which you build most everything else you do with your CMS.

Defining the content model of a CMS implementation is one of the first things you do. At Blend, we’ll usually start by paging through wireframes and writing down the content types we see, adding attributes, combining them, abstracting reusable elements, etc. This forms the core of the entire implementation.

A content model can be said to be “established” when you’ve implemented it and built a bunch of functionality on top of it. During the implementation, you’ll realize you have some mistakes and inefficiencies, which you can correct as an expected task of development.

But fast forward two years down the road – your model is now loaded up with actual content, and you have templates, workflows, external integrations, and all sorts of other things built which depend on your content being in the format that you settled on when you launched the site.

Like it or not, your model is now “established.”

Changing content models after they’re established can be tricky, just like changing the foundation of a house can be tricky after you’ve poured it.

True story: I don’t have a front porch on my house because – 20 years ago – the contractor started building it four feet (just over one meter) too close to the road. We didn’t realize this until after the foundation was poured. At that point, it was too late.

I was talking to my friend Allan Thraen about this the other day. Allan worked at Episerver for a decade, and now he’s off on his own at CodeArt. Our conversation drifted into the idea of letting editors modify an established content model without a developer being involved, and was this a good idea?

The conversation resulted in a great blog post from Allan: The Curious Case of Content Modeling.

It’s worth reading. In particular, Allan recounts the situation of a client using Contentful, and allowing business users to do their own content modeling, without any developers being consulted:

If they for instance added a new field, or even a new content type, it would of course not be visible on the web site until their developer had put it into their rendering, but they could start to create content for it right away and that way it would be easy for the developer to see just how it would fit and make the proper front-end adjustments. In fact, all they needed was a front-end developer to update their site with the desired changes.

As a back-end engineer, this just freaks me right the hell out, but it seems to be working for them so who am I to judge?

The key is this: content modeling takes skill. It’s easy to build a dumb, inefficient content model that makes future changes difficult (“We don’t need ‘FirstName’ and ‘LastName.' That’s just wasteful! Let’s just have one ‘Name’ field!”)

However, if you do have skill at it, then it doesn’t matter what your job title is. These skills are more often found with engineers than editors, just because engineers have experience with data modeling and abstraction, but a good content strategist can generate perfectly fine content models. In many teams, there might be a super-user, administrator, or metator (all hail Boiko!) that has the wisdom and perspective to do this well.

In fact, here are two books that do a wonderful job of bringing content modeling into the editorial space:

• Content Everywhere, by Sara Wachter-Boettcher
• Designing Connected Content, by Carrie Hane and Mike Atherton

(I wrote a sidebar for the former, and I’m quoted in the latter…but, really, who’s keeping track?)

Also, Ann Rockley did a lovely job several years ago in defining a “back end content strategist”: Why You Need Two Types of Content Strategist

Back-end strategists … have a love for structure, scalability, and technology. They make recommendations about how to use technology – hardware and software – to handle all that content in efficient and powerful ways. This type of strategist answers questions like these:

• How can we organize content so that our authors can easily store and retrieve it, and prepare it for automated selection and delivery in the relevant channels?
• How do we structure the content so that modules are consistent and can be easily assembled (mixed and matched) on-demand to meet customer needs?
• How do we make sure that we aren’t creating, recreating, and recreating content over and over for each channel?

That’s great stuff, and it really gets to the absolute core of content modeling. All those questions are critical when defining what your content looks like inside your CMS.

But content modeling still has a reputation for being something like the Dark Arts, which is done by a select few and requires an Act of God to be deployed where it can provide some productive value.

So, the desire to modify established content models “on-the-fly” is still something people ask for in RFPs. More and more editorial groups want to be able to do everything without a developer involved, in a continuing quest to liberate themselves from any external limitations.

Generally speaking, content modeling can be done two ways:

1. As Allan points out in this article, many systems allow for the definition of content models from the administrative interface. Episerver used to do this, Drupal does this – dozens of systems do this. At any time, an editor with sufficient permissions could conceivably go in and just…change stuff.

2. In contrast, many systems require content modeling to be done from code or configuration. In most every current Episerver implementation, content models are C# classes. In Sitecore, a lot of developers do their content modeling from a Visual Studio extension called Sitecore Rocks, then this can be synchronized with the production instance. These are things that a developer needs to do.

When you model content from code, you have technically “done development,” and you’ll need a code deploy to get your changes launched. Many editorial teams hate this, because then they’re dependent on someone else, not to mention being subject to deployment schedules, change control, regression testing, etc. They’re trying to achieve this ideal vision of being able to do everything without outside resources or limitations.

However, this is often not realistic for the same reason I quote at the beginning of this post:

Content models are foundational.

And just like the foundation of a house, a lot of stuff rides “on top” of an established content model. The model change might just be the tip of the iceberg, and is all the stuff below the waterline also editable from the interface?

Let’s assume an editorial team can edit their content model, and they decide to add a property/attribute – let’s say they add “Mood” to an article to track the mood that the author was in when they wrote it. Let’s also assume they know what they’re doing, and they know to add it as a dropdown or a checkbox list or a text box or whatever is correct for their implementation.

Doing this from the interface allows them to do exactly one thing: capture data. But they don’t capture data just for giggles. Clearly, the editorial team is going to do something else with this property.

• Do they want to output it somewhere?

• Do they want to use this in some event tracking or workflow, maybe to trigger additional review of the author is “angry” or “hostile”?

• Do they want it to affect channel distribution? So, “happy” articles also get pushed into the @goodnews tweet stream.

• Do they only want this attribute only available to editors who have been working at the company for six months?

• Do they want to disallow editing of this attribute after the article is published, or prevent editors from changing their mood after the fact?

So, you can sure add the property, but how much more can do you than that? Most systems have file-based templating, so to get that attribute even added to an output artifact, someone is going to have to change a template file and deploy it…which brings you right back to the code change you were trying to avoid in the first place.

Now, this isn’t the case with all systems. Some CMSs will allow you to do a lot more than just add the attribute.

• Drupal is probably the King of Configuration. You can do a lot in Drupal without writing code, and you could conceivably get that attribute output somewhere from the interface by adding it to a view or modifying the display fields of a type. And there are other Drupal-like CMSs that treat output as a matter of configuration.

• Some systems like Umbraco and TERMINALFOUR allow templating from the interface. The actual templates are editable through embedded code editors, and don’t have to be “deployed.” In some cases, they read/write from the file system, so you get the best of both worlds (spoiler: it’s actually the worst of both worlds because now you’re writing files in production that aren’t in source control, but whatever…)

But here we’re still just discussing the ideal scenario: (1) adding an attribute, and (2) getting that to display somewhere. This is probably the simplest use case. And even if you accomplish this purely from the UI, you’ve still had to engage a developer-ish person to re-template or style the output.

If you’re working this hard to avoid a code deploy, maybe you just have a DevOps problem? Or if you’re that estranged from developers, maybe you have an organizational or managerial problem?

And don’t even get me started about the scarier edge cases:

• Content model changes or deletions. Aside from losing data – which is a huge problem – there might be dozens of processes that editors don’t know about that depend on the content being in a specific format.

• Things other than templating. Integrations, workflows, advanced permissions, and anything that involves data exchange with an external system.

The larger principle at work here is the division of duties. Who can do what in a CMS implementation? I touched on this a while back in a post about another quasi-development feature that editorial teams constantly want to do: ~/tech/blog/truth-about-cms-form-builders/

Understand that if your expectations are to integrate your forms with a wide variety of other systems, then you’re not going to get the freedom from development that you’re looking for, and only having the UI portion of these integration scenarios under editorial control will rarely ever be helpful.

The same thing applies here. You can find systems that will let editors change content models on-the-fly, but that’s not nearly as much freedom as they actually want.

In most cases, it will give them very limited control over a very limited number of things. In addition to waiting on a development team to finish all the things they can’t, they might find that the first thing the developer does is undo all their work and re-implement it to account for technical parameters they weren’t aware of and couldn’t be expected to understand.

Once a content model becomes established, it’s hard to change, and it probably should be. In most implementations, there’s a lot riding on it.

I remain unconvinced that reducing the barrier to change here will result in a better experience over the long term.