Where does your content live?

If you are almost done with your content strategy study and still wonder what the heck content modelling is good for, this article is for you.

The aim is to close the gap between content modelling and content management. I will do my best. And if you don’t get it in the end, feel free to comment.

Let us start from the beautiful website you see on your screen right now.

1. Final product = What we see

Any digital product like this website is just a code. And as you open and scroll through the website you see smth like this:

Header (so and so big, so and so beautiful, with the main menu inside)
Main menu (so and so big, so and so beautiful, with these sections inside: (‚Startseite‘, ‚Über mich‘, ‚Meine Artikel‘))
and the code goes on and on.

2. Actual code & How it should not be

Have you ever heard the term ‚hardcoded‘? Like developer saying:

„Oh, you can’t find where to change the wording? Oops… I guess I’ve hardcoded it“

Hardcoded content is caught in code like in prison and can only be changed by the developer. Which is very very bad, cause developers are terrible at words. In my example, section-titles are hardcoded.

Main menu (so and so big, so and so beautiful, with these sections inside: (‚Startseite‘, ‚Über mich‘, ‚Meine Artikel‘))

They will stay ‚Startseite‘, ‚Über mich‘ and ‚Meine Artikel‘ whatever content creators do. And even the superpowers of CMS administrator will be helpless against hardcoded stuff. Until the developer touches the code.

3. Actual code & How it should be

So what you want instead hardcoded text is a placeholder. You go like:

Main menu (so and so big, so and so beautiful, with these sections inside (‚@sec1‘, ‚@sec2‘, ‚@sec3‘))

Here you have placeholders sec1, sec2 and sec3 that know where to go and get some good text to display. The text content creators have developed. And guess where would they get it? In RDBMS.

4. RDBMS = Where content lives

RDBMS is a Relational Database Management System. This is where your content really lives. But let us give it a short nice name. Database.

I hear you wondering: ‚But what about CMS? Isn’t content live there?‘ Hold on. Follow the logic. We will talk about CMS later.

The majority of CMSes uses MySQL as it is an open-source RDBMS. In order to show you how it looks inside, I will create a simple Database in Microsoft Access. Hold on.

5. RDBMS & Content modelling

Creating my little Database I made some content modelling decisions.

First of all, I decided on two types of content I want to store: User and Article. These are content types that any website has and any CMS allows to manage.

Let’s take a look at Article content type (1 on the image below) and my modelling decisions around it.

The second step was to decide which attributes the article content type will have. For instance, I decided that any article can only have title, URL, teaser, intro, article body and creation date (2 on the image above). It was a content modelling decision, as adding new attributes when the system goes live will be difficult.

The third step was to decide upon formats (3 on the image above). Most of the attributes are long text, however, URL has a link format and Created has a DateTime format. Which totally makes sense, doesn’t it?

The fourth step was to decide on important restrictions (4 on the image above). Date when an article was created Created should clearly have a DateTime format, but cannot be in future. That is why I set up the rule, that the date can only be less or equal today’s date. I also made this field obligatory. Thus no article can be saved until Created field is correctly set.

What I’ve just done, is described in Deane Barker’s slide above.

6. Relational Database & Why is it relational?

This is how our little Database looks like:

And now answer the question:

Can we find out who is the author of which article?

The correct answer is no, as there is no relation between those content types. Yet.

To create a relation I added one more attribute to an Article called AuthorID. Here I am creating a relation between User’s ID and Article’s AuthorID.

Relation type 1:n means that 1 user can relate to many articles. And if you take a closer look at the checkmarks you will see some dangerous stuff going on. The last checkmark means that if a user is deleted then all his/her articles will be deleted too. Sure, you will have consistency and no articles-without-author will be floating around, but it might not be the best solution. This is how it looks like:

So now you know what Relational Database Management System means and why it is called ‚relational‘. Our example is tiny in comparison to real RDBMSes behind CMSes you use.

7. What is the difference between CMS and RDBMS?

Once I worked in the medical centre, where employees had to take backdoor when coming and leaving the building. The front door was only for patients. In the Content strategy world, the front door is called frontend and the back door is called backend.

So your CMS is a nice and user-friendly tool for editors to manage content inside of the Database. Or would you prefer working with tables and relations as I showed you above? Of course not. And whenever a user comes through the front door they receive content directly from the Database, CMS is not involved here.

8. Explanation evaluation

Was my explanation helpful? Do you feel confident in understanding where content lives?

If not – please give me some feedback on how to improve the article.

If yes – write in comments your answer to this question: How many authors can an article have in this Database?