Category: Sitecore Hacks

10 tips for optimizing the author experience and operational efficiency in Sitecore CMS

10 tips for optimizing the author experience and operational efficiency in Sitecore CMS

This year, along with Dominic Hurst of Valtech, I was very fortunate to have presented at the Sitecore Symposium in Las Vegas, Nevada. Both Dominic and I have worked on a variety of Sitecore installations and over the years have noted some mutual industry observations:

  • The role of the Content Author in modern CMS solutions has evolved into a multi-dimensional job. Too often these every-day heroes have to fight inflexible and uninspiring solutions to overcome the even smallest tasks
  • Many organizations spend the lion’s share of their budgets on CMS implementation, yet pay little attention to the efficiency of the operational processes that enable it
  • Poor authoring experiences can lead to UX erosion over time. Bad AX → Bad UX → Bad CX
  • Content authors are rarely empowered to aid in design, personalization, and performance analysis

Together at the Symposium we decided to address these observations and present our top 10 tips for organizations to empower their content authors to deliver real value on a daily basis. Many they can enact right away. Below are links to 10 blogs posts that cover each of these points in greater detail. We hope you enjoy these posts and, of course, please reach out to either of us to continue the conversation. Dan – @sitecorelations; Dominic – @dh_analytics)

  1. Provide access to non-explicit fields in Experience Editor
  2. Simplify rich text embeds
  3. Make it easy to do the “right” thing
  4. Optimize data template architecture for greater usability
  5. Dynamically nest local components with pages
  6. Use branch templates to create structured content models
  7. Get your content authors involved in the design process
  8. Be a custodian for chang(ing content)
  9. Embrace governance, add guard rails not gates
  10. Combine the authoring experience with analytics

Special thanks to Nicolai Winch Kristensen of Sitecore for coordinating and moderating our Sitecore Symposium presentation. May the force be with you!

Dynamically nesting local components with pages in Sitecore

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

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.

  1. 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.
  2. It’s not possible to edit them inline in Experience Editor.
  3. 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
  4. 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.

Embedded assets

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.


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.