Make your model extensible, maintainable, and adaptable

Extensibility

Check what would be necessary and what would break if you tried to:

Add new elements/items/types
Change the order of elements/items/types
Change the names of elements/items/types
Change the structures of elements/items/types
Delete elements/items/types

Note down issues and other findings in a shared space where stakeholders can address the shortcomings as part of ongoing improvements. Incorporate this into your yearly maintenance. Addressing extensibility is tricky, as it involves ongoing content model changes, which should ideally be automatically reflected on your channel front ends. If possible, draft a specification on how the front end should be handling content model changes, which you’ve identified in the previous steps. Focus at least on the most important use cases. The front ends shouldn’t break if:

You add items or elements
You don’t fill out elements that don’t have validation setup
You change the order of elements
You change the name (not codename) of elements

Ideally, in other cases, the front ends should fail gracefully, and you should be notified of these occurrences automatically if possible. This is, of course, something developers are responsible for, but it first needs to be brought to their attention. To make your content model as extensible as possible, consider using and over-using content type snippets. Snippets allow you to essentially inherit a set of elements, guidelines, and validation associated with these elements. If you decide to change anything related to those fields, the change will be reflected everywhere they’re used. You can also add elements and extend your content model pretty easily that way. If you keep your hierarchy flat, 2–3 levels deep, you can still add a joining M:N relationship to connect content items that were previously thought of as unrelated.

Maintainability

Set up yearly content model reviews where you check how certain content types are used. This can be a joint effort together with content audits. Content audits are maybe even more important than content model reviews, so make sure you perform them regularly. Check if duplicate content is created due to your setup, for example, creating new content instead of reusing existing components. Check if the content pieces with high return on investment (ROI) are well maintained and if you are getting the most out of that content. For example, does it make sense to chunk it further to reuse parts of it elsewhere? Once you create your content model, check if you can simplify your content types and merge the ones that can be merged. Following approaches touched upon in extensibility, such as using content type snippets, will help with maintainability as well. Naming elements according to a predefined pattern will also allow developers to predict codenames in code. Although they can’t rely on it, it is much easier to write code if you have a predictable pattern present. This pattern is then also returned by the JSON, so the content model is easier to interpret. By using snippets, it’s easier to follow these conventions as instead of specifying the fields in multiple locations, you only do it once. Content type snippets also help with the simplification and merging of content types. This helps you keep the number of types low. Try to be as generic with your content types as possible while moving any specifics into the taxonomy of the given type (Article left & Article right vs Article with a taxonomy alignment). These taxonomies and some of the more generic fields might be implemented via snippets.

Adaptability

Chunking is a significant aspect of adaptable content. To be able to adapt your content for other, previously not thought of, use cases, it has to be sufficiently structured and chunked. These content chunks can be easily reused later on. They help with maintenance as they promote reuse and prevent duplication. But don’t go overboard – you could hurt usability.Using content chunks in Kontent.ai is easy. The first step is to create a content type representing your chunk. As mentioned under maintainability, generic content types are preferable, so these chunks need to be as generic as possible. The more choices you have, the more complex the implementation and usability will be.Taxonomy or multiple-choice selectors will help you to indicate the behavior modification of the chunk if necessary. If you don’t know where to start and what chunks to create, create a generic one called, for example, “reusable text”, and move from there.