I’m going to veer away from getting too deep into code for a bit to discuss a little bit of strategy. This is a two part post about a strategy to make life easy for content editors and in general, have them like you.
- 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.
Sitecore Page Editor has come a long way since its original inception, and it keeps getting more robust and easier to use. As Sitecore implementors, we provide a lot of training after a site launches, but depending on the complexity of the site, sometimes users still have questions about specific modules. And as with any user interface goes, the easier it is to use it, the more people will use it. As developers and designers, this is a very important part of making a successful product.
Helping the user by creating templates with standard values
It is generally a good practice to make modular renderings, meaning that each module should be self-standing, with its own datasource, so content can be changed easily. One of the things we know we can do to achieve this is by making granular sublayouts, and then be able to use the same sublayout for multiple renderings via the usage of the datasource property of renderings. This is great, but sometimes it could get a little complicated for users to add a module, then set the associated content, and then add additional items that all require associated content. This can get even more complicated if we are talking about a tabs module or a slideshow module.
Note: In this post I will interchange the use of the words module and sublayout – for all intents and purposes, I’m referring to a sublayout.
Enter Guided Help
One recent project we worked on had a lot of separate components/sublayouts, each one of which had very specific functionality. Rather than train and write documentation on each and every module which then the user would need to refer to, we decided to incorporate instructions for each module with the module itself, sort of like a wizard, explaining what to do to at each step to complete wiring up a module.
In order to do this, the first thing we have to do is figure out what the steps are. The steps where the instructions need to go to are:
1. When a sublayout/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 module specific content.
A Simple Example: A Basic Image Teaser Sublayout
Below is an example of how the instructions show up step-by-step. This module is a simple teaser module, which allows the user to place a teaser image on the page.
Once the item is created, all the modules on the item (that were there via the standard values) are shown with no datasource, which is when the first set of instructions show:
It states exactly what the user has to do to wire up the module with the datasource.
The user has a choice to enter new content, or choose an existing content – in the case of the teaser module, the job is almost complete – an existing item will render the image right away:
… while creating a new item will allow the user to choose an image.
A More Complicated Example: A Download Grid Sublayout
The teaser module was a simple one, so lets look at one that is slightly more complicated, that requires the user to enter a number of different items. We have a download grid module, which basically takes an download grid item, and shows all the items below it (that are download items) and shows it in a grid. This module requires the user to set associated content to a item which is the main download grid item, and then its children will be the items for that grid. We can have multiple download grids per page, which is why it is setup this way.
As best practices would dictate, we decided to include it in Standard values. So the very first thing you see on the page is the instructions for when there is no associated content.
It instructs the user exactly how to create the associated content, which is the same screen they would get when they place a new module on the page. It also shows what you have to click to get the toolbar to set the associated content:
Once the associated content has been created, it then needs all the items to create the grid. The module detects that even though there is associated content, there is still no items as children that can be shown (or to create the grid). It now shows:
This shows how to create content for children of the download grid:
Once a few download items have been added, the module now detects that there are some items for the grid, so it now shows how to edit the items that are shown.
This is just an example of one of many approaches to make it easier for content editors to do their work. In Part 2, we will dig into the code that allows us to do this, and how the templates and items are all set up for this to work.
Let me know what you think of this strategy, and/or if you have accomplished something similar in different ways!
One thought on “Sitecore Page Editor: An Approach for Easier User Adoption – Part 1”