Working with the Sitecore platform for 14 years, I’ve seen a lot of different approaches to organizing the content tree. Those approaches have changed over time as features like Web Edit (remember that?) have evolved into the current Experience Editor and beyond to Horizon.

The Past

Content trees from 6 to 10 years ago favored a context-driven approach: It was common for the Context Item to inherit from a vast array of scenario specific contracts (Data Templates). Content Authors signed into the Editor and filled out a form, which magically transformed itself into the appropriate page via Preview. If you needed to swap out parts of the page, the most common solution was to provide a field (or fields) on your Context Item that allowed you to set the content for that page fragment. Back then, Web Edit mode wasn’t particularly user-friendly and the budding Page Editor was… less than feature complete.

Into the Future

Today the content tree structure must treat Experience Editor as a first class citizen. In the future, Horizon may make it the only interface your content authors use. If you’re lucky enough to be using SXA, you already have no choice. The days of monolithic page Items are gone. What killed them off?

• Modern content authors want to be able to assemble ad-hoc pages from a variety of “blessed” components.
• Marketers want to be able to test messaging and design on-page, in real-time.
• Companies want to establish deep connections with their customers by making content on each web page personally relevant to each visitor.

While it may fundamentally be a “page” in the sense that your browser loads a URL, which (usually) causes delivery of an HTML document, today’s web pages are living applications, making real-time decisions to deliver a veritable custom micro-magazine to the customer.

Convergent Evolution

In biology, convergent evolution is when two unrelated organisms (like birds and bats) independently evolve similar traits because they both have to adapt to the same environment. Guess what? The same thing happens with Sitecore installations. There’s a “best way” to organize the content tree. I’ve seen it evolve of its own accord at 5 different agencies, even before the advent of Helix or SXA.

Prototype

Above is an archetypal Sitecore website that is fully compatible with Experience Editor. Each “Page” on the site has an Item that represents the URL, probably some meta-information, and the presentation details for that particular URL. We’ll use the “home” node as our example page.

Below “home” is a housekeeping folder (highlighted). I’ve seen it named “hidden”, “data”, or “parts” depending on taste, but it always serves the same purpose. This folder holds the datasources for Renderings that are in the Presentation Details of the parent page (“home” in our case).

The nodes below our highlighted “_subcontent” folder are datasources for the following Renderings:

• Jumbotron
• Content Section (2 instances, different datasources)
• Related Links

These datasource Items have a common trait: they are unique to the “home” Item. You wouldn’t see any Rendering anywhere else in the site reference the datasources stored at ~/home/_subcontent/*

That’s not the whole story for our home page though, because it also has these Renderings:

• Analytics Scripts
• CTA Row (sublayout)
• CTA Card (3 instances)

Each of these Renderings needs a datasource, but in this case, the content they render might be visible on more than one page. If you reference the above content tree, it’s pretty obvious that those Renderings draw their datasources from the highlighted ~/widgets/* folder.

Core Semantics

One glaring difference between Sitecore and most other WCM systems is that Sitecore offers no data constructs beyond Item, Template and Layout. Sure, Templates define Items, and Layout tells us what the Item looks like, but missing are hard and fast solutions for navigation, meta data, content blocks, even columns, rows, tabs, lists, galleries, and breadcrumbs (to name a few that every client assumes are “stock”). Sitecore expects you to roll your own.

Stepping back to our convergent evolution, it’s obvious that we need some sort of semantics that allow us to quickly develop the above “missing” features, preferably in a way that’s reusable between projects. Here’s the core object types every Sitecore install needs to be successful:

A Page

Sitecore actually makes this decision for us, as we need a place to put the URL and a place to specify what that URL sends to the browser. If we have any digital marketing people on our team, this is also where they’d want to put SEO-specific meta information.

Optional Content that is Unique to its hosting Page

With Experience Editor, the more options you can provide the author, the better. This means that a “page” might be virtually devoid of content and presentation when created. It’s up to the author to add sublayouts and renderings to the page to achieve their message. However, from an SEO perspective, it’s important that the page have an overwhelmingly unique message, thus the majority of datasources for any Renderings added to the page should be considered unique to the page.

Optional Content that can be Shared between Pages

Looking into Sitecore’s Personalization and Multi-variate testing features, we can see that there’s a need to provide the visitor with enticing calls to action: Content that starts a funnel that leads to a good business outcome (and ultimately more money for the business). Well need a bevvy of options depending upon:

• the different types of visitors coming to the site
• the products and services the site offers
• whether the company has an existing relationship to the visitor
• whether the company has something timely that they want to present to the visitor.

That’s a lot of potentially useful content, but it’s not usually primary content. It’s the pitch. We’re going to want to expose this content broadly across the site so the visitor has every opportunity to enter our funnels, or, if we see they’re not responding to a particular message, swap it out for one that’s more relevant.

Keying this content into every page would obviously not make sense. Scattering it across the site in page-specific folders makes it too hard to locate (using Sitecore’s UX) so instead we’ll store it in centralized repositories. Just in case they need to access it from site #2…

Enter Constellation

This philosophy digression has a point: Constellation ships with this paradigm ready for use. Install Constellation.Foundation.Datasources and you get the schema defined above, along with Rule Conditions and Rule Actions to make it painless to maintain. I’ve been using this particular bit of kit for 7 years now, and I haven’t found a website where the UX or business strategy didn’t fit. It works for multi-language, it works for multi-site. It even works if you’ve got multiple vendors with different approaches in your system. You can layer this library in and it will only take effect if you opt your existing Data Templates into it.

Starting with this basic set of principles makes Sitecore development incredibly straightforward. It is 100% Helix compatible. Sitecore themselves are using a similar strategy within SXA. Thanks for making it this far, I hope you’ll take a look at this library and the others that Constellation has to offer.