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.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s