Make your model extensible, maintanable, and adaptible

To make that happen, your model needs to be straightforward to maintain. It is very likely that certain content types will be overused and others underused. Unused structures will hurt the usability as they will confuse users. Some types might hurt the reusability of content items.It's easy to create too many content types and although there aren't any limits, it's beneficial for everyone to keep the number of content types low. In this lesson, we’ll dive into three aspects – extensibility, maintability, and adaptibility.

Extensibility

Check what would be necessary and what would break if you’d 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, e.g., 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 with merging of content types. This will help you to keep the number of types low. Try to be as generic with your content types as possible, whilst 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 big 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 as that way 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. The main idea here is to have at least something reusable prepared for text, images, and metadata when it's needed. This will help you to reuse content with high ROI if editors stumble across it, even if it's embedded in a longer content item. It's easy to replace existing text with a component if there is at least one for which the content model and front ends are prepared. Then, when more specific requirements are discovered, you can easily expand on the existing content type representing your content chunks. Again, if you create multiple content types representing chunks, think about adding a content type snippet for managing things like guidelines, a shared set of fields, or validation for all chunks in one place. Relationships could be related to adaptability as well. So make sure there are semantic relationships between your content items. Those can be implemented via linked items as 1:1, 1:N, or M:N direct relationships, or via taxonomy or linked items representing categories or tags. Another application or respective front ends will then be responsible for using these indirect relationships to create connections where necessary.