Content is Data, Data is not Content

According to the World Economic Forum, the number of bytes in the digital universe in 2021 is 40 times bigger than the number of stars in the observable universe. As the number of internet users continues to grow, the amount of data generated each day is expected to reach 463 exabytes globally by 2025. Data is literally everywhere and consumed anywhere, from smartphones to laptops and connected devices. But how much of that data is actually content?

Content vs. Data

Content is Data. Data is not Content. Intriguing isn’t it? We often use these two words interchangeably although they are completely different by nature. So let’s start with definitions!

Content is about context. The context gives a meaning to the data. Good content is often an aggregation of data coming from different sources and types.

Data is the root of the information, it’s the raw value. Without context, there is no meaning.

For the sake of this example, let’s use the following sentence: “27°C in August in Spain is a cold summer, while 181 centimeters means you are considered as a tall person in Western Europe.”

In the previous sentence, we have multiple data to extract. The temperature (27°C), the month (August), the country (Spain), the period of the year (summer), the feeling (cold), the height (181 centimeters), the feeling again (tall) and the region of the world (Western Europe).

Now, imagine we store these data somewhere in a database. Could you recreate the previous sentence from these raw values? You can’t. The process is irreversible. You could generate hundreds of sentences with completely different meanings though, such as the following one for example: “In Western Europe, in August, tall people suffer more when the heat exceeds 27°C, especially in Spain where the summers are usually not cold.”

Content and data are similar to song and music notes. What makes good content is usually the uniqueness of the data aggregation and order. Ditto for a good melody or song.

The rise of Headless CMS

Why are these differences and definitions important? As one of the co-founder of Strapi, a new generation of CMS called Headless CMS, I have seen the barriers between content and data lowered. The main reason is because Headless CMS forces us to think about the content structure in a destructured way. The true power of a Headless CMS relies on the ability to break down the content structure into smaller pieces often called fields.

While it opens new opportunities to build incredible digital experiences, it also tends to be the perfect application of Conway’s law in the user interface. In other words, Headless CMSs start looking like modern administration panels for apps whereas they should be designed as a unique space to empower content editors to write good content.

The reason behind that shift to a data-centric approach in Content Management is rather simple. With data, you can aggregate, filter, sort, modify, calculate, edit them and finally tell a completely different story. Content is the story you want to tell. Content is the format and the structure you give to your data to have a meaning. When we apply these tenets in the Content Management System field, the impacts are important. In a world where collaboration is key, we don’t collaborate on raw data, we collaborate on content, sometimes in real-time/ We comment, we make suggestions, we bring creativity, we try to surprise, we think about the message and the audience. These principles don’t apply to data. We create, read, edit or delete data. It’s a value that we store for later usage, or not. To make it brief, we feed computers with data and humans with content.

As a result, content should not be handled like data... Data is managed by databases. Content is managed by CMSs.

Moreover, in terms of personas, they tend to be the opposite. Developers interact, store and consume the data. They care about the format, the way to retrieve and optimize it. Content Editors have other expectations. They look for a purified user interface, real content management functionalities to publish their next article at a specific date for example, and powerful tools or integrations to gather data from different sources in order to write thrilling stories. As the expectations and usage are different, the user interface should not be the same. Similarly, Content Management Systems can be developer-friendly, but they should not be built for developers. As the developers influence more than ever the final decision when choosing a new CMS they cannot be ignored. On the other hand, it doesn’t mean we have to forget our roots and why Content Management Systems exist.

Treating content as data makes sense for developers and gives them the flexibility they need to build modern digital experiences. It also opens new opportunities to create unique personalized experiences for specific audiences based on criterias such as geolocalisation, types of device, or user preferences. Headless CMSs are still CMSs, they still manage content, however, they require more granularity and more discipline in the structure to spread the content anywhere, beyond a simple computer’s browser. If we manage to keep that frontier between content and data visible while providing new capabilities, we are just at the beginning of a new era for digital content experience.