I have spent the last year and a half observing content management system users struggling with a not exactly cutting edge system. I found out their errors would always happen for the same 4 reasons. Though it may seem cruel to observe people as if they were just lab animals, so I also want to add I offered them the best support ever during that time. One last thing: no user has been injured during this experiment.
Typing path
Whenever contributors have to type in image or page URL to insert them in their text, there are 1 chance out of 4 they make a mistake. This can raise up to 3 out of 4 if they have to type in a different domain name than the one hosting application they are currently logged in. Paths and URLs should not be of users business, it is enough they have to type external site URL when linking to them. Images and internal links should always be inserted using a visual browsing facility.
Default content
Default content is great because it is a way to ensure no page goes live with empty content elements. But sometimes I wonder what is worse: no content or irrelevant content? Let’s face it: average users can’t be asked to remember to check every default content field to see if it needs to be adapted. They often contribute to website as part of their jobs, because they are expert of a given field and so are not specialised in web content. The solution is to explicitly extend their contribution to hidden content such as META or alt attribute, and to make it mandatory on a system point of view. And also to make the system take care as much as possible of things such as pages title or navigation links.
Externally formatted text
Users love pasting text they have previously edited in their favorite word processor. This is probably because lots of WYSIWYG editors featured in CMS are not that user friendly. But this is a nightmare because it imports all sorts of formatting bits that CMS can deal with more or less easily. If there is no easy way to integrate word processor in the CMS interface (or just because it is not a good idea), make sure this kind of error can be handled correctly by the system. It should always block saving or warn user when an unacceptable piece of content has been inserted. Another good work around is to feature a ‘clean formatted text’ button: it transforms any formatted text to pure text. It is almost magic, so make sure you let users know about this.
Hacks
The most important is not what a system can do but what it has been designed to do. Whenever users have the technical possibility to hack what the CMS is supposed to let them do, there is a potential error on its way. A good rule of thumb is that there is danger if code can be inserted (and interpreted as is by the system) on a visual interface. Access to code view in WYSIWYG editor should always be restricted to really expert users. And wild formatting using weapons such as b or u in pure text fields should not be accepted.
Conclusion
To sum-up, first steps to user friendliness of a CMS interface are:
- Browsing computer files and system facility whenever a path to a resource is needed
- Educating users about necessity of good hidden content
- Making the CMS handling site structure and navigation automatically
- Offering a ‘clean formatted text’ facility
- Restricting access to source code
- Forbidding html tags anywhere outside of the code view facility
To end on a positive note, I found out that observing how errors happen gave me a better understanding of what a CMS basic features should be.
Who does what in your CMS? What user should be allowed to edit templates or to approve edits? Each system has subtleties in permissions repartition and profiles naming, but basically there are only a few roles: technical administrator, functional administrator, website/section editor, contributor and reviewer.
