Principles of Content Management

Technologists tend to get enamoured with their architectures and solutions. However, the goal of content management is simply to enable the consumption of content by the people to which it’s intended. It is a means to that end, nothing more.

The “correct” solution for managing content in any given scenario, is simply that which enables content to be effectively created and consumed in the present, with some consideration to future usage. Part of our job – a key component of experience – is creative forecasting of future usage and balancing that against practical realities like budget and schedule.

We build the rest of our content process in top of our content models. Mistakes here can reverberate throughout the life of your content. Changing a model after it’s been “loaded” with content can be complicated.

Very rarely does a content object exist in isolation. It’s almost always part of an aggregation of other content, and its relationship to that other content – its “context” – often defines behavior, appearance, and functionality.

We execute the (1) practice of content management using (2) technology that has been (3) implemented for our specific needs. All three of those things will impact the effectiveness of our content over time.

We need content management because things change. If our content was static and never changed, would we need to manage it? Our needs for management are propotional to the amount of change present in the editing and presentation of the content.

In some senses, content is an abstract ideal. It exists as an idea, a message, or some unit of knowledge. It is used to create artfiacts, which are the actual, concrete media that humans consume. One unit of content can generate multiple artifacts.

Content is WORM-ish (write-once, read many). This means that it’s efficient to do logical work during artifact creation that isn’t represented in the underlying content. This requires that the concept of an “artifact” be something that is repeatable and ultimately disposable.

Aggregations of content can become content, in and of themselves. Organizing content creates value, and that organization often needs the same services that the constiuent content needs.

There’s a temptation to structure content as tightly as possible, but in doing so, we can inadvertantly increase the work require to create, manage, and deliver it. Our goal should to find the right balance between exactness and usability.

The creation of content requires a complete different set of tools than that required for the management or delivery of content. They are three phases along a continuum, each gated from the others, and requiring a different appoach in mindset and tooling.

All humans interact with data, just at differing distances from its raw, original state. The bytes on disk are “raw” – editors work with processed data some distance from that; designers at yet a further distance; and a human consumer at an even further distance. “Distance from data” allows for processing, refinement, and creation of value.

Content demands specific functionality, such as versioning, permissions, editorial tooling, etc. Data does not require this. The difference between what a system calls “content” and “data” is often defined by the services applied to it.

An artfiact that is fit to be consumed is the end result of a content model, editorial process, and artifact publishing process that’s designed to be hidden from the public.

Some content management scenarios are very open about how the content is modeled and aggregated. In fact, knowledge of this might be key to working with the content. Other scenarios assume ignorance of the underlying content architecture and expose only the refined artifact.

A content management process reflects many of the same characteristics of a complex system. There are flows, stocks, nodes, edges, and vertices.

Managing content means imposing rules. These rules restrict flexibility in service of greater functionality and value. A system with no limits and total flexibility isn’t “managed” in any sense.

Managing a specific unit of content always imposes overhead and can increase risk. In many situations, it’s to your benefit to exclude some content from exposure to humans by preventing it’s management an increasing the friction required to change it.

Content can be structured inside a single property of an object, among multiple properties of the same object, an object in relation to other objects in the same repository, or even in relation to objects in other repositories.

When we say “content management system,” we should be talking about the entirety of technology and human processes that act upon content, not just a single technology platform. A content object can transcend a single platform and become effectively portable.

Content can accumulate deferred work which will be required to re-use the content in other contexts. Experience, skill, and planning can limit or slow this debt accumulation.

A cognitive actor consuming a specific piece content (reified into an artiact) constitutes an “experience.” Technology has advanced to the point where these individual experiences can be managed and optimized.

Content aggregation has a far wide “pattern space” than other aspects of CMS. This means that understanding and mastering how a CMS works often hinges on understand how it aggregates and organizes content.

Content can take the form of logic, functions, or algorithms. This logic or functionality works alongside more static elements in order to affect the consumption of content.

A content management system has multiple layers of data, process, and functionality which have different levels of inertia. Some are very slow and difficult to change, while others might be undergoing constant change.

Content has a lifecycle, from creation to deletion. Additionally, at any given moment, a single content object might exist in multiple versions, each having a lifecycle of it’s own.

Code operates on content, for logical processing and presentation. The two are often released in parallel to achieve objectives. However, in most cases, they are developed and managed separately.

Very rarely is a content object consumed in isolation. Most often, it’s experienced and consumed inside a “cognitive container” like a page,app screen, or episode. That container may or may not be content in and of itself.

There is no “grand unified theory” of content management. A content management system is simply a packaging of the collected experiences and opinions of its designers. Consequently, they can differ markedly from one another.

Like a building, a CMS has “load-bearing” walls, which define what a user can do without developer assistance. How many of these – and “where” they’re placed – have a huge impact on the development of the system over time.

The content management industry can “drift” into other genres, depending on your opinion of what constitutes content. Some systems are designed around managing content, while other manage content as a side feature in service of something else entirely.

The skill level and perceived needs of content technology customers are usually lagging behind what vendors are offering. Their perception of the market and what’s possible are largely shaped by what vendors are offering. Vendors tend to “pull” customers along by offering new functionality, which may or may not be used to create practical value. Many features are “mirages” of value.

There are some specific aspects to content management systems that make them a very attractive development project. CMS is likely the category of software that is re-invented more than any other and more well-represented in the open-source ecosystem.

Users claim to want ultimate flexibility, but when presented with an empty system in which anything is possible, they’re often confused and don’t know where to start. Whether they realize it or not, users need some level of guidance. They are generally incapable of building a content system from an empty shell.

Moving out of one CMS and into another is far more difficult than other types of marketing technology. Therefore, customers tend to drag their feet in moving to a new CMS and will try to find problem workarounds to avoid it.

Blogs are serial – one post after another. Corporate sites tend to be hierarchical. Other types of information domains are grid-like, or tabular. Some are a series of interconnected nodes. When a system is designed, it’s often planned around an assumed shape of content, meaning some systems do better with a particular shape than others.

Content technology is evolved on a pyramid of prior innovation, which means the same opportunitites and trends seem to move through the vendor landscape at the same time. Innovations external to the vendor community will reverberate inside of it in largely the same way.

Customers lag in tool usage due to a lack of awareness, belief knowledge, or capacity in their applicability. They have to have all four of those factors, in order. Failure of one factor will short-circuit the consequent factors.

Channels force content in a homogenous format. At some point prior to the last-mile, content needs to coalesce into a common protocol to be universally templated and then presented for that channel. At what point we decide to do this can greatly impact flexibility.