Of CMS and WYSIWYG editors
Should writers and contributors using CMS have a say in how a web site renders text and paragraphs?
Opinions differ. I consider this a much tougher question than it seems at first, even in these times of UX and Rich Internet Applications.
Most of the discussions I've been tracking and following tend to make it either a user-related problem (users love to WYSIWYG) or a technical problem (embedding and standard compliance) and fail somewhat to take into account that context plays an important role.
The Web allows for different, competing design and use models for CMS, and this is not a simple matter of personal taste, developer skills or editorial democracy. If you are implementing largely interactive web sites, and this could be for example an intranet wiki or your favorite social platform, having a whiz-bang WYSIWYG editor might make sense. Even to me, I mean1. In this context, the often unavoidable different personal communication and typographical standards 2 can probably be traded in for a richer experience. Say, let's favour a little creativity and clutter over visual polish and typographical evenness.
As Seth Gottlieb points out in his posts3, it's a compromise: I'd like Word, you'd like pure data to fetch, use and reuse, so let's settle for some middle grounds.
I can see the logic but I do not think it directly implies a WYSIWYG editing environment: it implies a meaningful, usable interface.
WYSIWYG may be difficult to apply to the average facing-out company / enterprise / organization web site, where there may be a number of layers of control and heavy reuse of data. But most of all I cannot picture the writer's right or freedom of expression coming such a long way: typography is a large part of the user experience, even on the Web4 and typography is professional work as much as layout and graphic design is. Editors in these environments shouldn't be concerned with visual output. It shouldn't be their job to decide if strong is bold or if emphasis is Sapphire Blue, Tahoma.
There is nothing inherently user-centered or technical to it: in theory, writers could be taught how to write by the rules, and a company could enforce internal style guides and tighter editorial control. Similarly, embeddable rich-text editors have undoubtedly come a long way since their early incarnations, so XHTML and CSS compliance, or at a larger degree standards compliance, is mostly accomplished. Moreover, FL/OSS editors are modifiable if further needs arise. Embedding these pieces of software is mostly trivially done.
When I think about it, it seems to me we may have some new broader underestimated case of content / layout separation: XHTML / CSS, editing (content) / designing. Editors are in for the former, information architect and visual designers should be in for the latter. This is not technical, this is ideological.
So, it doesn't really matter if both fields have their technical / organizational shortcomings: if you favor plain entryfields, how do you account, say, for tables ? But if you go for WYSIWYG, how do you enforce style and typographical coherence to the CLASS level5?
More often than not, the WYSIWYG experience is somewhat baffled by the fact that a) it's incomplete (since it's rendered inside a modified textarea) b) it does not provide actual in-page visualization, without any administrative menus, buttons, entryfields, etc. It just provides content-item previewing; c) it actually allows for all kinds of direct inline tag manipulation but no complex hooking up to the various classes and ids that usually are at the core of CSS in any CMS.
Even those who are pro-editors point out that unrestricted access to the truckload of features these fluffy creatures offer is bad. Users gets confused. Pages break. Times New Roman, plastic pink, bold, 124pt on a web page? Bad. Bad editor, bad.
My stance is that in complex editing environments like those provided by CMS, if somebody decided to invest time, money and resources in building up one or more templates, we have rules and we shouldn't try to give users ways to break them. As much as it is a compelling (if market-driven) problem, cut'n'paste from wordprocessors like Microsoft Word is an incidental issue, and editing in a CMS something that should be addressed by a fresh approach, not by implementing some thousands buttons on top of a textarea, as technically sound as that may seem.

If I really have to think about providing users visual aids while writing and editing content, I do not see WYSIWYG editors as a generally viable solution. What I think is that we have something more interesting to investigate, albeit not so trendy right now, and that the WYSIWYM6 paradigm could be an interesting path to follow. If you have some mouse clicks to spare, try out WYMEditor: in the long run this could be a better way to go.
- 1. For some insights on why you should possibly advocate online rich-text editors , visit Infospaces and drop Emanuele Quintarelli a line. He even managed to get me convinced about rich-text editing in FaceTag, and that means he has a point. Maybe.
- 2. I personally know a number of otherwise perfectly sane and valuable professionals who use to render every important sentence in their writings in bold, italics and underlined. All together, like this, so 'they stand out'. I bet you know a couple of them too. Now picture them contributing with full editorial rights to The Times.
- 3. See The 6 Million Dollar WYSIWYG Editor in Related Links
- 4. You may not completely agree, but check this out nonetheless. Worth a read.
- 5. To my knowledge, if you use FL/OSS, Spawis the only embeddable editor that allows local CSS even during editing.
- 6. What You See Is What You Mean, and doesn't that sound semantic?







