A Richer Experience Editor Editing Experience: Part 1

Using Sitecore XP CMS features to it’s Fullest Capability

One of the best features of Sitecore XP is the Experience Editor (formerly known as Page Editor). In order to utilize this feature fully and make it as user-friendly as it can be, I had written about an approach that makes the life of a content editor easy, by providing on screen guidance for editing content and editing components. You can read about it in the two part post here:

• Part 1 – Easier Page Editor Adoption for Content Editors – How it works for the Content Editors
• Part 2 – Easier Page Editor Adoption for Content Editors – The Code Guts

It was written with webforms in mind. We have since updated it to use on MVC projects, but on a new MVC project, we decided to try a different approach behind the scenes – one that involves more centralization, and more flexibility.

The results are the same as the old approach – the output of what this achieves is outlined in Part 1 of the Post: Easier Page Editor Adoption for Content Editors – How it works for the Content Editors. It would be a nice refresher to see what this achieves and then come back here to understand what we need to do for it to work in MVC.

Just like the other approach, I’ve decided to break this down into two parts (and because one post became too big):

• Part 1 – A Richer Experience Editor Editing Experience – Reiterate the basic idea, and go over all the elements necessary to make this work.
• Part 2 – A Richer Experience Editor Editing Experience – In this post we see how all the elements connect and work together.

The Basic Idea

In Sitecore MVC (as in webforms), the basic idea is very simple – whenever we add a new rendering/module to a placeholder – or when a rendering/module has been placed via standard values – we want to show some help instructions so that the content editor knows what to do next. In webforms, we were able to utilize user controls. Inside a MVC view, we are not really aware of the page state, so we have to centralize it somehow. When a View Rendering loads, with the Model being passed in, we must display the right instructions (or not – because we are not in page editing mode).

We’ve decided to add a some more flexibility to this concept – one of being that for Page Editor, sometimes it makes sense to have a completely different view of a page, than what the final display looks like. This is not a new concept (as Nick Wesselman wrote about it way back), and it makes content editing renderings/modules such as Image Carousels, and Video Slideshows much easier, by breaking them down and displaying all the different elements of the modules (which are usually hidden).

So, architecturally, the solution should provide:

1. The ability to have editing help instructions per View (rendering/module)
2. The ability to have a different display HTML vs editing HTML
3. The ability to define the business logic for how each module shows its’ help instructions
4. The ability to use a generic version of both #1, #2 and #3, and not have to make an individual view for every step.

The Setup

To follow the approach here, we need the following:

1. The view for Sitecore rendering (duh)
2. A view for displaying the content in preview or live mode
3. A view for laying out the content in a different format for ease in editing
4. A view to layout the instructions corresponding to that rendering/module
5. Templates to hold the help instructions data
6. Items based on template in #5 for each rendering/module.

Note: as mentioned in what the approach should provide, #3 and #4 are optional, and there should be a generic view for both, that outputs the help instructions and editing view in a generic format. This approach shouldn’t add more work than necessary.

The Views

When we create views in our VS solution, the folder structure tends to get created based on controllers, or for simple view renderings, we can create our own folder structure:

To create the renderings, we point them to .cshtml file – standard operating procedure.

We then would need to create different views, for editing, and displaying – we decided to just suffix them using “Display.cshtml” and “Edit.cshtml”:

The views name “…Display.cshtml” would show in preview mode, and “…Edit.cshtml” would show in Page Edit Mode.

Page Edit Help Controller

We need to have a PageEditHelp controller, which has the business logic to show the instructions:

… and the corresponding views folder, to have a corresponding help view for each rendering/module.

An Example

A simple example: to create a View Rendering for a Title Panel (an image with some text and headline that hovers when you mouseover it), these are all the views you will need, depending on how granular you want to control the display:

Tradtional Sitecore Development: HoverTitlePanel.cshtml – you are essentially done, as long as you used Field Renderers, you should be good.

To create a guided help View Rendering, you will need:

• HoverTitlePanel.cshtml – the standard view
• HoverTitlePanelDisplay.cshtml – the display/preview view
• HoverTitlePanelEdit.cshtml – this view will display when Sitecore is in Page Editing mode
• HoverTitlePanel.cshtml – in the PageEditHelp Views folder – this is needed only if the help instructions are complicated enough that a completely different HTML structure is necessary
• HoverTitlePanel-NoDataSource.cshtml, HoverTitlePanel-RegularEdit.cshtml and HoverTitlePanel-NoData.cshtml – these views are necessary only if the help instructions for each step of the module content creation is drastically different. This is a very rare scenario.

So, to summarize, you can customize the help instruction at a very granular level – or not – to just display simple help instruction on top of the page, all you need is the HoverTitlePanel.cshtml and HoverTitlePanelDisplay.cshtml – of this, you only really need to worry about HoverTitlePanelDisplay.cshtml to render your model data. (HoverTitlePanel.cshtml will call a simple method, and nothing else – which we will show in Part 2 of this post)

The Assets

We still need the same assets that we had in the earlier approach:

• Templates to hold the instructions data
• A mechanism to decide whether to show the help or the regular display view

The Templates and Items Setup

There are three main steps where we need to show instructions. They are:

1. When a rendering/module is placed on a page without a datasource via standard values.
2. Once the item is created, instruct how to add associated content (i.e. setting the datasource)
3. Once the associated content is set, how to enter rendering/module specific content.

The templates don’t really change from before:

Notice the the three different fields correspond to the three steps where we need to show the content:

• Field No DataSource Help is for step #1
• Field No Data Help is for step #2
• Field Page Editor Instructions is for step #3

We would need to create a Help item for each rendering/module, to hold the help instruction – in multiple languages, if so desired.

We then need to create a base class for the Views, and the PageEditHelp controller. Once those are created, the only thing needed from a perspective for rendering development are the different views. As mentioned, they could be two views, or more, depending on how granular you want to get.

The second part of this post explains how to connect all these views and make it work with the PageEditHelp Controller.

Advertisement