Tag: Author Experience

Optimize Sitecore data template architecture for greater usability

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.



Ensure content authors can easily understand the meaning of Sitecore data fields

Ensure content authors can easily understand the meaning of Sitecore data fields

I’m often surprised to discover that many of my Sitecore clients don’t take advantage of some the out-of-the-box guard rails that come with the platform, most notably help text. While the meaning of some fields may be self-explanatory, there are always many more that are non-obvious. This can lead to longer ramp-up time for new content authors, content-based errors, duplicate fields, and general frustration and displeasure with the system.

There are many reasons for this trend. Despite the best intentions of Sitecore platform implementers, some common causes are:

  • Time – Quality content object definition and data modeling is complex and time-consuming enough for a robust solution with worrying too much about guides and tutorials. This step often gets left for last which is to say it rarely gets done at all.
  • Evolution – Systems evolve over time with new fields frequently added to the mix, often without things help text, validation, and standard values leading to a bit of hodge-podge experience.
  • Lack of content author involvement – Content authors are in the best position to define the meaning of the fields they are meant to edit, yet they aren’t always invited into the field definition process as the system is taking shape.
  • Inheritance – While it’s tempting to use very granular base template inheritance to drive very common fields like Title, Image, Text, etc, across pages and components this often is an impediment to using help text when the context differs from use case to use case (e.g. when a 1×1 image vs 16×9 image is required in an Image field). What we gain in data template efficiency we give up in context and guidance.

Making sure that fields are well defined requires vigilance in the content object definition process while building an entire platform or just adding a new component. Here are some tips:

  1. If building or redesigning a system, do some game-planning in form of a content object definition data sheet that includes a column for Help Text that will serve as a reminder pre-implementation to define this, and by all means, get your authoring teams involved so it makes sense to the people who need to understand it.
  2. Use discreet fields on components rather than inherited ones whenever unique help text is going to be required. Consider an Author Experience checklist with reminders to include help text, validation, and standard values.
  3. Finally, consider bypassing the use of Short Description for help text since this is, by default, displayed right after the field name in Content Editor which I find affects readability. Instead it is possible to apply some custom code on top of Content Editor that reveals Long Description via a simple tool tip icon, as shown below. The code loops through looking for the Long Description title attribute and in CSS adds a tool tip icon if Long Description is not null. Without this enhancement, the content author would have to know to hover over the title text to see the help text, which is not very intuitive.


By taking the time to ensure that content authors can easily understand the meaning of Sitecore data fields we are facilitating adoption and satisfaction among the folks who use the system the most!

Providing access to non-explicit fields in Sitecore’s Experience Editor

Providing access to non-explicit fields in Sitecore’s Experience Editor

One of the most common issues I’ve come across during author experience audits for Sitecore clients is that they do a lot of context switching between Content Editor (where you edit all form fields on a data template) and Experience Editor (where you can author and design content inline). There is a tremendous amount of time wasted in moving back and forth between modes to complete an author’s objective.

There are a couple of reasons for this. In many cases, editing inline is a fairly new concept and authoring teams are not investing as much in the setup and implementation of clean architecture in Experience Editor as they are in Content Editor. But even when they have, there are still some impediments to being able to fully complete their tasks in a single mode. Some values that require management are just not explicit on the page. While some images and text may be edited directly inline, there will always be things that aren’t. These include…

  • Alternate fields beyond the one displayed (e.g. Short Title for navigation purposes)
  • Meta details like description
  • Navigation options (e.g. Suppress in Navigation)
  • Taxonomy values (e.g. Topics, Locations, People)

Left as is authors have no choice but to bounce between the two modes. So what can we do about it?

  1. Install a custom “chunk” in the ribbon of Experience Editor that allows access to non-explicit, page-level values without having to return to Content Editor (e.g Page Options, Navigation Options, Taxonomy).2017-10-13_12-30-02
  2. Each button represents a custom collection of fields that will launch in a modal, allowing you to focus on just the relevant fields for that grouping and make the necessary changes.2017-10-13_12-32-41
  3. Likewise, every component should be configured to consistently allow access to non-explicit field values and rendering parameters that affect display.

Doing this requires a bit of upfront planning as you are defining the data structure of your pages and components to consider what field values might be inaccessible from the inline editing experience, but it will surely save time and improve the inline editing experience.


How to allow access to Dictionary in Sitecore Content Editor tray

How to allow access to Dictionary in Sitecore Content Editor tray

Two key principles of ensuring a strong authoring experience in a CMS is (1) reducing the amount of time it takes to find something and (2) allowing authors to focus on content rather than being distracted by the CMS.

Many of clients make extensive use of a Dictionary of editable values for chrome content such as field titles, button text, and other elements that don’t require frequent edits but should not necessarily be hardcoded.  However, in a Sitecore workflow-enabled environment, non-admins will often not have access the System folder where Dictionary natively resides. While it may be updated less frequently, Dictionary content is content just the same. It should not require drilling through a tree structure to find it. It is possible to expose the “Dictionary” in the Content Editor tray alongside “Media Library” and “Workbox” so that authors may easily access and update Dictionary item values as necessary.


Sitecore Content Editing Hacks - Dictionary 1


Sitecore Content Editing Hacks - Dictionary 2

Steps for Adding the Dictionary to the Content Editor Tray:

  1. Login as an Admin and access the Sitecore Desktop.
  2. Click on the Database icon at the bottom right and select ‘Core’ database.Sitecore Content Editing Hacks - Dictionary 3
  3. Return to the Content Editor and navigate to sitecore\content\Applications\Content Editor\Applications. These are the default items that you would normally see here – Content Editor, Media Library, and Workbox.
  4. Add an item to represent your new “tab” in the tray.
  5. Name it “Dictionary” and set the following values:
    1. Header = Dictionary
    2. Source = /sitecore/shell/Applications/Content Manager/Default.aspx?mo=media&ro=/sitecore/system/Dictionary&he=Dictionary&ic=People/16×16/book_red.png

Sitecore Content Editing Hacks - Dictionary 4

Tip: Don’t forget to add (or ask your developer to add) these configuration changes to the core project for propagation to each environment.