There are many CMS systems on the market at the moment. All of them allow users to create and manage content, each of them in it’s own specific way. I have been working with several CMS systems in my career. Each of the system is different from another but there are some pieces that are common for most of them. In this post I would like to share with you my observations and thoughts about a capablitity that many CMS systems have, which often is a source of problems. That feature is rich text input for editors.

The good

Flexibility. Setting up sites using CMS systems often requires defining page types, templates or other artifacts which define structure. This is great for consistency as it allows us, the developers, to have full control over the output. However this is not a best solution for editors, as they often see it as a limitation. Rich text fields are a good way to give more flexibility to the users allowing them to shape the content to their liking and be able to provide more relevant information.

Modern content management systems offer many capabilities in their rich text data types, allowing to format text, embed multimedia items, link to internal and extenal content.

In certain scenarios instead of using multiple properties/fields in a content type, we can combine them into a single rich text field, minimizing the complexity of the content type.

The bad

With great flexibility comes great responsibility. Having all the possibilities handy, we have to find right balance between which options we should hand out to the editors and which ones are not a must.

When using rich text fields, there are many things to consider:

• Are we predefining styles and formats for the content or are we passing the control over the styling to the editors? It might have impact on the consistency of the content if editors have too much freedom.
• Is there a need for custom scripts in the rich content? Ideally not as it can have some serious security implications that have to be considered and mitigated within the application.
• Is it required to create tables in the rich content? Often the rich components provide editors for tables but sometimes they are not meeting user’s expectations. Often providing this kind of functionality might require a lot of effort and it could be hard to make it good enough for the editors given time and budget constraints.

The ugly

Very often information architecture requires us to put some restrictions on the fields, like length, maximum/minium values etc and validate against those restrictions. Validating rich-text fields might be cumbersome, due to the fact that raw values are represented as raw HTML. For example, we have to take into account HTML entities encoding for text length, i.e. & becomes & which pumps the raw length of the field by 3 characters and skews maximum length validation. The same goes with HTML tags used in the content - bold, italics, lists, paragraphs and so on.

Editors sometimes expect that the rich text editors in the system will be 1-1 or almost 1-1 match to desktop text editors, which rarely is the case. List formatting, indentation, mixing list styles, managing images are often simple and limited. In many cases those features can be configured to some extent or customized with the code, but we have to be careful and balance between the profits it can bring and potential issues and bugs that we might introduce.

Very often editors ask for the ability to paste formatted content from the text editors like MS Word or similar. Not all of the systems support that out of the box. Even in case that it is supported, there might be issues with retaining/removing/merging the styling of the pasted content and to maitain consistency on the final pages. It might take some back and forth and a lot of testing to make it work as expected.

Summary

I have been working on several systems that provided rich text capabilties for their users. From my experience, I often see them as a source of all sorts of problems and endless bug reports. I’ve learnt that RTE components require good specification, a lot of love and attention and many iterations to make them perfect and eliminate of all the edge cases.

Wherever possible, I strongly discourage to use RTE fields/properties and work closely with the stakeholders to find the best solution. If it is not possible to find a solution without rich text, I drive towards limiting its flexibility to minimize possible edge cases and potential source of issues and frustration for the users.

If you have your own thoughts on this, don’t hesitate to leave a comment!

Cover image by Fabrizio Van Marciano from Pixabay