Introduction
In the previous posts of this migration series, we have looked at technical ways to migrate content from Kentico EMS to Kentico Kontent without really worrying about the architecture or setup of the project(s). This post will zoom in on this topic and provide insights in helping you making the right architectural decissions.
Content modelling in Kentico Kontent
Before we continue I would like to highly recommend the following series of articles from one of my fellow Kentico MVP's Michael Kinkaid, who did an amazing job serializing his thoughts on content modelling best practices into a human readable format:
Content Modelling in Kentico Kontent Part 1, Part 2 and Part 3
Definition of a Project
Taken from the documentation the terminology of a project in Kentico Kontent is: the primary way to organize your content. You can use a single project to store all related content that you are trying to deliver across various channels (a website, a mobile app, an IoT device).
Despite this clear definition, I initially treated a project in Kentico Kontent similar to a website in Kentico EMS. With Kentico Kontent you have the flexibility to create unlimited Projects (without additional costs). This freedom made me apply workarounds for specific requirements which with todays experience I would have definitively have done differently afterwards. 😅
Ask yourself the following questions:
- How do Projects relate to Sites in Kentico EMS? Are they the same? In case of migration from EMS to Kontent would you migrate Sites to Projects?
- What kind of issues will you run into when putting everything inside one Project? Think of Roles, Workflows and Permissions. Is the system flexible enough to handle the exceptions?
- Do you need to share content between Projects/Sites?
- Would you consider using multiple Projects to seperate Production data from Test data? Or would you handle this differently in regards to upcoming features based on the Kentico Kontent Roadmap?
If you have no issue answering them all then I envy you. For the rest let me share what I have learned over the last couple of months. 😄
Project != Website
As described in the previous section, I looked at Kentico Kontent Projects in a similar way as I looked to Sites in Kentico EMS. This means that we would typically manage all the content inside a content tree that represents a single website.
This is a great starting point but consider the following: if you don't have the concept of a content tree, often used to represent the sitemap of a website, is it really that important to have multiple Projects to distribute the content over multiple channels?
If you would ask me now, I would answer NO to this question. 😱
Question still remains if you can provide a good experience to your content authors and especially ensure that they only see the content that matters to them.
Providing the best Author Experience
Kentico Kontent is constantly being enriched with new features to help content authors in their day-to-day job. At the time of writing the following features are already available for you to enable and provide an even better experience.
Role-based access to the right content
I am a big fan of simplifying things and distributing content elements over multiple tabs. In Kentico Kontent this can be achieved using content groups. Content groups allow you to present a group of content elements in a tabbed user interface.
The benefit of this progressive disclosure approach is that it allows you to improve the author experience, because you can influence the amount of content elements the editor directly sees when working on a content item. This in combination with role-based access allows you to have full control over who can edit content types and control the access to content elements via the permissions applied to content groups.
Personally I prefer to distribute content elements among channel specific groups. This allows differentiation between e.g. web content (SEO title) and social media content (Twitter title). The channel on the other end knows which data it requires for presentation, and fetches the data from the headless API.
Finding the right piece of content
When working with headless content it is important to have a tool that supports logical flows to drill into your content inventory. Speed and UX are crucial aspects that make or break a productivity tool.
A personal favorite of mine is the ability to compose taxonomies. Taxonomies allow you to manage a list of words (simply put) to support categorization of your content. The taxonomies are automatically added to the content filters and list only the content that is assigned to the selected terms. An additional advantage is that taxonomies can also be used to create relationships between content items.
Content filtering using taxonomies in combination with other key filters like content types and workflow steps should be more than enough to help you easily find the right content. Alternatively you could always rely on the full-text search. 🔎
Content planning
Sometimes a different view on the matter helps to understand what the actual status is. Dashboards and editorial calendars are great tools to get a better picture of the current situation.
The key to succes within Kentico Kontent is to setup a workflow to represent the content lifecycle. By also assigning due dates to content items, chief editors can quickly address content that requires direct attention.
Summary
The key takeway of this post is to think carefully about how you are planning to use the concept of projects to distribute your content over multiple channels. Do not assume by default that every site within Kentico EMS should be 1-on-1 transferred to multiple projects in Kentico Kontent. Hopefully the provided questions and examples will help you in your decision making process. Happy architecting! 😃
Top comments (0)