^ Minor Exaggeration
As astutely pointed out by Rachel Andrew, WYSIWYG editors are a semantic minefield, as well as being a serious styling/consistency weak point in many a CMS.
The Problem
As well as the messy code that most WYSIWYG editors produce, the problem is to do with different people’s roles and the span of their influence. And to illustrate it, here’s a nice picture:
(Download as SVG)
Interactivity and Styling are self explanatory. Layout refers the laying out of elements on a page, the order things come in, etc. Meaning is altogether more abstract, e.g:
<ol>
<li>Hey, a pointless List
<li>So pointless the order of items doesn't matter
</ol>
and:
<ul>
<li>This comes first
<li>Whereas this comes second
</ul>
both produce output that, unstyled, looks very similar and is laid out in a similar way. But the two have very distinct meanings. Of course, meaning can also be expressed through the actual text.
With a WYSIWYG editor, the content creator is being given control over meaning, layout and styling. But it’s the designer’s job to style the meaning created and laid out by the content producer. Giving the content producer control over styling can wreck consistency and integrity of the styling of content.
The Solution?
The astute observer may have noticed the other editor type in the image — the WhatYouSeeIsWhatYouMean editor. These seek to allow end users to create structured meaning instead of styled meaning.
With a WYSIWYM editor things are significantly improved, as the content creator only influences meaning and some layout. There is one good one available that I know about.
FIX IT NOW FR CHEEP
If you can’t or don’t want to switch to a ‘real’ WYSIWYM editor, good news: they easily can be faked by altering the config on most common WYSIWYG editors.
What I’ve done in at least one past project has been to give the user an extremely cut-down WYSIWYG editor exposing only format, list, B/I/U and any other required controls (e.g. here there are image and table menus):
Despite sometimes getting annoyed at the messy output created by these editors, I’ve found that most semantics problems are sorted as soon as you show the client the ‘Format’ menu.
I did this using TinyMCE with the following config:
tinyMCE.init({
plugins : 'table',
mode : "textareas",
theme : "advanced",
theme_advanced_buttons1 : "formatselect,bold,italic,underline,strikethrough,separator,bullist,numlist,separator,undo,redo,link,unlink,separator,image,separator,tablecontrols",
theme_advanced_buttons2 : "",
theme_advanced_buttons3 : "",
theme_advanced_toolbar_location : "top",
theme_advanced_toolbar_align : "left",
theme_advanced_statusbar_location : "bottom"
});
I’ve found that once clients get round the idea of:
- Using heading levels instead of bold/bigger font size
- Not being able to change fonts
- Not being able to change font size
the whole thing becomes a breeze.
In Conclusion
The point to take from all this is (as I find so often) the fact that Educating clients about the web is the most important part of a web designer’s job.
Whether it’s teaching people how to use markdown, how document outlines work or even when to use ‘bold’, fostering client understanding and competence is a far more powerful tool than the idea for the ultimate WYSIWYM editor I’ve suddenly had, or any other software tool.
But How?!
If you’re not a natural teacher, explaining things like this can be tricky. Many people learn best by example, though, so you can educate clients in layout, meaning and tone through a style guide (Anna Debenham has put together some great documentation on these).
Another random idea that could be useful for demonstrating this to clients is the 3D document tree WebGL thingamajig you can get for Firefox. Document outlines can be hard to express as you can’t really see them, so having a contour map of a HTML document could be a great way of expressing it to clients.