Our Head Of Product Strategy and Episerver Most Valued Professional Janaka Fernando, and our Content Specialist Jane Gillow, share perspectives on the importance of building a strong content editing experience to support the needs of today's content editors. Plus Janaka provides 5 tips for building a compelling content editing experience in Episerver.
As Head Of Product Strategy at Made to Engage, I've successfully executed many implementations of the Episerver CMS for our clients over the years. I know that it's critical to build a strong interface that today's content editors can enjoy using. That's right, content editors - the people who use the CMS every day to curate and edit relevant content for brands. The first step is to understand content editors' unique needs and expectations.
"Content editors face tremendous pressure to quickly identify, craft and publish compelling articles," says our Content Specialist Jane Gillow. "Strong content management tools can be critical to the success of an organisation's content and their ROI. Many content editors are in need of a simple and intuitive design solution that will accommodate various types of articles and visuals as well as a flexible layout to fit their content strategies."
To address these needs, the Made to Engage team focus on delivering streamlined Episerver solutions that put the joy of curating content at the centre of the experience. That's one of the reasons why we include a module on designing for the content editor when we're training our back end and front end Epi developers. Here's a checklist I made to ensure our developers are building products that content editors can enjoy using.
While ArticlePage might be a bit lazy, StandardLeftContentPage is unlikely to mean much to the average content editor. Fortunately, Episerver allows you to select a new Display Name as well as a Description for each content type to make this more user-friendly. These names can even be localised if you have editors with multiple languages using the CMS. And the same rules apply for Blocks too.
Janaka's tip for developers: Avoid generic placeholder names and descriptions like 'content'. The description should always be in line with the intended usage of the page.
This page is for press releases and corporate information.
And while we're looking at the example above, did you notice the use of Alloy icons?
Is it just me or do these seem to be the icons we see on almost every project? They only make sense on Alloy because that is the brand of the company. At the very least developers should come up with a thumbnail icon that represents the brand of the customer site they are working on.
The icons are meant to indicate the usage of the Page or Block, so more brand-specific icons would be extremely helpful to a content editor who wishes to spot the right content type quickly.
Janaka's tip for developers: Never release a content type without a thumbnail icon. You could spend weeks delivering the functionality for a specific content type and yet it will look unprofessional and rushed if you skip this detail.
Sometimes there are settings for a Page or a Block that require you to go into the All Properties view to properly edit, such as the number of items to display on a page listing block. However, you should try to make the On-Page Edit view the easiest way for editors to make changes to the majority of properties because this is the most natural way of understanding what those changes will look like.
Janaka's tip for developers: As a rule of thumb anything in the Content tab should be available in the On-Page Edit view. If it doesn't fit in there, it may go in Settings or a custom tab.
Here's one that frustrates content editors no end. They want to do something simple but in order to do so they have to click through several layers of Blocks. Adding one layer is generally okay, for example a Block that contains a set of items that might be Blocks themselves. The problem is when those Blocks contain other Blocks the poor content editor has to take four or more steps just to edit the content.
Janaka's tip for developers: Avoiding nesting will lead to improved performance for your site.
Error messages provide a better experience for editors, guiding them on how to correct invalid input. However, these don't provide much help if they just show the default message.
Janaka's tip for developers: Try to help the content editor along with examples of the correct input or a clearer error message such as the one below.
Once again, use localisation here if you need to accommodate editors in multiple languages.
At Made to Engage we take these measures to build experiences in Episerver that content editors love. I hope this makes you consider the experience of the content editors who will be using the site you are building and incorporate their needs and expectations from the very start. If you aren't thinking about the content editor when building your product in Episerver, you're missing an opportunity to facilitate the content editing experience and generate better customer engagement for clients.