Several things can go awry if your content model is hastily designed. It usually results in heavy model adjustments that further require development and process changes. In this lesson, we’ll explain why.
Time pressure and a lot of tight deadlines have become a new standard. Therefore, saving time by speeding up the content modeling phase and omitting the relevant stakeholders is often very tempting. But is it worth it?Setting up a content model with pages at its core will mean it’s outdated when the design of the pages changes. These days, when changing the website design every couple of years is pretty much the norm, it means that you will need to redo the content model from scratch.The content model is the centerpiece of content. To redo it, it will also require:
Eventually, a new content model will affect all roles in your company.
Content models quickly patched together often mimic real-life forms or database tables. Not much thought is given if those elements and their content are reused elsewhere. Adding an element for an asset is effortless, but related metadata is often stored in other elements.
These consistency issues force content creators into a lot of copy-paste work that no one enjoys. They’ll start to resent the content model, steering you away from the current setup or overall solution. That will lead to another migration, content model creation, configuration, training, and process creation.
A widespread approach to covering multiple channels is to add elements for a specific delivery medium. Some CMS vendors have these in their templates. Often, there is a Facebook post description or a Twitter summary in the long list of elements. So with every new social network, a new element is added, but when do you stop?
This isn’t how you create a future-proof content model. No developer wants to spend time adding new fields, hooking up the business logic – and then what do the editors do? They copy-paste the content from other elements, which hinders their productivity.
Overuse of WYSIWYG elements and embedding layout information into text has given editors layout-changing powers since the release of Microsoft FrontPage. This approach might be great for a one-person business, but companies with complex content operations value consistency over layout editing freedom.
Developers struggle when their stylesheet is overridden or when dealing with unexpected inline JavaScript. These are things possible when you decide to go for WYSIWYG. While most online channels use HTML, quite a few don’t. Using RegEx to extract useful information from WYSIWYG HTML elements full of tables is complex and error-prone.
Introducing WYSIWYG elements into your CMS will only bring more maintenance. Hurried content models may depend on WYSIWYG because the content model concept isn’t well-thought-out. This will turn out as pleasing for creators in the short term but a more costly and cumbersome problem in the future.
Missing out on useful metadata locks you into using relationships for everything. Linking one item to another will be a must to express any relationship. These tangled relationship dependencies will be a pain to manage and use within the code. If you miss an important relationship, adding it back into the model is almost impossible. A metadata-driven approach is much easier to enhance, maintain, and utilize to surface information in the right context.
Designing content models that are not future-proof wastes everyone’s time. Sooner or later, you’ll outgrow such an inflexible content model, having to redo the content model from scratch.
Headless CMSs are very open regarding their configuration, and it sometimes gives a false idea that because something is possible, it should be modeled so that creators can always decide whether to use something.
However, modeling many edge-case scenario options leads to a bad authoring experience because there are so many options. Similarly, developers must spend significant time implementing and maintaining all model combinations.
A future-proof content model has consistency in mind, so it focuses on improving the main scenarios instead of adding more and more functionality that will be used just a handful of times. Hurried content models are, in contrast, full of “what if” functionality that only adds time to both developers and creators.
At Kontent.ai, we’ve seen all of these cases mentioned here. Even though we provide our Customer Success Services where we offer our guidance, it’s eventually up to you to decide how to use Kontent.ai.There’s always a need to prioritize speed, but there’s a thin line that, once crossed, it’s much more costly than doing it properly at the beginning.
needed for your app to work. Do you want the authors to re-add the same description, alt tag, or categories every time they use a shared asset?
Sign in with your Kontent.ai credentials or sign up for free to unlock the full lesson, track your progress, and access exclusive expert insights and tips!
What can go wrong when modeling is hurried | Kontent.ai Learn
Are marketing scenarios stirring up your pot?Social media are mentioned as an example here because marketing scenarios often raise questions during content modeling. If you’re interested in learning more about them, check out how to consider marketing in your content model.
Tomas Nosek, Boris Pocatko
9 minutes
Content model
