In a previous post we looked at how we can model 🗿 content with Page Types and learned about the value of content governance 🧑🏽🏫.
In this post we'll continue our Content Tree Architecture exploration by learning about Content Hierarchies.
This is Part 2 of 4 in a series on Content Tree Architecture in Kentico Xperience 13. You can read Part 1, Part 3, or Part 4.
📚 What Will We Learn?
Parent-Child Relationships
Content models, when combined with sitemaps, reveal a natural hierarchy of content 🤔.
As two examples, a Video Library landing page likely has child Video pages and a Product Line page usually has child Product pages.
This list-detail pattern is very common in content hierarchies but it's not the only one 😯.
A site might have an Office Location page for each regional office. The Office Location pages could then have a child page for each employee at that office. The Office Location page might not show all the employees working at that location, but it can make sense to organize the employees as children of the Office Location anyway.
With this parent-child relationship in mind, we might be inspired to go and create parent and child Page Types for every content model for our site. There's nothing wrong with this approach, but there is also a better alternative 😎.
Groups and Containers
As we already noted, a Video Library landing page is very likely to have child Video pages somewhere in its descendant page hierarchy. These could be direct descendants as seen in this screenshot of the Xperience Content Tree:
As our content structure and site matures, an issue we will encounter with the direct parent-child structure is there's no good place to add other types of structured content 😔.
What if we want to create some structured Call To Action pages that are placed on the Video Library page with the Page Builder? Where would those go in this example 🤷🏻? We could add them as direct children of the Video Library next to the Videos, but then as the number of Video pages grows, the Call To Action pages will get lost in the list 😧.
Imagine another scenario where we have 5 Video pages being created every business day. By the end of the year there could be nearly 1,300 Video Pages in the Video Library - finding a specific Video could be difficult 😫, especially if we're using the Page Selector to select a Video page to feature somewhere else on the site in the Page Builder.
This rate of content growth would also result in more child pages than Xperience recommends for the Content Tree - "each item (page) in the content tree have at most 1000 direct child pages."
A better approach, which takes a little more setup, is to create organizational Page Types and insert those under the Video Library page - all child content would then be contained in the organizational Page Types 🤔:
Above we can see there are several new pages in the Content Tree (Page Name - Page Type):
- Videos - Video Container
- 2022/2023 - Video Year
- 01/02 - Video Month
- CTAs - Call To Action Container
- Try Our Coffee For the Full Experience - Call To Action
If your are interested in trying out a prescriptive approach to creating these container pages, check out fellow MVP Mike Wills' Page Asset Folder Module library 👍🏼.
Hierarchy and URLs
In the past, we often needed to consider the impact that the Content Tree structure would have on the URLs generated for each page. Adding too much structure could lead to overly verbose URLs and the need for aliases and URL shorteners 🛠️.
Thankfully, Kentico Xperience 13's Content Tree based routing system is more nuanced and easily customizable. It's up to us, when creating Page Types, to indicate whether a Page Type influences the generated URLs.
Organizational or container Page Types can have the URL feature disabled, which means their existence isn't reflected in the Live site URL structure - they exist purely to make content governance easier for marketers 💪🏻.
In more advanced scenarios, this added content structure can be leveraged to add Page-level access control lists (ACLs) to what content is visible to users. This applies to both visitors to the Live site and content creators in the Admin application 🙌🏾.
The disconnection of Live site URLs and content structure from the Content Tree lets us tune content organization to meet content governance needs while also prioritizing visitor experiences 🤓.
Recommendations
Planning
Generally, we model content with Page Type fields but we also need to model content relationships.
A well thought out (and understood) content hierarchy will help our sites scale both in the amount of content (thousands of videos, as an example) and future content usability. What features or new types of content will we need to add that haven't even been imagined yet 🧐!?
The Xperience documentation has specific guidance for sites with a large number of pages in the Content Tree and it aligns with what has been presented in this post.
Ok, so we have some guidelines... but how do those apply to our site's content and requirements? It might not be clear what the best approach is - for developers or content managers 🤷♀️.
I recommend planning a few different content structures. Talk with stakeholders about this plan and then demo the Content Tree variations in the Xperience Admin so they can see 👀 an implementation of the abstract concepts.
Don't get too caught up generating all the Page Type fields or code. We don't even need the Live site running at this point, because the goal is to have a visible Content Tree and identify any areas where scalability, requirements, or complexity haven't been resolved 📝.
Naming
We should try to define a naming convention for Page Types to better represent how a Page Type is being used, because with dozens of landing, structured content, and organizational Page Types, things can get confusing 🥴 if we aren't intentional.
Not only are the names of Page Types reflected in the Administration application (primarily in the Content Tree), but also in the application code.
Our goal should be to align the names of Page Types with how stakeholders (content managers and marketers) would name them so we have a ubiquitous language 🧠 across teams. We also want to help developers be able to make safe assumptions about their use when they see them referenced in code 🤓.
Personally, I like using the conventions below, but yours don't have to be identical:
- Suffixing Page Types with the URL feature enabled with
Page(ex:HomePage). - Suffixing Page Types that is reusable structured content with
Content(ex:NavigationContent). - Suffixing Page Types that are organizational or are less important than their children with
Group(ex:CTAGroup).
You can read more about Page Type naming conventions in the Kentico Xperience 13 Style Guide.
URLs
It's worth pointing out again that the robust content organization we've been reviewing doesn't have to affect our URLs since Xperience allows us to enable or disable the URL feature for each Page Type 🙂.
Disabling it for an organizational Page Type means it won't participate in URL generation for any child pages that do have the URL feature enabled. This lets us organize content as needed while also ensuring our URLs and content structure match the project planning sitemap ✔️.
This is a feature that's new to Kentico Xperience 13 and can free content managers from the tyranny of the "Content Tree is Sitemap" mentality 😒 (we'll touch on this idea again in a later post).
Try exploring it to see how you can improve content governance without negatively affecting the live site experience for visitors.
More Page Types, not Fewer
It's extremely important to note that in the Video Library example we reviewed earlier, each of the organizational Page Types is a different Page Type. Although we could create a generic "Container" or "Folder" Page Type that can organize anything, this approach would lose 😬 one of the most important benefits of these organizational Page Types.
As we will see in a later post, the Allowed Page Types feature in Xperience is extremely powerful and can lead to amazing content governance, but it requires a broader set of Page Types to leverage fully 🤔.
In general, we shouldn't feel discouraged from creating more Page Types. We should create as many as we need to help ensure a well structured and easily governable content tree 👍🏽.
Conclusion
Modeling content is an extremely important step in implementing an effective and maintainable website. But content in Xperience isn't only the individual structured fields of a page - it's also the relationships between those pages. This relationship modeling can be achieved through the organization of content hierarchies in the Content Tree 🧐.
There's also an aspect of content governance that benefits 😇from a well structured Content Tree in a Kentico Xperience site.
Adding layers of abstraction to the Content Tree can lead to a more manageable site, long term. It can make it easier to find content and result in a more intuitive experience for content managers 🤗. Thanks to Xperience's flexible URL feature, we don't have to sacrifice live site URLs or visitor experience for these administration improvements.
These benefits don't come for free. We will need to spend time planning the Content Tree structure after identifying our content models and pages in the visual sitemap. Creating a sample Content Tree structure can help in this planning process 🗺️ by turning the abstract into something more concrete for stakeholders without too much work.
In the end, content organization is one of the tools we can invest in to help content managers and marketers with the work they do customizing a site's experiences, every day.
As always, thanks for reading 🙏!
References
- Xperience Docs: Page Builder Components - Page Selector
- Xperience Docs: Content Tree Limitations
- GitHub: Mike Wills' Page Asset Folder Module
- Xperience Docs: Page URL Generation
- Xperience Docs: Page ACLs
- Xperience Docs: Guidance for Large Content Trees
- Kentico Xperience 13 Style Guide: Page Type naming
- Martin Fowler: Ubiquitous Language
- Xperience Docs: Allowed Page Types
- Xperience Docs: Content Tree Routing
We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!
If you are looking for additional Kentico content, checkout the Kentico or Xperience tags here on DEV.
Or my Kentico Xperience blog series, like:
Top comments (0)