Set up a user friendly Edit Mode before the training

EPiServer is, as you probably already know a very flexible system. There is plenty to do to adapt the tool for both visitors and editors. I am so often surprised with that so few do anything about the editor interface.

This blog post is translated with Google Translate. Read the post in Swedish here

I think one reason is that it is so easy to change so that nobody does. The developers do not see it as a problem that there are fields with strange names or tabs that can not benefit from. It does not matter that there are many folders in File Manager, for they are, after all, not be used. But from my perspective, one can not be more wrong. It is exactly this that matters.

A person who has never seen EPiServer has no idea that these things are easy to change and think it must be so. The field where an editor to write his text named Main Body does not think it is logical for that to which to write their body. This creates two problems, and the risk is that the person think that the system is not user friendly and boring. The second problem is that it makes it unnecessarily difficult for a person to learn the system.

My advice to you is that already in the requirement specifications of the website to ensure that all names and field right from the start. There is no reason to delay it. I get so often hear, that we take it later. The problem is that "later" rarely comes. It is simply not done. Even if you do not do it right so it MUST be done before the training of editors. It is often when the editors meet the system the first time and you know how they say, FIRST IMPRESSION LAST.

To simplify for you as a specifier / clients I have made a list of things that need to be examined in EPiServer before training so that editor mode is as easy as possible to learn and understand. If you do not know how things should be done, bring the list to your provider and go through it together. Most of the points concerning EPiServer 6 and earlier, but it's good to go through the list even for EPiServer 7.

Name and help texts on field

All fields in templates may have their own names and help texts. These are often quite technical names and help texts are often lacking. There should be good clear name that makes it easy to understand what each field should contain. This can be done in XML files, so that it is possible to have the editor interface in multiple languages, if desired. Making decisions about which language you should have prior training. Change preferably not on the default name from EPiServer, then this will affect the user documentation to come.

Order in the field

Put the fields in a logical order, so that it becomes easy to fill a page with content. Determine if certain fields should be mandatory or not. Also make sure that it is logical to understand why some fields located on a particular tab. Generally speaking, it may be appropriate to place fields such as page is built, top down simply.

Flaps position, name and any permissions

Determine the order in which tabs to show and which names they should have. Put any rights if not all to see all the tabs.

Settings in the editor field

As the new editor, it is perfectly possible to have different settings on different editor field in the same template. The preamble field would not normally allow the same opportunities as a body field. It would certainly not have as great a field. All this can be customized. Making decisions about size, buttons and design in each field. See attached example from another customer. Please read an old blog post about it here.

Permission to templates / templates available and name

When creating a new page, often appear all templates in a list. Which to be displayed can be controlled in various ways and by those that will be available for a certain template, but also by permission. It needs to be fixed so that editors do not think they can create all kinds of pages. Also give all templates logical names and help texts. Sort them in a logical order in the places where they are more in the same list.

Structure and permissions in the file manager

About EPiServer file manager is used, there should be a finished structure with permissions on the folders. There must be a logical way to find files and know where to invest. Failure to do this from the beginning, the file manager will be like a haystack that it is impossible to find anything in. It is important to determine the starting points to use, and structure them so that the correct starting point is displayed first.

Folder structure for block

If you use EPiServer 7, we also need a folder structure of and access rights to the block. 

Folders in the form handler

It is quite common that there are lots of forms and hence a need to put them in different folders that you should find. Create these folders before training, we learn editors to find right from the start.

Permissions in tree structure

The various permissions that different groups will have, should be established before the training. It will be silly if a person has the right to do things during the course, but do not have it then. The danger is that it leads to becoming confused by too many things during the course and then when you come back you become frustrated because you can not do things that made during the course. You often think you make a mistake, though, this is actually the system that has limitations.

Clear up the tree structure

The tree should be as clean as possible, with as much "real" data as possible. Remove whatever tests and other devices and control up to any systemic side is a little hidden for editors. The tree should as far as possible reflect the structure you see on the website, it is most logical for the editor.

Multi language / Globalization

In many solutions the language support enabled, though it is not supposed to work in multiple languages. Should the site be only in one language, this function should be disabled.

Workflows

Should workflows used? If not then hide this tab.