Using Sitecore branch templates to create structured content models

Three of the guiding principles I always keep in mind when trying to build usable systems in Sitecore are:

Reduce the number of decisions a content author has to make
Reduce the number of things that require editing in the first place
Make it easy to do the “right” thing

One of the greatest tools for ensuring that these three things are achieved are Sitecore branch templates. Branch templates allow creation of item hierarchies in a singled click using dynamic placeholders. You can instantly create complex but predictable multi-tiered structures so that an author need not recreate these manually.

A content author creating yet another news article need not see a blank slate each time when it’s likely that this content type is highly structured and will have instances of the same components in the same layout, at least as a starting point. Below are some examples of branch templates for pages that specifies a core collection of default components to be included with each new instance of the page.

This is even more useful for creating multi-tiered structures such as office microsites or any other repeated content grouping that all have the same basic hierarchy. Why have content authors doing data entry for content objects that are predictable and repeatable? This is time-consuming, prone to error, and discourages consistency. Companies tend to treat content authors time as expendable, but it’s really not when you consider the cumulative total of all of these tasks and micro-interactions with the CMS.

Leveraging branch templates requires a holistic approach to content modeling that is best done when a platform is being constructed as it requires some forethought and consensus on standardization. That said, it’s not impossible to inspect existing structures and create supporting branch templates for use moving forward. Finding ways to accelerate repetitive tasks may just improve content author morale as much as their efficiency and free them up to do higher value work!

Dynamically nesting local components with pages in Sitecore

The challenge

Information architecture and system design decisions can have a major impact on the ease with which content can be created and managed in Sitecore. Authoring experience is not always front-of-mind as architects and developers are shaping a system, but this can prove short-sighted as content teams begin to build content in the system.

During recent authoring experience audits of clients’ Sitecore platforms, I have noticed one key thing negatively impacting author efficiency. Many times, local components are not grouped with their parent page. While this is common and expected for globally shared components, it’s not recommended for unique instances of components referenced only by a single page. In one such case, there was a total separation of pages and components. There was an entirely separate directory for components that mirrored the page hierarchy manually. The rationale was that it kept page objects in the tree simple and uncluttered (which was true) but the end result was that authors were pre-creating all necessary components for a page ahead of time rather that authoring a page inline in Experience Editor. Rather than simply choosing from a list of allowable components and dropping an instance on a page, the first thing the content authors were required to do was establish a link to an existing data source. This really threw a wrench in the inline editing experience and was affecting content authors impressions of Sitecore – thinking “that’s just how it works.”

The solution

To allow for greater automation and improve author efficiency, dynamically nest components locally under each page object so that pages can be more quickly constructed and fully edited inline.

Through use of branch templates and standard values, a local Components folder can house all unique instances of components applied to a page. The content author doesn’t have to spend a lot of time thinking about where they should go. It reduces the number of decisions they have to make and speeds the authoring process. If you want to get fancy, you can even include sub-folders to keep multiple instances of different kinds of components organized (e.g. multiple rich text blocks, images, or videos).

This approach also simplifies the publishing process when you want to publish all components along with a page. Since these are sub-items, this relationship is easier to deal with rather than referencing components as related items.

This is something I have had a lot of success with and as the trend towards greater componentization in WCM systems continues it’s becoming a standard approach in the platforms Velir builds.

Simplify your rich text embeds in Sitecore

The challenge

One of the most common challenges of crafting quality solutions in Sitecore centers around the handling of media elements and other complex structures embedded in rich text. Many of my clients write a lot of highly curated, long form articles and reports with embedded pull quotes, images, galleries, videos, audio clips, data visualizations, and more. In most cases, they rely too heavily on rich text snippets to achieve the desired layouts and presentation which has some inherent drawbacks.

A rich text snippet is a really just structured blob of HTML jammed into the rich text editor as opposed to being a discreet component that exists as part of the platform. They are really brittle. If a content author is trying modify one and accidentally chops out a class it’s difficult to fix it without starting over. It can be time-consuming.
It’s not possible to edit them inline in Experience Editor.
If content authors want to change all instances of this snippet in some way they would have to update it in X number of places
The snippet contains styling markup so if and when content needs to be migrated the styles may not play nicely with the CSS of the destination site and may need to be manually retooled page-by-page.

The solution

There is better way. Working with media in rich text can be less clunky and time-consuming through use of dynamic placeholder-driven embeds. It is possible to use discreet, page-editable rich text embeds for all common components that can be included independently anywhere in the text block.

If your solution has commonly used media components such as Image or Video, there is no need to create a rich text snippet that mimics this functionality. Alternatively, allow these components to be embedded within the rich text block. Instead of placing a token with the GUID of the component, Velir has been working on a method that allows the content author to drop a dynamic placeholder into which you can add components as you would any other placeholder. Below is an example of the a customized RTE ribbon that includes 3 new options – Embed Container Float Left, Embed Container Full Width, and Embed Container Float Right.

The content author places the cursor between two paragraphs of text and then chooses an option in the ribbon. They can choose to float the asset left or right or allow it to span the width of the content well. A dynamic placeholder for embeds is dropped into the text block and components can be added as defined by the container. This means media embeds are discreet entities and can be added and fully managed from Experience Editor.

Once saved, the embedded components will be visible in Experience Editor and Preview. Below is an example of an embedded image component floated left and a video component floated right. Front end styling will determine the allowable width of floated embeds and whether they “bust” out of margins as they do in this example.

Below is an example of an embedded pull quote component floated right and an image component at full width. Text like captions can be fully edited inline.

Disclaimer: We are still tooling with this method and need to work out some kinks around reordering embedded assets once set… but so far so good. If, like us, you’d like to find a cleaner, more structured way to manage rich text embeds then I recommend giving this a try.

Optimize Sitecore data template architecture for greater usability

In my time as a Solutions Architect / Systems Analyst / BSA, I have often been the one charged with creating an exacting map of all the data templates necessary to provide data sources for components, pages, and any other data container to be created in Sitecore for a new or redesigned platform. This can be a daunting task for a complex system but one I am always happy take on for one simple reason. In my experience, this is where most implementations go wrong in regards to authoring experience.

When I see a new client’s existing Sitecore platform for the first time, I am often struck by how little consistency there is across data templates within the same system and how few guardrails there are. Despite best intentions this is usually the result of different development teams over time or multiple teams working in silos, accelerated project timelines leading to cut corners, or lack of product oversight or focus on the general usability of the system. The end result tends to be content author confusion and potential dissatisfaction with the system when, in fact, the problem has more to do with information architecture and implementation.

Here are a few tips on optimizing Sitecore data template architecture for usability:

1. Have a plan

For a Sitecore build of any complexity, I always create a Content Object Definition document (which is just a fancy Excel matrix hosted in the cloud) that serves as a global mapping for all data fields. It additionally defines template inheritance, section/field naming conventions, standard values, validation, and help text. It can contain taxonomy and enumeration items or anything that will be required by data templates. This document is referenced in every ticket that prescribes the building of a component or page in Sitecore so there is no ambiguity for the development team. As it starts to come together, it serves as useful charter between prescriber and implementer. And most importantly, it forces us to think globally about the information architecture and ways to achieve consistency and simplicity in template design.

2. Use consistent field/section naming conventions

Use simple, consistent naming conventions and ordering for sections that are clear across pages and components rather than general buckets for “content” or “data”. It’s common for, say, article-type pages to have a date fields, image fields, titles, text, taxonomy, navigation options, etc, so why not enforce this pattern system-wide for pages, when applicable. The pattern should be familiar as the author moves on to content they may be less acquainted with. They should be able to able to quickly get their bearings.

Likewise, use simple, consistent naming conventions and ordering for fields. Use simple names like Title, Subtitle, Text, Image, Video, and Link wherever needed and stick to a prescribed, global ordering for these fields giving thought to which groups of fields require editing most often.

Lastly, consolidate any uncommon, display-related fields into their own batch of separate rendering parameters to keep the number of common fields less cluttered or house these fields in their own Display Options section at the end.

3. Avoid inheritance of inert fields

All too often, pages and components inherit a sledgehammer of a base template that comes with fields that may or may not be required by that object in presentation. Through more granular base template inheritance you can inherit only fields that are relevant for the context and ensure that content authors aren’t left wondering what a field does when, in fact, it does nothing. This takes some forethought and the Content Object Definition exercise mentioned above can help shake out what should be inherited broadly or a la carte.

4. Ensure content authors can easily understand the meaning of data fields

Don’t forget the help text! Ensure that every non-obvious field has description to help guide content authors who may not be power users. See my recent blog post that covers adding help text in more detail.