Blobs vs. Chunks: Understanding True Separation of Content from Presentation
One of the old principles in the content management system (CMS) world is separating content from presentation.
Sounds nifty, right? But what does it actually mean?
It's about creating adaptive content, or in other words, content that isn't restricted to a single display. Content that is totally separated from its presentation or design breeds many benefits. For instance, it becomes vastly easier to redesign a website or corporate identity without undergoing serious content modification.
This was one of the strongest pitches in favor of content and presentation separation. And it still is, but the truth is that true separation from content is much more powerful than you might think.
Below is an illustration from the documentation of one of our very first releases of our CMS, eZ Publish. It illustrates the basic principle of content and design separation. What it doesn't show is the fact that the content can be displayed in many more ways than just the web page pictured below -- think mobile phones, tablets and watches.
Today, many CMSs commonly store HTML in the content repository, then use CSS to apply the design. In the "blobs vs. chunks" debate, a topic made popular by Karen McGrane, these masses of HTML are the blobs. From a development perspective, storing HTML directly in the repository as blobs is a tremendously smaller effort than storing semantically channel-neutral XML, it is also lazier.
The blob technique handicaps your content. Once your content is stored in HTML, you're stuck to display your content only on specific HTML-based presentation devices.
Garrett Moon, of Todaymade.com, has a great explanation for why blobs can create problems. "To start, blobs are presentation-specific, meaning they were meant for a single purpose or device. A magazine spread is a perfect example of this. The text, story length, images, and callouts are all baked together in one perfectly sized space. The design and text are one."
At eZ, we see the flaws with blobs and our philosophy is on the other end of the spectrum. Since version 1.0 of eZ Publish, we've stored clean semantically-defined XML in the database, allowing for reusable content in other channels. This approach is otherwise known as the "chunks" approach.
When content is stored in chunks, your organization has access to clean REST APIs, web to print capabilities, simple digital signage creation and integrations with a wide variety of devices like the Apple Watch. Today, many of our customers use eZ Publish for digital-first purposes, and take advantage of channel-neutral content. Because of the chunks approach, our customers can easily convert their content to InDesign, FrameMaker or other formats for print.
The chunks approach makes your content flexible. You're no longer restrained by the boundaries of blobs.
Note: You can learn more about why remaining channel-neutral matters by reading our post on content modeling.
Semantic Encoding vs. Markup
Keeping semantic structures is becoming increasingly important as technology continues to develop. Semantic encoding tells us something about our content, whereas markup does not.
For instance, many visually impaired individuals rely on text-to-speech translations, and the better job your site does at semantically defining content, the easier it will be to interpret when read aloud.
A good example of this is italics. In HTML, this is written with the markup <i>italics</i>. What this doesn't tell you is why the word is being italicized.
Applying a semantic meaning like <emphasis> or <strong>, which is what we use in eZ Publish, is much more efficient, and in the long term, a much smarter way to structure your content. By using <emphasis> or <strong> you can highlight the words importance in the sentence.
Keeping the semantic meaning might seem stupid if you are thinking purely about the web and mobile experience. For the web and mobile, you can get by using HTML for the presentation. In eZ Publish, the template that renders <emphasis> is actually converting this to an <i> tag for HTML presentation. So, why is it different?
Think of the multitude of future devices that italics won't apply to. Let's say you want to have the text converted to voice for the purpose of a smartwatch. In this case, <emphasis> makes much more sense than <i>.
Keeping semantic meaning has been a big principle for eZ since day one, and remains paramount to this day.
Even if you are using chunks, as suggested, you still need to define content structures in a sensible and reusable way. You need to think about content in an object-oriented fashion. By creating itemized reusable chunks of content, you can allow maximum reuse of the content in the future.
You also need to think about different variations of content. For example. the title of a piece of content should be represented in a long and short (or even small, medium, large) form. You can't be sure where or how your content will be presented in the future, so creating content that is flexible should be considered essential.
However, this means more work -- sometimes double, or triple -- for the editorial team as they have to think about multiple channels and devices when writing content. But by semantically tagging your content, you give it infinitely more value to be reused in the future.
Know What You Buy
When you're looking to purchase a new CMS, make sure that you're aware of the way the system is storing its content internally.
You might be surprised, and perhaps you haven't seen the value of true separation of content from presentation until now. But I would be shocked if there's not something new just around the corner that will require your organization to present its content in a different way -- and it is best to make sure you're ready for it.