WYSIWYG text editing in CMS
Written at 17:22, on Friday 11 November 2005. Tags: usability .
As visual designer, I’m used to working with website Content Management Systems (CMS) which generate a lot of markup out of the box for the content. Most of it is hackable or reworkable, but there’s always one X factor (not talking about Idols here): the WYSIWYG editor that is included which often messes up my carefully created stylesheet. Unfortunately, the buggers are often an non-negotiable feature requested by clients and end-users, and offered as a unique selling point by CMS providers since they “enhance the usability”(sic) or lower the threshold for users who aren’t web savvy. Instead of having to write angle-bracket-happy HTML or XHTML, they can concentrate on the actual content and how it will visually present itself. Unfortunately, that’s often also the problem: the editor does both too little and too much.
Goals and purpose of editors in CMS
For (professional) copy writers, a good editor should assist them in writing (structured) content, with headers, links (internal and external), images and files and tables. The content should be transformed in proper (X)HTML, while preserving structural information, which happens live as you are typing (it’s WYSIWYG, after all). A good editor should also make it easy to generate accessible markup. Finally, a good editor should integrate well within its environment: it should degrade gracefully if browsers don’t support some of its functionality, integrate with CMS functionality, and make good usage of pre-defined CSS rules.
Lessons from Office 12
While most people will recognize the bold/italics/underline buttons (although they are located in different places in each editor), can you find the button to insert a link? Unless you’ve actually used the editor I think you’ll have a hard time to guess the correct one. The fact that the buttons are unlabeled makes them extra hard to use, since you have to hover over each button whose meaning you don’t know in order to find the one you’ve been looking for. Compared to the jungle above, the few non-standard icons in Spaw seem like a refreshment:
Although I think it’s preferable to have both the link and the image insertion buttons properly labeled.
Too many features
Unlabeled buttons is a symptom of a deeper issue, namely that not all (in some cases even most) features of these editors are very useful in a CMS context. Most CMS (and most blog tools as well) insert user-generated content into a predefined or custom built template. This template generates a large part of the required HTML and also includes a CSS stylesheet which determines the presentation. Editors, on the other hand, try to override the stylesheet by including presentational markup (
<div align="right">) and inline styles (
<span style="color: red;">). But there’s actually very little need to have the full range of formatting capabilities available in a CMS context, since most of the formatting choices have already been made. So out with the font selection and text alignment. And instead of font sizes, let me easily choose headers based on structure instead of presentation. Most editors hide the headers in a dropdown box where they’re not easily discoverable (and thus won’t be used much, if at all), and to add insult to injury, both TinyMCE and FCKEditor hide it under a dropdown widget labeled “Format” (confirming my argument that these editors are purely presentational). HTMLArea provides a nice header dropdown, but right next to the font selection tools it will stand little chance of unaware users.
No live preview
There’s one critical feature which I haven’t encountered out of the box yet, namely a true preview. Most editors work by enhancing a
<textarea> element, which makes it harder to apply a websites’ default stylesheet. But in order to be truly WYSIWYG editors must integrate the websites’ stylesheet in their presentation of the text. It’s too bad that this isn’t available by default (Spaw can be configured to use your CSS, but you have to change the way it’s integrated into your website).
Quality of the generated markup
Writing content for the web should entail more then merely writing the text and converting it to HTML. There are countless of guidelines how to write efficient copy for the web and how to mark it up best for search engines. A proper editor should assist in making it easy and fast to write semantic, standards-compliant (X)HTML. Instead, most editors try to make it easy to style your text with word processing features. This is best seen in the tagsoup which editors produce out of the box. They’re literally full with needless breaks, empty paragraphs, divs, spans and font tags in an order of ugliness comparable to MS Office’s HTML output. In other words, the markup generated is very often purely presentational instead of semantic. Support for valid markup is improving though, but it’s still nowhere near as good as it could be.
Like stated above, most editors try to copy MS Word. However, that interface is optimized for general word processing and not for creating web copy. The task is different, and thus requires a different user interface. Various features which make perfect sense in word processing are hard to copy in HTML because there are no proper markup elements (microformats try to solve that in HTML; unfortunately that’s so very new that editors can’t be expected to take advantage of that). Vice versa, editors take little advantage of the unique capabilities of HTML, and I’m not just talking about header structure and hyperlinks. I have yet to encounter an editor which allows the full range of HTML elements. Even proper support for useful (but little used) ones like quotes with optional
cite attribute (
<blockquote cite="url">), definition lists (
<dd>) or abbreviations with title (
<abbr title="value">) is hard to find.
Other technical issues include general instability of these editors, which cause browser crashes (IE is notorious for crashing whenever MS releases a security update), and lack of good cross-browser support. There is hope for users who care about stability and cross-browser support, in the form of the Rich Text editing widget in Dojo.
There are lots of opportunities for WYSIWYG editors, which is probably the reason there are so many. Even though the editors I reviewed above are among the most popular, some new contenders have the promise of being better suited to web content. For example:
- The WikiWYG editor seems very simple (ugly buttons though), but with good preview capabilities.
- Cameron Adams’ WidgEditor is a light-weight textarea enhancer with clean, semantic markup output.
- The aforementioned Spaw Editor is good-looking and allows you to hook your websites’ stylesheet into the editor for the live preview.
- And finally, the Rich Text editor (demo) widget in Dojo adheres to strict stability and user experience principles. This will be one to watch out for.
The perfect editor doesn’t exist, although a mix of the best features of each editor would be very cool! (And considering that they’re all Open Source, that’s actually doable!) Any features which you think are essential for WYSIWYG editors on the web? And do you know of any good ones?
Comments closed | Permalink