Should Rich-Text Web Editors Be Separate Products?

Blogger: Larry Cannell

I had an interesting conversation this week with Ephox, makers of a rich-text editor used within web content applications (e.g., web content management systems, collaborative workspaces, blogs). Their product, EditLive!, provides the rich-text editing within CrownPeak’s WCM, Oracle’s Universal Content Management, EMC/Documentum’s Webpublisher and others. In addition, they also sell EditLive! directly to enterprises for use within their own applications. Longer term they are planning to extend support to SharePoint and Drupal.

If you aren’t familiar with web rich-text editors, here is how they work: instead of a web application prompting the user to enter text with a simple text box, a rich-text editor replaces the text box with a small embedded browser-based application, which is based on rich Internet application technology, such as Javascript or Java. The editor application looks similar to Microsoft Word or WordPad. It provides buttons for bolding or underlining text, creating bulleted lists, left/center/right justification and many others.

The end result is the user enters and formats text in a familiar interface and the web content application receives HTML returned in the form. The application may not even recognize the HTML, but when the text is returned (e.g., a web page or blog post is displayed) the browser formats it as the user intended. Other rich-text editors that you may be familiar with include Telerik’s RadEditor (popular among SharePoint developers) and the open source products TinyMCE and FCKeditor (popular among many open source projects).

To me, rich-text editors seem to be in one of those “can’t win” positions in technology (like Rodney Dangerfield, they can’t get any respect). Bad rich-text editors can be downright frustrating to use (and can impact user acceptance of an application), but good rich-text editors never get the recognition they deserve. Many of us have come to expect usable rich-text editing capabilities and the editor only gets noticed if it is frustrating to use.

Ephox thinks there are opportunities to provide value beyond simply bolding and bulleting text. Of course, many web rich-text editors provide advance features, such as spell-checking and smart-pasting of text from Word. However, Ephox is betting you will also need features such as:

• Checking against web accessibility standards. These standards ensure people with disabilities can access information on the website (e.g., WCAG 2.0 recommends always having alternate text to support someone who cannot see an image)
• Support for tracking changes (similar to Microsoft Word) to enable multiple authors to see each other’s changes and to approve or reject them
• Support for adding comments or annotations (also similar to Microsoft Word) to enhance scenarios provided by tracking changes (e.g., someone may add a comment saying “I deleted this sentence because…”)

Checking against web accessibility is something that should get the interest of IT strategists supporting a large global enterprise. However, what about support for tracking changes and commenting on text? To me, these are features I had not considered the province of rich-text editors before. Shouldn’t these be features of the web application itself? I can see arguments either way.

What do you think?

• Is there a market for rich-text editors that are separate from the web application vendors? (So far, based on the success of rich-text editor vendors and open source projects, the answer seems to be “Yes”)
• Should rich-text editors provide capabilities beyond what might be expected by a web application (such as tracking changes and adding comments)?

Comments

[Saqib Ali]

p.s. I have not seen any 3rd party rich text editors that utilize the HTML 5 Canvas. We desperately need that......