My fellow vinyl fans will, I’m sure, be familiar with the album “Babylon by Bus” by Bob Marley, a co-founder of reggae music and arguably its greatest ambassador. In my brain, however, Babylon is also associated with the impossibility of understanding each other without a common language. And what person who has ever had any contact with information technology does not think of data connections when they hear the word “bus”?
I come across it all the time: Specialist departments that have opted for a better content management system (CMS) are surprised to discover that they can’t automatically transfer their existing content pages – for example, the landing pages in their online shop – to the new CMS quickly and easily.
It goes without saying that this is very irritating and can even give rise to misgivings about the competency of the service provider. After all, a lot of work and money has gone into producing the content in the legacy system. So, what’s the problem?
The problem is similar to the problem faced by the astronauts on the Apollo 13 mission, when the square CO2 filters used in the command module were incompatible with the cylindrical filters in the lunar module, which had to serve as emergency accommodation until just before re-entry into the earth’s atmosphere. The fact is that different manufacturers will come up with different solutions to the same problem, at least in cases where no binding standards or specifications exist. In the case of Apollo 13, this almost led to disaster and a lot of improvisation was required to bring the situation temporarily under control.
The manufacturers of content management systems also have very different ideas about this. We are talking specifically about the content model here – the way in which content is organized within the system. Less sophisticated systems do not structure the content further at all. They simply fill a placeholder in the template using the rich text editor and save the unstructured result. Other systems use ready-made content models that can be enhanced to a greater or lesser degree during the project. These models can be structured in many different ways.
For example, a well-designed, object-oriented content model enables properties to be “inherited” along the object hierarchy and elementary content objects to be assembled into more complex content objects.
This provides a great deal of structure, which can help developers to automate editing tasks. And because the content is not embedded into the page, these types of systems are much more suitable for an omnichannel approach.
Each of the different content models fulfills its purpose and you can build a website using any of them. However, things can get a bit tricky if you want to transfer content from one content model to another. This is a challenge typically encountered when switching systems. In general, it is far easier to transfer more complex structures automatically to simpler structures than vice versa.
This can be illustrated simply using white coffee as an example. It is no great challenge to add coffee, milk, and possibly sugar (different content objects) to a cup and stir. However, it is practically impossible to separate the milk, coffee, and sugar from the white coffee (unstructured content).
Before investing a lot of money into content creation, ask yourself how well your investment is protected:
What content model is the system based on?
In what form can I import or export content?
How does the content model fit the content strategy?
Do I need the content only for websites or do I also plan to use it for other touchpoints in the medium term?
So, give some thought to this issue before selecting a system, or you may inadvertently find yourself in another Bob Marley album – “Confrontation.”
Further information on this topic: