Structuring Content Within A Site In Sitecore

Recently, in a discussion with the team regarding how to structure content in Sitecore brought up some very interesting theories which I thought would be useful to share.

So, my theory was that enterprise content should be grouped reflecting the business structure, as I discuss it here) and taking it one step further, using the same logic to structure content within a site. But this idea was promptly met with rejection. The counter theory offered was that the content should actually follow navigation paths used by visiting user personas. This immediately brought to light a rather large assumption:

      Do we assume that the content tree structure in Sitecore dictates the navigation paths for end users?

The answer is, not necessarily. In my view, the minimum requirement should be to facilitate logical grouping of content that always avoids content duplication.

I think there are two primary ways of implementing navigation paths:

1. Create navigation components such as Primary Nav and Left Rail Nav, which offer explicit suggestion to the user regarding how the business assumes the user should navigate the site.
2.  Navigation using call to actions, which is rather implicit using right rail promos or other promo components giving the user a choice every step of the way.

Creating a well-structured content tree defined by the business that reflects explicit (suggested) navigation paths does makes it easy to facilitate that type of navigation via presentation components but more importantly, it offers more meaningful deep links for SEO. But it certainly does not mean that you cannot have more than one way to reach a content item.

In case you are thinking of using aliases please read John West’s in his blog before you make that decision.

I think the best way forward is to have a good balance of explicit and implicit navigation paths. Let the business decide what they suggest should be the navigation path for content and structure the content accordingly but let the marketing folks come up with personalization and call to actions/promos by authoring content that creates implicit navigation paths for personas. Do let me know what you think and what has served you the best.

Enterprise Inheritance and Content Hierarchy

This post is my humble attempt to share what I have discovered from my experience to be a best practice in implementing IA (Information Architecture) and content hierarchy for an enterprise implementing manage sites within a single Sitecore instance.

As this is my first Sitecore blog, not to mention my first blog post ever, please feel free to comment and critique my approach as I attempt to contribute to the incredibly talented Sitecore developer community.
So let’s just jump into it, consider the following scenario: an enterprise has just acquired Sitecore as their CMS platform and wants to strategize on how they should implement IA and content hierarchy so that they maximize reuse and have a Sitecore instance that scales really well.

It is unsurprisingly common for businesses to decide to manage the entire company’s content within a single Sitecore instance and why not, since this is one of the easiest selling points for Sitecore, “Buy a single instance and you can build any many web sites as you want”. 

The problem however is, as everyone in the Sitecore community knows, Sitecore installs as a blank slate with a “Home” node indicating it as your Site’s landing page. So intuitively, some eager .Net architects-turned-Sitecore architects tend to design content hierarchy something similar to:

·       Site 1

o   Home

§  Contact Us

§  Products

§  Services

§  …

o   Shared Content

·       Site 2

o   Home

§  Contact Us

§  Products

§  Services

§  …

o   Shared Content

·       …

This then follows IA similar to

·       Templates

o   User Defined

§  Site 1 templates

§  Site 2 templates

·       Sublayouts

o   Site 1

§  Sublayout 1

§  …

·       Layouts

o   Site 1

§  Sublayout 1

§  …

As more experienced Sitecore architects/developers would immediately realize, there are several problems with this approach reusability, duplication of content, difficulty in content authoring, no scalability etc.

So what is the solution? Well it depends. But the general rule should be “Let content structure reflect the company structure”

What do I mean by that? Take a look at the following content tree structure

The typical structure here is that an enterprise generally consists of one or more operating companies and each operating company manages its own digital content. 

Hence you see the content tree is structured similarly with “Reusable Content” typically housing taxonomy and component items that do not have presentation but can be reused at every level of the enterprise all the way down to an individual site. This way you introduce reusability, avoid duplication of content and keep some level of consistency with content.

What about IA? Well take a look at this:

If you ask a developer, he/she would say that this is even more important that content hierarchy as this defines multiple inheritance which is a major feature of Sitecore. The idea here is simple

• Start with creating base templates at the Enterprise level
• Then create base templates for operating company that inherit from Enterprise Base Templates
• Then create Site Base templates that inherit from operating company’s base templates

This is where the power of Sitecore lies. A change to the Site’s base template affect’s only the single site’s items. To implement a change to every site in the operating company you simply need to make a change to the operating company’s base template and similarly for change to every site in every op-co simple change the base template of the enterprise.

A similar approach can be taken for Sublayouts and Renderings to group them by Enterprise, Op-Co and Site.

I think this is a great way to get organized quickly in Sitecore. I hope you use take this approach and make it your own or feel free to suggest a better approach. This may seems very obvious to most but you will be surprised at the number of Sitecore instances out there struggling with scalability and reuse.