“All it takes to turn a grouchy Experience Editor Friendly is a little TLC.” – Mr. Rogers

♬ It’s a beautiful day in the Experience Editor, A beautiful experience for an author, since we’re together, we might as well say, won’t you be my Content Author?

Hi, Sitecore Neighbor, I’m glad we’re together again… discussing new cool ways we can help provide the friendliest authoring experience an author can have while using Sitecore’s Experience Editor!

When I think “friendly”, I flash back to my childhood and remember the legend, Mr. Fred Rogers. As I grew up watching him, his demeanor was always calming influence. He cared about everyone and was always friendly to whomever popped up at his doorstep. Not only did he use his show as a platform to teach everyone, he also made one of the most impressive speeches in front of congress in 1969 – View Video.

Fred Rogers always treated everyone with respect, as friends and close neighbors. Our “neighbors” happen to be our clients and we should treat them with kindness, listen to their ideas and try to keep them happy. With that in mind, I strive to give my clients that same feeling I had watching Mr. Rogers; the feeling of a friendly, relaxing, stress free experience as they easily create and edit content in the EE.

Developers often forget or delay developing for the Experience Editor towards the end. Every aspect of a site’s implementation is extremely important, but forgetting or neglecting the EE is unacceptable.  It’s surprisingly easy and relatively quick to keep the EE user friendly throughout the project lifecycle. Keep these things in mind while developing for  the EE:

  • Develop a solid understanding of who our client’s content authors are and their skill levels.
  • View the EE from the author’s POV and spend extra time making the more complex areas as friendly as possible.
  • Do not ignore the client when they critique your hard work! We need to listen to their concerns throughout the project’s lifecycle and do our best to address their issues.
  • Make use of EE tools developed by the Sitecore Community, they are extremely helpful and can save you a lot of time.

In the end, we should be confident that we delivered the friendliest EE experience possible almost as awesome as those two certified developers pictured above.

Scenario: The EE is confusing the Client and they would like a little more clarity.

The client has been trained to use the EE, but they aren’t feeling the friendliness that they were hoping for. The client mocks up various screenshots and emails them to you in hopes you can fulfill their dreams of that awesome experience they know is possible.

The Client's Screenshot and comments.
Image 1

The Client is correct with their first comment in Image 1. The text: “NO TEXT IN FIELD” is vague at best and not entirely clear to what field that text belongs to. It’s obvious to us that all the client needs to do is click on that area to trigger the chrome that will display the field’s name and help text if any. The client is aware of that default functionality; however, they aren’t satisfied. Chances are they have some authors who aren’t as technically savvy as we are.

I’ve thought of a few solutions that could be used to solve this issue, I’ll just mention two:

  1. For each view, we can add additional markup around all the fields. Hardcoding the addition field help text, or add more fields to the templates. This could become a tedious task on a larger site even if we were to implement Experience Editor only views. I am also not a fan of just adding additional fields to the templates. It’s so easy to over load templates with fields and that will just end up confusing authors more. Also, adding the same makeup to dozens of views could become more tedious to maintain. This approach could also lead to possible inconsistencies if your attention is elsewhere.
  2. Create a custom RenderWebEditing(1) RenderAdditionalFieldInformation processor, patch it after the RenderWebEditing processor and use the rules engine by using a custom action to map one field to an additional field info value or we could use the xml and map dozens of these.

I am not a fan of #1, so I will be covering approach #2. Since my module: the Editor Enhancement Toolkit (Sitecore 8.2 version) has all the items necessary to utilize the rules engine I will be integrating it into that.

Creating a Custom RenderAdditionalFieldInformation Processor

The RenderAdditionalFieldInformation Processor is basic. I prepend the custom HTML markup to the args.Result.FirstPart.

The example above shows the creation of rules processor. We process the rules and check the Mapped Items collection for the first MapItem object that meets the criteria:

  • The MapItem’s type is Field
  • The MapItem’s Title equals the field’s name
  • The MapItem’s AdditionalFieldInformation contains a value.

If a MapItem object is found, we proceed to build out the markup and display the additional information. When the field is rendered, it should look like:

Fields with Additional Information

Step 2: Creating a Custom Rule Action Code and Sitecore Item

We need a new action to populate the Mapped Items if the conditions equate to true. The action is really basic.

In Sitecore, navigate to /sitecore/system/Settings/Rules/Definitions/Elements/EditorEnhancementToolkit/ and create a new Action named: Set Additional Field Information. The Text and Type fields should look like:

Step 3: Xml Mapping – Wiring up the Additional Field Information Mapping

I’m not going to walk through all the modifications needed to get this feature functional, but if you view the module’s source code, it’s self-explanatory and relatively easy to follow.

The Actual True Story

The PM on this project happened to hear about the Editor Enhancement Toolkit module and inquired about using it on a project that is in the final stages. The PM initially mentioned the client wasn’t happy with the “undescriptive” field names, a scenario my module was ready and able to handle without additional coding. It only needed configured. However, once the client sent over additional information, the client’s request was something my module wasn’t capable of handling without additional coding.

I spent some of my free time quickly coding a POC of my approach and proved it was a quick and easy feature to implement. The only task the client is responsible for is defining what items and fields should display the “Additional Field Information”. The amount of time this will consume heavily depends on how the client decides to target the items, such as by template, content path or other item information.

I felt it was important to solve this issue. It gave me something to blog about and it would be neat seeing my module helping a client in need. I see a positive outcome with a happy client, much like how a Mr. Roger’s episode always would end.

I made video with a more indepth code review + a quick demo!

Related Post:

A Better Solution: Injecting Resources into the Experience Editor

(1) – Silly me, I was going to completely replace the RenderWebEditing processor until I stumbled upon this post from Adam Weber. Thank you Adam for posting this literally 4 years ago today. It saved me from overriding an existing pipeline which is always a good thing.


Do you enjoy my blogs and wish you had access to even more of me and my ideas? Good news, you’re in luck!

If 140 characters is your thing, follow me on Twitter.

If you hate reading and watching Sitecore videos entertains you, head over to my YouTube channel! Sometimes I entertain, sometime I provide useful Sitecore information and sometimes I can do both in the same video.

I can also be found hanging out on the Sitecore channels on Slack. 

You can also find me adding content on LinkedIn and on Reddit.

I have also contributed on the Marketplace and GitHub.