The process of creating components in Tridion has always been very different from creating pages. When you create a component you are guided by a schema, which provides strict guidelines. However, when you want to create a page, you start off with a tabula rasa – essentially a blank sheet of paper.
This changes with the introduction of regions and page schemas. Here’s how.
When you set out to write a component (say, a news article, or a product description), you are very much guided in every step of the way. Tridion will tell you which text fields you need to fill, it will allow you to add styling to your text – or not – and how many images you can add (and which types of images). Tridion describes which fields are optional and which are mandatory, it will allow you to create links to other content – but only if it’s of a certain type -, it will instruct you to classify your article with metadata, etcetera.
All these rules (and many more) are laid down in a schema. Schemas provide the structure your content needs.
When you create a page, however, the process is completely different. A page is basically a blank page in a photo album.
A blank photo album page
As an editor you are completely free to insert photos of different shapes and sizes, in different positions and of different types. This freedom comes with great responsibility. It can easily lead to a mess:
A rather unstructured album page
No matter how pretty the photographs are, the end result is a disorganized and therefore ineffective album page.
SDL has thought about this, and they have come up with a solution: page schemas. A page schema provides structure for your pages, much like a regular schema does for your components. To continue the analogy with a photo album a little bit, an empty page which has a schema attached to it, might look like this:
Or like this:
Or like this:
It is easy to see how these ‘predefined page layouts’ can help the editor to create more structured pages in a shorter amount of time. In Tridion 9, this approach is now possible thanks to the introduction of page schemas.
A page schema breaks a page down into regions. Each region contains a number of component presentations, that together make up the page:
The colors symbolize regions
Regions contain component presentations (or other regions, more on this later). It is possible – and this is a major change – to limit which component presentations the editor can add to a region. You can constrain them by schema or component template, or both, and you can constrain the maximum number of component presentations that are allowed in a region.
In the example above, the pinkish region at the top could be constrained to a single component based on the schema ‘Hero banner’, while the yellow region on the right might be constrained to a component template called ‘Call to action’ and a maximum of 4. The blue area could be unconstrained, so editors can still add anything they like in there. This is of course just an example of how you can model this type of page!
I think page regions are a useful addition to the tools that we as implementers have to make the life of the Tridion users easier. And if SDL would want, they could make them even more useful quite easily – more about that later.
How will regions change the implementation practice?
Many implementers of Tridion were used to minimizing the number of page templates in an implementation. Since the content on the page couldn’t be influenced by the choice of a page template, it seemed a needless complication to force editors to choose between many different page templates. Any logic needed to split the component presentations into ‘regions’, was put in the web application instead.
Now with the introduction of real regions, it is likely that implementers will increase the number of page templates. This is necessary because a page schema is always based on the selected page template – it is not possible to select a page schema from a page directly! Each different layout of a page could be modeled as a separate page schema, and hence a separate page template.
An implementation of Tridion Sites 9 might contain page templates like:
- Hero + wide main area + banners on the right
- Hero + wide main area but no banners
- Hero + blocks in 3 columns
- Hero + blocks in 4 columns
- Wide main area without hero
- …
The list could become quite long. One problem with this approach is naming: how can we make it clear to the user what kind of page layout they are selecting, if we can just show them a name? It would be great if the UI would be able to show simplified diagrams (like you can do in XPM).
But aside from the name, there is a risk that the list of page templates / page schemas becomes too long to be workable – or maintainable for that matter.
However, as an implementer it is up to you how specific you want your regions to be. Take the following two page types as an example:
We may choose to implement these page types with two different page schemas (and page templates), called ‘type A’ and ‘type B’, as shown in the diagram above. Each schema has 4 different regions, and they only differ in the order of the red and the green region.
However, we could also model these page types differently:
In this example, both types of pages can be created with a single page schema. The ‘blue region’ is made a little bit more flexible, to make sure it supports both variations.
What does this mean for the editors? Well, they need to take more decisions. They have to know, for example, that the blue region should contain either two small blocks followed by a large one, or one large block followed by two small ones. This is exactly the type of decision making that SDL is trying to get rid of! But it may be a necessary evil. If we don’t allow some flexibility, editors will be confronted with a huge list of possible layouts – and that is also not desired.
I think we will probably end up offering editors around 10 or 15 page schemas to choose from, with most of them allowing some editorial freedom in one or more regions.
Could editors insert regions themselves?
The conundrum could also – theoretically, at least – be solved in a different way, namely by allowing editors to choose from different regions to insert. Let’s take another look at our earlier example:
What if we could offer the editor 2 choices:
- First pick an over-all page layout by choosing a page template (say ‘hero image + right banners + main content’)
- Next, let them choose a layout for the main content area (subtype A or B)
Like this:
Looks great, right? It is a way to offer the editor a structure to guide him or her when creating a page, without confronting them with a myriad of choices. There is only one problem: it is not currently possible with Tridion!
To make this work, we would need two things:
- Nested regions (regions that sit within other regions)
- The freedom to insert a region into another region
The good news is that nested regions are supported already. In fact, each page schema is a region in its own right, and all the examples I gave earlier use nested regions. But each of these nested regions is determined by the implementer, and is cast into its parent region. The mold of the page is thus provided by the implementer, and cannot be modified by the editor at all.
If you agree with me that this would be a good idea, please go to https://community.sdl.com/ideas/sdl-tridion-dx-ideas/sdl-tridion-sites-ideas/i/sdl-tridion-sites-ideas/allow-editors-to-insert-regions-into-a-page and upvote it!