Information Architecture in a Helix Era – Part 2 – Outline of the module interface templates

This blog post is part of a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How we do it”, and gives a view about the setup of a flexible information architecture that can be reused in multiple projects.

In the previous post about this subject, a high-level overview of an information architecture in the Helix context was given. It introduced a granular definition of features. In this post I like to give a more detailed explanation about the setup of the interface templates

Template types

The Helix architecture document gives a set logical template types:

Template Type Can have a page layout? Exists is which layers
Interface template No Feature or Foundation
Page template Yes Project
Datasource template No Project
Settings template No All
Folder template No All
Rendering parameters template No All

A detailed description of these template types can be found in the Helix documentation ( You’ll maybe notice that, in contradiction to this documentation, in the table above the settings template is upgraded to have existence in all the layers.

Our first Content module

One of the most basic (business) objectives when you talk about content is the base of all types of content: it always starts with some title. Secondly, to share content, or to summarize the information, there is some abstract. And at third, most content is accompanied with an image.

This title, abstract and image can have an alternative function as well: they can function as the SEO data, the Open Graph data or the Navigation as well. Or, these data can be the fallback for more specific implementation in respectively the a SEO module, Open Graph module or Navigation module.

Because of this dependency, the Content Module should exist in the Foundation layer. The interface template definition of the module looks like:

Name Base templates Fields
IContent Standard template
_ContentTitle Standard template
_ContentAbstract Standard template
_ContentImage Standard template

Or as an image:

Sitecore Interface Template - Helix - Content Module
Sitecore Interface Template – Helix – Content Module

As you can there is a very large degree of partitioning in the module. Instead of the maybe expected single interface template, four interface templates are created, where there is also a completely empty IContent template.

In the introduction of this paragraph some reservations were made about the fields: information might have a title, an abstract or an image, and not necessarily all three at the same time. And because Page and Datasource templates are scaffold in the project scope, we need the ability to select zero, one or maybe all three the fields. Using the setup in this way, it aims us to do so.

At the same time, we are able to determine with one single question if the Content module is part of a project scoped page or datasource template: it the IContent template part of your base templates. If this question is answered positively, we know that at least one of the three fields is implemented in the project scope, and we can ask the module to give us an appropriate model for displaying the data.

A rich content module

A second module which contains functionality that can be re-used in projects is the rich content module. You can think of many examples where an editor should be able to add rich content through the rich text editor of Sitecore.

The rich text editor can be configured in multiple ways by attaching a desired Html Editor profile. Out-off-the box there are multiple profiles, which can be copied and adapted according to project specific preferences.

At this moment we are challenging an interesting situation: the configuration of the rich editor is set through the Source value of the template field. However, the rich text editor is created as a module on foundation or feature level, and there is no way to override the source value on project level. We’ll keep that as a future challenge and have our first implementation of a rich content module:

Name Base templates Fields
IRichContent Standard template
_RichContentBasic Standard template
_RichContentMedium Standard template
_RichContentComplete Standard template

It’s important to note the name of the fields. Where the Content feature has three different fields, this feature has three times the same field: RichContentBody. The idea is that within the project scoped templates, one of the RTEs is used, based on the nature of the content written. In some cases, a basic text editor with only the ability to make text bold or italic is desired, while in other templates, a complete rich text editor, with all its capabilities is necessary.

Sitecore Interface Template - Helix - Rich Content Module
Sitecore Interface Template – Helix – Rich Content Module

Constructing a project template.

With these two simple modules we can create our first project scoped content template by inheriting the interface templates from the Content and Rich Content modules. But before we scaffold the template, we introduce two other interface template (which have to find their way in a foundation module):

  • IPage
  • IDatasource

The role of these templates is to make a distinction between all the content that has an url and all the content that is rendered indirectly through Sitecore renderings. This information can be useful in the case of search for example: the search results should only contain content that inherit from the IPage template, because this content has an url.

With these interface templates we construct two project scoped templates: a content page template and  a content datasource template. It will be clear that these are simplified examples:

Sitecore Project Template - Helix - A constructed page template based on two interface templates
Sitecore Project Template – Helix – A constructed page template based on two interface templates


Sitecore Project Template - Helix - A constructed datasource template based on two interface templates
Sitecore Project Template – Helix – A constructed datasource template based on two interface templates


In this post we defined the interface templates for two modules. A characteristic of this interface templates is that each module contains one empty template which is prefixed with an “I”, using the naming convention: IModulename.

The fields of the module are setup in a flexible way. Thus, the project scoped page and datasource templates can inherit only these fields that apply in the project. Because all fields inherit the IModulename interface template, it’s immediately clear which modules are applied to the project scoped page and datasource templates.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s