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.
sitecorrelations 