Eval Criteria # 1
What is the built-in content model?
In college, I read a textbook about communication that said:
There is no opposite of communication. You can’t not communicate anything because even the absence of communication in itself communicates something.
The same is true of a content model. A CMS can’t not have a content model. If it stores content in any way (which it would have to, being a “CMS” and all), then it has to store it according to some rules and structure, no matter how simplistic.
Consider a wiki. The most basic wiki in the world has two fields: (1) a title, and (2) a body of text.
Simple as it is, a wiki has content model. What you type in the @attr:Title field is the…title, and what you type in the @attr:Body field is the…body. The title isn’t the body and the body isn’t the title, and we know this because there’s a declared model behind it. Simple as it is, those two things are distinct, named attributes.
We’ll call this the @term:"built-in model”. This is the model the CMS uses internally, and enforces at some level.
It’s common for most systems to require every object to have a @attr:Name or @attr:Title attribute. Often, every content type gets that by default. Many systems will also have another text field for @attr:Body or @attr:Content or @attr:Text. While it stores characters just like the @attr:Title it’s generally a larger field, accommodating more text, such as a raw textarea or a rich text editor.
The Default Editorial UI Often Reflects the Model
The easiest way to discuss a content model is to visualize the editorial interface, because, in most cases, all the attributes of a built-in model are reflected in the user interface (UI).
In addition to the @attr:Title and @attr:Body, the Movable Type interface above also shows some built-in attributes that might get classified as “metadata,” or “data about data,” which we’ll talk about in the next chapter. These are attributes such as:
- @attr:"Publication Status”
- @attr:"Publish Date”
- @attr:"URL Segment” (“Basename” in the image above)
- @attr:Categorization
- @attr:"Change Note/Comment”
These are properties that will never display to the public – so they won’t be directly consumed by a human – but which exist to change the behavior of the content.
Now, remember back to our discussion of theory – our simple wiki content model and the default Tumblr model shown above still provide us with some benefit:
- We have names and labels, so we can separate the @attr:Title from the @attr:Body
- We can tell the editing interface that the @attr:Title should be a single-line textbox, and the @attr:Body should be a multiline textarea (perhaps even a rich text editor)
- We can ensure that every content object has a @attr:Title by refusing to create or update an object unless a @attr:Title has been entered
So no matter how simple, a content model gives us some advantages.
Knowing the built-in model is helpful because you need to know what you have to work with and how you might need to extend it. Additionally, knowing the built-in model gives you some insight into functionality – if a system is managing @attr:"Start Publish” and @attr:"Stop Publish” dates, then it clearly allows scheduled publishing and expiration; if it manages @attr:"URL Segment”, then it must allow URL management.
In most every situation, the built-in model won’t encompass all of your requirements, and you’ll need to change or extend it. Let’s talk now about whether/how that’s possible.
Evaluation Question
- What is the built-in model – what content types are in the product as installed, and what attributes do they possess?