Create a Rich Text editing experience that authors won’t avoid

2 Replies

Beware of Rich Text EditorWYSIWYG Rich Text editors are central to every CMS.   These tools enable content authors, who might know nothing about HTML, to create HTML content.

However, content authors frequently fear and avoid their CMS’s rich text editor.  These tools are perceived as confusing, buggy & fragile.  As a result, content is written off-line, using tools like MS Word, and then pasted into the CMS’s Rich Text editor.  Unfortunately, this behavior creates a completely different set of challenges.

This post is devoted to reshaping this behavior.  The goal is to lure content authors away from their trusty off-line tools and instead use their CMS to compose new content.  Below are some recommendations for creating a more friendly web-based authoring experience.

1.  Use good typography

Many Rich Text editors use extremely hostile fonts & font sizes.  No content creator is going to spend an hour writing content in an editor that makes them squint.

TinyMCE defaults to using small fonts. No content author will want to compose in this environment.

Readability is a problem, in general, on the web.  In fact, there are applications devoted solely to transforming the web into a readable format.  The same principals used to create legible web sites, can also be used to create a pleasing authoring environment.

2.  Go ‘full screen’ for distraction free writing

In most CMS’s, the Rich Text editor occupies a very small portion of the screen.  This is appropriate for small content touch-up’s, but completely undesirable for extended writing sessions (like this article).

Blogger has one of the worst Rich Text WYSIWYG authoring experiences imaginable.

It’s frustrating to edit a 4-page article and only see 2 paragraphs at a time.  It’s even more frustrating when most of the screen is completely unused.

Most Rich Text editors (TinyMCE, CKEditor, RadEditor) have a full-screen feature that can be added to the toolbar.  By using this feature authors can easily toggle into (and out-of) full-screen mode.

3.  Wrap long-lines of text for readability

A single line of text should not be wider than 65-70 characters.  Anything longer will be difficult to read.  This rule is well known in typography, but often ignored in Rich Text Editors.

Orchard CMS - tiny fonts and no word wrapping means that content authors will write their content elsewhere.

This problem is particularly noticeable with full-screen mode, or any CMS that occupies the entire width of the screen.  Thankfully custom CSS styles can be applied to the Rich Text editor and establish a width to wrap text.

Here is an example of ‘full screen’ edit mode with comfortable word-wrapping:

There is a reason that WordPress is beloved by its users.

4.  Use the TAB key to indent lists

Outside of the web-world, the tab key is used to indent a list item.  (Shift-tab is used to out-dent a list item).  However, on the web the TAB key moves to the next field in a web form.  These 2 conflicting conventions are at war in Rich Text editors.  As a result, authors are frequently frustrated that a familiar convention (TAB to indent) sends them somewhere else in the web page.

Indent & outdent options in WordPress's toolbar

Rich Text editors (TinyMCE, CKEditor, RadEditor) have an option for capturing the TAB key and modifying the behavior.  However, web savvy users are going to be equally frustrated if their browser’s traditional TAB behavior is modified.

My advice, modify the behavior of TAB when authors switch into ‘full screen’ mode.  In this mode there are no other web form fields.  Consequently, no one will be using the TAB key to move to the next field.  When ‘full screen’ mode is switched off, restore the traditional web-behavior of the TAB key.

5.  Auto-save to protect against computer mishaps

Imagine the unimaginable happens…

Authors are lured away from MS Word in favor of web-authoring tools.  These tools create a comfortable authoring environment and they forget they’re on a web page.  Instead, they are purely focused on writing.

An hour passes and the author clicks Save…

Your web browser reminding you that your Rich Text WYSIWYG editor is stateless - and now your article is gone

This error will quickly cause authors to regain their fear of web-based authoring tools and retreat to predictable off-line environments.  In MS Word, even if power is entirely lost, the content is typically recoverable.

On the web this level of auto-recovery is also possible by periodically saving the editor’s state.  This can be done through…

  1. HTML5’s off-line storage
  2. Browser cookies – beware limitations
  3. Server-side – through web services or the CMS

Realistically, #3 is the path most projects will pursue.  However, this will require developers to invent a storage & recovery solution.  To my knowledge, no Rich Text editor offers a canned solution to this challenge.  However, there are likely CMS products that have implemented this feature.

Parting words…

Microsoft Word has been around since 1983.  It’s unreasonable to think that a blog post with a few tips could prescribe a full alternative to this software.  Like it or not, MS Word will continue to be an enormous force behind the content that finds its way online.  Accept it and learn to cope with it.

However, it’s also true the Rich Text editors (and CMS’s) frequently make UI decisions that are downright hostile to content authors.  These systems work great for developers (who are pasting “Lorem ipsum” sample text all day), but create poor experiences for extended writing sessions.  It’s little surprise authors actively avoid them.

Hopefully the recommendations described above will help repair some of this damage.  In addition, I’ve attempted to put many of these recommendations into practice in the following sample (give it a try):

Try It! – Best Practice WYSIWYG Rich Text Editor

  • http://alfonsoml.blogspot.com Alfonso

    You are wrong with number 1 and 3, at least in the way that you are exposing it.

    The editor should match the final content as much as possible. If you show different fonts and styles while editing, then the user will be confused because the final site doesn’t match what he has created. That’s why the editors allow you to specify the stylesheets that must be used for the content (and it’s also part of the problem about why pasting from Word can lead to troubles and workarounds)

    In that stylesheet you put the correct font-family, size, color, background-color, so that the edited content shows really how it will show up in the final content. If the content will have a fixed width, then you should also adjust the editor so the content is shown with that width, or the user will see a very long line while editing, but a narrow column in the final site and he will have a hard time to make the text wrap around correctly that small image that he has added.

    About the auto-save, it’s harder for an editor to do it correctly by itself. Yes, it can use some nice local-storage for the content, but how does it know when it should be shown back to the user?
    If it’s part of a CMS it’s “easy” to save drafts while it’s editing, and that way if the session is lost, the browser crashes or whatever, the user has a well established environment where he can find the latest draft (even the CMS can tell him upon re-login: You were working on this draft).
    But the editor, how does it knows that the content has been successfully saved and it doesn’t needs to keep it’s local storage copy? remember that reading the contents of the editor can be done to provide a preview, to perform some custom processing on the contents, the data can be saved by ajax or post, there’s no easy way for the editor to know if the data has been safely saved or it’s under risk.
    And when a new instance is created…
    How does it knows that it’s trying to edit again that previous content (and then it should provide the user with the option to restore the data) or it’s editing something different?
    I’ve thought about this kind of issues for my WriteArea extension where autosaving could be specially interesting, but providing a good UI and detection for when and how to show it isn’t easy. (although in fact I think that with my extension it should be slightly easier than in a purer editor)

    • Gabe Sumner

      Hey Alfonso,

      You’re hitting on another post that I only have half-written (WYS is not always WYG). This is certainly another source of aggravation for authors. You are correct that the editor should (as much as possible) mirror the final result.

      However this felt a bit outside the scope of this post. In this post I wanted to identify the things that make it painful to compose extended content in a Rich Text editor. Regardless of what font sizes or page widths the web site uses, these items can become a source of pain during the writing process.

      Great comments though. I’m delighted that you’re reading. I’ll also definitely check out your WriteArea extension.