You need to make a lot of decisions when creating a content model. These decisions involve content types, their structure, their relationships, how everything fits together, and more. At the same time, all content should be easily reusable, uniform in structure, and extendable. I’ll show you how content chunks achieve most of these things with ease and remove mental strain.
What are content chunks?
Content chunks are the smallest reusable piece of content. Imagine a security disclaimer, warranty information, reusable yearly earnings chart, or infographics. These content pieces can potentially be reused in multiple places; e.g., the earnings chart can be featured in a blog post, newsletter, or on social media. This may sound too good to be true, but it’s more than possible with tightly defined chunks!
Reusability of chunks
If implemented properly, showing any chunk of text anywhere and multiple times with one source of truth will be the norm in your project. At first, create a fairly basic content type representing your content chunk; let’s call it “📦 Content chunk” or something like that. This content type will only contain one rich text element with tightly controlled input validation. For simplicity, start with allowing only text. Allow the “📦 Content chunk” to be used in any rich text element.
The developers will prepare a component in the front-end application that will render this chunk virtually anywhere, without any visible change to the content item where it is embedded. This simple approach will let any editor replace any piece of text with this “📦 Content chunk” type if the text needs to be reused somewhere else without worrying that this change will break existing content items. No more copy-pasting. Just converting existing text and reusing it! How neat is that?
Uniformity of chunks
The above concept can be expanded on further. Do you need to reuse images? Allow them in the chunk directly or via linked items or components. Tightly control what’s allowed in these chunks as developers need to update how they are handled on the front end. Do you need to be able to change the behavior or look and feel of the chunk? Implement taxonomies! Add a taxonomy representing various behaviors of the chunk, such as a pop-up window, highlight, or slideshow capabilities.
Taxonomies for adding context
Try to have taxonomies represent more than just the behavior. For example, instead of having a taxonomy called “Text style” and a term “Bold” have a taxonomy called “Importance” with terms “Important,” “Trivial,” and similar. These can still represent bold text on the front end, but more importantly, they add more useful metadata to your content. Tagging a content chunk “Important” gives it so much more context than just labeling it “Bold.” And add guidelines explaining this behavior, so your editors know what these taxonomies mean!
Extendability of chunks
The taxonomies mentioned above are one way how to extend chunks. You may, of course, add multiple choice tagging capabilities, more metadata elements, or nested content types. As with anything, try not to overwhelm your editors because “The agony of choice” (I prefer the German version: Die Qual der Wahl) is a real thing.
Yes, make your chunks extendable, but have a reasonably simple default configuration option available that doesn’t require much input or decision making. Opt-in for more content types representing chunks if your core content chunk gets too complex. And as always, avoid encoding layout information if possible to make your content more future-proof.
There should always be a content type in your content model, allowing for easy content reuse. I hopefully made a clear case for simple, reusable content chunks as an easy way to ensure reusability, structure, useful metadata, and ease of implementation to a project. It’s easily one of my favorite content modeling techniques.