Looks like we’ve come to a decision about the editor to use for writing web copy in Rapid Site. There were several options out there but in the end it came down to two which fulfilled our criteria.

WYSIWYG Editor criteria

1. Ease of use.
   This is fundamental to the project. Our users will understand copy writing from using applications like Word, so the interface must be recognisable, usable and intuitive.
2. Quality of Code.
   Rapid Site is designed to meet W3C specifications in XHTML, CSS and Accessibility. This means the code produced by the editor must also meet these standards as it will be included into the site.
3. Ease of Development.
   OK, not the number one priority, but a good API or open source code will allow us to implement the editor flexibly. Changing features or the interface easily will allow us to bring the editor closer to the goals of the project.

The final candidates.

Only two editors really measured up to what we were after. These were TinyMCE and xStandard.

TinyMCE is a popular open source editor used with many other open source Content Management Systems and Blogging applications (WordPress, Jumla, Drupal, etc). It has good documentation and a large user base. It is very flexible and can produce standards compliant code with only a small amount of tweaking. The feature set available to the user can be as narrow or extensive as required, and custom css tags are available to insert. It will clean up text pasted in from Word and is very intuitive in it’s interface. It is a javascript editor that works through the DOM so the separation of layers is maintained.

xStandard was built to be a standards compliant wysiwyg editor and so fulfills that context easily. It comes in two versions, a free lite version and a commercial version. The interface is again very intuitive and Word users will feel at home (it also has a Word code cleaning option). The interface is again customisable with user features available to add or remove, in addition, like TinyMCE, custom styles or editing of pre-existing styles is available. A useful feature for a commercial product such as Rapid Site is the interface is skinnable, so it can be given a ‘Rapid Site’ look. The API is extensive and well documented so it can be flexibly implemented and it will work with our existing systems. xStandard is implemented as a browser plugin, which does involve a download and install but this is quite easy and has some benefits as it gives the application access to the clients file system.

…and the Winner is…

Although as a simple wysiwyg editor the two final candidates are about neck and neck, with TinyMCEs implementation method (it essentially just hijacks textarea tags, so remove TinyMCE and you are left with textarea tags!) being a definite advantage.

But in the end xStandard won due to the extensive feature set available in the paid option. As xStandard will implement as a browser plugin it has control over image uploads and allows clients to drag images from their desktop straight into the editor, which are then uploaded and inserted with no further input from the user. This is what is called a killer feature. In addition it means we have control on the client side over the size of image uploaded, in TinyMCE we can only find out what size of image is uploaded after the upload, hence wasted bandwidth if the user uploads the 4MB image straight from their camera. Whereas in xStandard we can stop the process and give the user an error message before upload begins.

…and finally…

It was also nice to see our decisions confirmed by Peter Krantz in his annual accessibility review of wysiwyg editors where xStandard gained most points for Peters criteria based around accessibility and quality of code produced (although not far ahead of TinyMCE it must be said)

So all thats left is to implement it.

(p.s. sorry Looi, it’s another long one.)