CustomerCentrix

A rich text editor is a given in the world of desktop computer applications. Nobody, except for maybe a few programmers, uses notepad when wordpad is available. The vast majority of computer users these days have MS Word as their primary tool for creating documents. When we move to web applications, things change a little bit because the functionality that desktop users have come to expect with Word are fairly heavy weight in terms of the code necessary and overhead in processing. This makes it a challenge to run a nice, full-functioned word processor inside a browser.

There are a variety of solutions for this problem. The basic categories are listed below with comments regarding their use.

• Low tech - Just provide the standard plain text edit box and let the users do their best with it. Some advanced users will be frustrated and may try to add raw html to get what they want. Many others who want to just have line breaks and white space may get unexpected results. Another workaround that is fraught with problems is when users attempt to paste large chunks of html from their favorite html editor (or MS Word). Broken links, external css and image files that do not work and lots of other problems are likely to occur.
• Plain text with simple markup. This approach is used with success by Wikipedia. The basic idea here is that the kinds of markup needed are limited and users simply add special characters where they want to see rich text effects. You put a * in front of an item to make a bullet list, a # in front of an item to make a numbered list, etc. This works because it is much simpler than html and quick and easy to learn. A couple pages of reference material are all that is needed to get going. See this description. Other than wikipedia, there are a few other implementations available for general use in other applications.
• Edit offline and then upload. For builders of static web sites and creators of much of the best web content available, many professionals use tools such as those from Macromedia as well as open-source desktop applications. These generally create a file or set of files on the users machine that can then be copied to a web server. Web applications then have some mechanism for copying the files and making them available, either built-in or not (FTP). The main issue with this method is that it is not possible for an average non-technical user to create content and publish it easily in this way. The basic steps of creating, editing and uploading are simple in understanding, but quickly become complicated by multiple files in multiple locations.
• Integrated offline editor. A number of desktop editing tools, particularly those focused on html output, have features that allow them to save "directly" to a web site. How well this works depends to a large extent on the web application and the method of integration (WebDAV, HTTP, FTP, proprietary). Our experience with this is several years old and was not very good. It has most certainly improved, but we are generally focused on solutions that are inexpensive to implement for a large number of clients and also easily used by non-technical users.
• Online rich text editor. This seems to be the "sweet spot" for most internet applications today. Using some combination of javascript and dynamic html, a user can add basic markup including fonts, colors, lists, tables and others. There is typically one or more toolbars to accomplish this, and it is downloaded and available automatically with nothing but a slight delay in most cases. Yahoo and Hotmail have had this option for years for creating mail messages and other online documents. Our current favorite for Drupal use is TinyMCE, and we may try to replace our LearnCentrix editor with this one at some point.

There aren't any hard rules about what option is best for what application. All have tradeoffs including:

ease of use vs functionality
  The easiest is also the most boring - plain text. The hardest requires training and customer support, but allows a nearly infinite amount of options and design capabilities.

ease of installation vs functionality
  I have found with Drupal in particular, but also other applications that the addition of even a relatively simple online rich text editor can add more code than the rest of the entire application. There are commonly installation issues that are more difficult to resolve and also assumptions about "integrated" or "included" functionality that is related such as handling of images and upload file management.

integration and suitability to application
  I couldn't come up with a decent heading for this tradeoff, but the idea is that sometimes marked up text doesn't work well with the underlying application. In some cases, the application expects plain text and when it receives content that is marked up, you get unexpected behavior. We have experienced emails that are sent with a jumble of html tags, styles intended for the content that take over the rest of the application and a variety of other oddities that all require coding to prevent future occurances, support to explain and fix, etc. A specific issue that we have repeatedly experienced is when a user is unsatisfied with the limited amount of markup in a simple web editor and decides to just paste the html from a desktop application. MS Word is the most common and unfortunately has a rather complicated version of html. Although I am sure it is perfectly suited for MS Word, it isn't readable by other editors and is very difficult to understand manually.

free vs client license vs server license
  Although there are some decent open source tools for editing files, many of the full functioned, desktop tools are several hundred dollars or more for each client. In addition, some of the server tools that are available require a license as well.

Realistically, the more users that you have, the more varied are their expectations and capabilities. We added an online rich text editors to our LearnCentrix application several years ago and more recently added optional multi-file upload capabilities. We also have FTP available to many users, so basically, we are trying to accommodate all users with their preference of editing methods. Some of our Drupal installations have online editors available and some do not.

FYI, this particular site is currently working with with just a plain text edit box. The minimal markup that you see such as the bullet list and links is done with knowledge of a few html tags.