This blog post is the first in a collection of posts about Information Architecture within Sitecore. The blog can be categorized as a “How I dit it”, and gives a view about the setup of a flexible information architecture that can be reused in multiple projects.
In 2016, Sitecore introduced a Helix, a document containing the overall design principles applied to a Sitecore project (http://helix.sitecore.net/). Besides this, a demonstration implementation of Sitecore was released, named Habitat (https://github.com/Sitecore/Habitat).
The Helix document covers all aspects of a Sitecore implementation, from Visual Studio project structure to Template definitions, to Rendering implementation. At the time Helix was introduced, I had just set up our own implementation that has similarities with Helix and Habitat: including the separation between foundation, features and projects. However, the solution setup, with the differentiating of the modules in separate projects was a great eye-opener.
At the same time I did not agree fully with all the principles declared in Helix. The most I restrained to is the scope of the renderings. Helix states about renderings (http://helix.sitecore.net/principles/layout/renderings.html):
Renderings, whether they are Controller or View Renderings typically belong to the Feature layer modules as they are connected to business features in the solution. […] Any controller renderings in project modules are typically an example of business logic creeping into the project layer, which should always be avoided.
The direct conclusion of this approach is that HTML is part of the feature layer. In our opinion this is not correct; HTML should be part of the project scope. However, a module in the feature layer can deliver some default HTML, but it’s not in charge of the final presentation mark-up. The main responsibility of the feature layer is implementing business logic deliver the correct data.
This conclusion has much to deal with the setup of an Information Architecture. The crux of this architecture is that I approach a more granular definition of the data templates of feature. Secondly, I see an Helix based approach not as a single application. It gives you all the chances to build for re-usability as well.
Definition of a module and Habitat implementation
In Helix, modules are defined to be “… business-centric”. This means that they should relate to business objectives and group together multiple technology entities that refer to this objective”. However, this definition is rather vague about the scope of the business objective, and thus about the scope of the module.
When thinking about the customer sites we’ve build we recognizing a lot of “business objectives” that are cross-project, and, putting the focus on the data that’s delivered, you can think about these objectives as:
- Every project has News
- Every project has Events
- Every project has Vacancies
According to the Helix principles, these business objectives are the context of our module definition. The Habitat implementation has a likewise bounding context for the News module. This module implements a data template for the News with all relevant fields (e.g. News Title, News Data, News Summary, News Image and News Body) as well renderings for news lists and news teasers.
However, if the Event business objective should be implemented, following the news module approach will result in a new data template definition which (almost) the same fields, only differencing by the prefix “Event” instead of “News”. And again logic is implemented for an event list and event teasers.
This will last, until the business objective is released that on the homepage, a combined list of news and events should appear.
Granularity of a module
When we have a look at the business objectives from an information architecture perspective, we can translate these objectives in a different way:
- News, Events, Vacancies, etc. have Publication properties like Publication Date, Revision Date and Author;
- Events and Training Coursed have Scheduling properties like Start Date and End Date;
- Offices, Departments, Stores, etc. have Address properties like Location Address and Mailing address;
- Persons, Offices, Departments, etc. have Contact properties like Phone Numbers, Fax Numbers, E-mail Addresses, Websites and Social Accounts;
- News and Offices have Geographic properties like a Geo point of Geo Json;
From this list, it’s clear that certain properties appear in several business objectives. From a re-usable approach it is more interesting to define these properties as the level of granularity on which a module is based.
Project Template Scaffolding
When the module definitions are more granular, and this granularity is translated in a set of interface templates, the resulting, project scoped, templates for pages and data source can be composed by inheriting these interface template. An Event template in the project scope might use the interface templates from:
- The Content module, containing title, abstract and main image
- The Schedule module, containing the start date and end date of the event
- The Address module, containing the Location of the event
- The Geo module, containing the geo location of the event
- The Rich Content module, containing the rich text information about the event
Thus it might be immediately clear that the individual features are not able to create an appropriate presentation for the resulting, project scoped Event template. Even a smaller element like an Event Teaser, cannot be delivered by all the individual modules. This is one of the reasons that we believe, in contradiction to the Helix architecture principles, the renderings should belong the project layer, instead of the feature layer.
Summary
In this first article, we gave a high-level interpretation about how the Information Architecture in Sitecore can be defined. It’s based on a granular setup of the features which brings us to a conclusion that the scope of renderings should be moved to the project layer in the Helix architecture. In the next post, a more detailed explanation of the interface data template structures will be described.
MY THOUGHTS ABOUT... 