Improving EPiServer usability for web editors and administrators

In EPiServer CMS, the are tons of tools available, but sometimes they can prevent the editor/administrator from working efficiently. As developers, we can improve usability by setting up the right tools from the start.

Many of these points are pretty basic but useful, so hopefully they are already part of many development checklists out there, like here at Epinova. Most of these tips are valid for both CMS 6 and 7 unless otherwise noted.

Configuring the TinyMCE editor

In EPiServer CMS 6 and 7, the TinyMce editor is reasonably well set up by default. You can insert images, links, tables and dynamic content, and only have access to basic formatting like bold/italic/underline and alignment and heading styles. Still, take a minute to consider the following.

XHTML or plain string?

TinyMceEditor is by default only available for the XHTML property type. Make a conscious choice of whether your property needs rich formatting or could just be a plain string.

If the site has a strict design or formatting policy and you don't want the web editor to get too creative, it may be necessary to remove or add specific formatting options (removing bold/italic/HTML view, or adding new predefined styles).

Keep all the buttons?

To remove TinyMceEditor buttons, go to
Admin mode > Config tab > Plug-in manager > EPiServer > Overview tab  and un-check the relevant options. Note: this will take effect for all XHTML properties globally.

• To programmatically set default TinyMce options, see this blog post by Johan Kronberg.
• To add new styles in the editor mark your styles with the EditMenuName attribute, see this blog post by Linus Ekström.

               

Limiting the number of old page versions

EPiServer stores each version of a page in the database, which means after a while, useless old page versions take up lots of storage space and drain the site performance when editing.

By default, EPiServer allows unlimited page versions, but by going to Admin mode > Config tab > System Settings you can set a more sensible number of versions (20 should be sufficient in most cases ).

Restricting available page types

When all page types and the basic information structure have been defined, you should restrict which page types are allowed where. Not having to browse a long list of unrelated page types will help the editor’s efficiency and prevent her from creating instances of page types where they don’t belong.

In Page Type Builder you can add the AvailablePageTypes attribute to your PageType declaration: 

[PageType(AvailablePageTypes =
new[] { typeof (StandardPage), typeof (SomeOtherPage)}]
public class TestPage : PageData 

and similar with the native page types in EPiServer 7:
(the AvailablePageTypeAttributes class has a bunch of other ways to exlude and include page types):

[AvailablePageTypes(Include = 
new Type[] {typeof(StandardPage), typeof(SomeOtherPage)})]
public class TestPage : PageData

Note: Although page types restrictions can be altered manually under Admin Mode > Page Types > Available Page Types, it is not recommended as you probably know.

In EPiServer projects using Page Type Builder, manual changes made by the administrator in Admin mode will be lost every time the site is restarted (for example an Application Pool recycle or a deployment). Be sure to inform your editors/administrators about this or they will be confused/annoyed. Implement any changes they need in your code instead. 

In EPiServer 7 projects using the native pagetype system (not PTB), manual changes will NOT be lost when the site restarts. But the site owners would still be better off communicating their change requests to the developers so they can change the code instead, or there will always be a diff between production setup and code.

Removing unused page types and properties

Clean up the editor’s workspace by deleting any unused page types and properties. This exercise may be especially useful if you have migrated or inherited an old project.

If you are unsure if a page type is used or not, use one of these handy tricks (which I’m sure most devs are familiar with):

Finding instances of an obsolete page type

First create a new page of the page type in question, then go to Admin mode > Page Types tab and delete the page type. You’ll get an error saying that there are instances of that page type, with a list of links to those pages. Convert those pages to another page type or delete them, then finally delete the obsolete page type. (Note: Make sure you empty the Recycle Bin before deleting the page type.)

Getting an overview of page type usage

For a quick overview of page type usage, run this little SQL script by Fredrik Haglund (written for CMS 5 but works in newer versions too).

If administrators need a similar feature available within EPiServer Admin mode, consider installing PageTypeUtil by BVNetworks. 

Sorting properties in a logical order

Take some time to organize properties for each page type in a logical and natural order. For example headings should come before intro and body properties. 

Assign properties logically to related tabs (create new tabs if necessary).  Consider hiding/removing some of the existing tabs if they are not in use:

• Manually: When editing a page type in Admin mode, drag-n-drop properties to set sort order. For more precise control, edit the Sort Index attribute for each property on a page type.
• PageTypeBuilder: Specify the SortOrder attribute in your PageType declaration. Note that sort orders defined in PTB will always overwrite manually set sort orders.
• Hiding built-in tabs, e.g. the Categories tab, requires some plugin trickery .

Translating properties and descriptions

Another obvious one, but make sure all properties are given sensible names translated into all active languages. Don’t make your editor work with properties named BigFocusBoxLeftHeading and ShowFirstNewsItemDate. Don’t forget to add descriptive, translated, help texts for each property and page type.

Setting default values for properties

Consider setting sensible default values for properties that are used often. E.g. the number of items in a list, default url string of an image, default state of a checkbox, etc. This will save the editor some tedious repeat work.

Default  values can by set manually per property per page type, or by specifying the DefaultValue and DefaultValueType attributes in your PageType declaration if using PageTypeBuilder.

Setting default VPP folder

By default, Page Files is the first VPP folder in the list. When opening the file archive while editing a page, you’ll often see the message “A folder for this page has not been created, do you wish to create one now?”

To avoid having the editor see this all the time, change the order of your VPP folders in episerver.config (inside <virtualpath><providers>) so that Page Files is not first in the list.

Setting SizePresets for image editing

If the web editor regularly resizes image to a certain size to fit in the site design, set appropriate size presets for the built-in image editor in episerver.config:

Restricting available languages

Your website may not need all the languages that are active/available by default after a plain EPiServer installation. Make sure you activate the correct language before creating any content (this determines the master language), and deactivate all unneeded languages. After initial setup, administrators should leave these settings alone.

 

Removing unwanted users and groups

During development, you may have created users and groups for testing purposes. If you have been using Windows authentication, you will probably also have some of your domain's Windows groups in there. They must be removed before the site goes live.

Users and groups created using Forms authentication (SqlMembershipProvider or MultiplexingMembershipProvider) can be removed directly from Admin mode.

Users and groups auto-created using Windows authentication (WindowsMembershipProvider or MultiplexingMembershipProvider) must be removed from the database manually using a few SQL statements. 

• Windows users will be found in tblWindowsUser.
• Windows groups will be found in tblWindowsGroup.
• For Windows user assigned to a Windows group, the relation will be found in tblWindowsRelations. You'll have to delete the relation before you'll be allowed to delete the users/groups. 
• If a Windows user has been assigned to a non-Windows group (e.g. Administrators, WebAdmins), the relation will be found in tblAccess. The relation must be deleted before you can delete the users.