Rationality in CMS implementation planning

You do not need to surrender your entire project to a content management system. Chief strategy officer Deane Barker explains.

  • Deane Barker
  • Jul. 06 2016

Content moves at different speeds, so to say, depending on its context. Some pieces of content live forever, unchanged, while others are constantly updated and expired. The live different lengths of time, they serve different roles, and they affect different sectors of the entire site.

Blend’s chief technical officer Deane Barker wrote a post about this — a concept he calls content velocity — and how this affects the different layers of a content management system. From the post on O’Reilly’s blog, “Rationality in CMS implementation planning”:

Let’s go back to the construction analogy and How Buildings Learn to point out that the walls of a building are not created equal. There are interior walls that are meant only to partition spaces. Then there are load-bearing walls, which both partition spaces and perform the not inconsequential task of holding the roof up. You can move partition walls yourself—get a sledgehammer and just go nuts. But load-bearing walls can't be touched without calling a contractor, getting a permit, etc.

Where the load-bearing walls are placed in a building will vastly affect how that building can morph and change in response to the needs of its owner. Some buildings are gloriously flexible, while others have walls and pillars that have to stay where they are, under threat of structural collapse. When an architect designs a building, they make design decisions about where these load-bearing walls are placed. These designs can reverberate decades later when someone attempts to change the building.

The same can be said of a content management implementation. Partition walls are content that is “editorially sourced,” which means it’s content that an editor can create, change, or delete at will. If an editor wants something new and different, they can grab a sledgehammer and go nuts.

Load-bearing walls are content, settings, and functionality that are “development sourced,” which means they are something that a developer put in place at the code level. Most of the structural, layout HTML is development sourced. The search box and text on the search button are usually development sourced. The CSS and layout styles are usually development sourced.

These items are load bearing. If an editor wants to change these things, they need to call a developer and endure the ensuing cost and complication.

Learn more about web content management from the book of the same name — Web Content ManagementGet it directly from O'Reilly, or you can visit the official Web Content Management site.