Blog Discussion: How important are rich text authoring experiences in 2024?

Great read, Sean!

I believe rich text authoring remains important, but its role has evolved. In the past, rich text was often overused, giving marketers and content editors near-total control over page content. Nowadays, even with structured content, there are still scenarios where rich text is needed - like when text fields require more than plain text, such as hyperlinks. When I use rich text in projects, I prefer to minimise the functionality/toolbar options to only what's necessary. 😂

In these cases, a Markdown editor could be a great alternative. It allows editors to manage text while easily inserting hyperlinks. For Xperience by Kentico projects, I’d love to see a native Markdown editor alongside the rich text editor - one that's user-friendly and includes the Kentico internal/external URL selector.

On my blog website, I use the page builder to fully drive my blog post's content. For text, I rely on the rich text widget (mainly for the internal/external URL selector). However, I often add images or videos between text blocks using structured content from the content hub, through Image/Video widgets. These widgets retrieve the image or video, along with descriptions and any other metadata stored for those assets. This approach gives me, as a developer, full control over the visual display of these elements. It also ensures editors don’t place images or videos inside rich text widgets, maintaining consistency and flexibility in content layout.

@liamgold

there are still scenarios where rich text is needed - like when text fields require more than plain text, such as hyperlinks.

Yep, this is the most common scenario I've seen along with lists along, bold, italic, and smaller headings (<h1> is always handled by a template or component).

I prefer to minimise the functionality/toolbar options to only what's necessary.

Good strategy. Do you ever worry that content will be copied into a rich text editor from somewhere else and bring along styling that the toolbar wouldn't allow?

I’d love to see a native Markdown editor alongside the rich text editor

I'm definitely biased, but I'd love to see one as well.

I was thinking about these questions while writing the post.

• How important are improvements to rich text/markdown editing in Xperience by Kentico compared to all the other features?
• What's the baseline where improvements have diminishing returns?
• What we have today wouldn't be good enough for Kentico Portal Engine sites from 7 years ago, but what's that gap for what is needed today?

I use the page builder to fully drive my blog post's content.

Good to know it's working for you! I definitely think I'm going to try it out, if only to improve my editing experience now that I'm storing media assets in the Content hub and want to reuse more existing content in blog posts.

@seangwright

Good strategy. Do you ever worry that content will be copied into a rich text editor from somewhere else and bring along styling that the toolbar wouldn't allow?

I encourage our clients to use 'Paste as Plain Text' (Ctrl+Shift+V) to remove unwanted formatting and retain only the text content. This way, they can reapply formatting like bold, italics, and hyperlinks, ensuring the document remains clean and well-structured.

How important are improvements to rich text/markdown editing in Xperience by Kentico compared to all the other features?

While adding new features to Xperience by Kentico is valuable, I believe it's crucial to focus on improving the core aspects of content entry, such as enhancing the rich text editor or integrating a proper Markdown editor. These tools are fundamental to our new projects, and clients often encounter issues with the current setup. For example, the internal page selector currently displays a long cmsctx preview URL instead of the actual selected page URL, which is not ideal for content editors and marketers. It causes confusion and can lead to delays in content actually being published.

What's the baseline where improvements have diminishing returns?

I think the core functionality for rich text/markdown editor needs to be there, bold/italics/hyperlinks/headings. A proper baseline that is solid would be amazing, and then anything above any beyond that could be added in future releases.

I wouldn't expect this anytime soon, but the ability to embed references to Content Hub items/Structured Content within a rich text/markdown editor would be great, and then the channel that is responsible for displaying that content would replace that block with the appropriate rendering. But this isn't something I'd see as a baseline requirement.

I wouldn't expect this anytime soon, but the ability to embed references to Content Hub items/Structured Content within a rich text/markdown editor would be great, and then the channel that is responsible for displaying that content would replace that block with the appropriate rendering. But this isn't something I'd see as a baseline requirement.

This is basically the approach WordPress and some headless CMS products have taken.

I understand the appeal! But I've also seen how much the WordPress Gutenberg maintainers have worked to get a high quality experience out of it. It's a long road and the payoff seems... not huge, given the other drawbacks of rich text vs structured content.

I can still be convinced otherwise, but right now I feel that pulling content and metadata out of rich text and managing it as separate structured information is a better approach than putting more structured information into rich text.

I agree with you that the basics need to work well - bold, italic, heading, URLs, lists, paragraphs. These need to all work intuitively with a really smooth UX.

I was worried about this article when I first started to read it. My impression was that this article would focus on saying that one should not use Rich Text. I am glad I was wrong.

The recommendation to use structured content as much as possible is dead on in my experience, but the point about "Rich Text is not dead" is also very true.

In my opinion, when building high quality websites, you still need both approaches. When done right, reusablity and governance still allow for flexibility and creativity.

In my opinion, when building high quality websites, you still need both approaches. When done right, reusablity and governance still allow for flexibility and creativity.

I think we're in complete agreement 😅...

I have been thinking about this topic because many developers and content marketers might not realize what they are missing by relying too much on rich text.

This could happen because of the content management products they are used to working with (WordPress, MailChimp) which have great rich text authoring, but treat structured content - or at least the separation of content and design - as an uncommon corner case.

It could also happen because people have brought their 2016 mindset to 2024 and "why should I change if rich text still works?"

My goal with this post was to get a conversation started and make sure people were at least aware there are choices to be made and the value of structured content should not be dismissed - it will become more and more value as time goes on!

Rich Text editing is a crucial feature, and content editors appreciate the flexibility it provides for designing content with markup. However, as a developer, I always ensure that editors have only the functions they need, which varies based on the project, the editorial team, and their workflow.

It's important to understand that content created in Rich Text Editors is typically confined to the page where it's placed, making it inaccessible to other areas. If content needs to be reused elsewhere, it should be moved to a shared/structured location. Communicating this concept to content editors is one of my main responsibilities when consulting and training.

Even when there's no immediate need to share content across channels, using a structured approach can often be a better solution for the editing team. Rich Text editing can become cumbersome, especially when trying to create complex elements like accordions, FAQs, carousels, content tabs, or tables. Relying too heavily on these editors can lead to disorganized content and a poor editing experience.

Before implementing these complex components directly in Rich Text, consider moving them to structured data sources instead of creating confusing inline editors. From my experience, most of these elements benefit from being centralized, as they often need to be shared across multiple pages or platforms.

Platforms like Kentico offer robust alternatives to Rich Text editing for implementing such features, providing a more organized and maintainable approach.

@elmhoef76

Communicating this concept to content editors is one of my main responsibilities when consulting and training.

Great point! It's easy to forget that customers of CMS/DXP are often not well versed in the available stragies and best practices for using them. Someone has to educate customers about this and it's often senior developers who understand the impact of a good or bad content model and are in the best position to help communicate this.

Rich Text editing can become cumbersome, especially when trying to create complex elements like accordions, FAQs, carousels, content tabs, or tables. Relying too heavily on these editors can lead to disorganized content and a poor editing experience.

I think this is a great way to explain the value of structured content - use examples marketers are familiar with like FAQs and carousels even if really complex content models "show off" the value better.

I also like that you mention a "poor editing experience" because it's easy to focus on the initial authoring experience and forget that it will be someone's responsibility to come back to that content, understand it, and make changes to it in the future.

Markdown is definintely the future I believe.

We took a marketing team and trained them on Markdown (providing some links near the editor), and they were able to adopt it without much issue. Links and images are always difficult without a great Markdown editor, which we split into separate elements for the editor experience.

I like how the Community.Kentico.com has their markdown editor with the similar hey, don't know markdown, click here! type of link.

We took a marketing team and trained them on Markdown [...] they were able to adopt it without much issue. Links and images are always difficult without a great Markdown editor, which we split into separate elements for the editor experience.

It's good to hear your non-coder users were able to adopt Markdown without much issue. I agree it's a good middleground between pure structured content and rich text... and the image/link syntax could still be easier in Markdown.

I think a solid Markdown editor like Milkdown can make things easier for editors, but still requires some technical implementation time.

I like how the Community.Kentico.com has their markdown editor with the similar hey, don't know markdown, click here! type of link.

Thanks! I thought that would be helpful to people 😅.