WYSIWYG is undesirable for collaborative editing

WYSIWYG editors are great, aren't they? They can be, especially when dealing with non-strictly-text applications, but they are the wrong tool for collaborative editing, like that done with most wikis. By encouraging editors to focus on making things look right, they are actually less likely to be making content that is right.

It Looks Right

If What You See Is What You Get, then users naturally focus on making what they see correct. The problem is that what you see isn't what's actually there. There is a structure to documents¹ that must be correct if you are to have a hope of maintaining them.

This isn't so bad if only one person is going to be editing their documents. But it's a nightmare in a collaborative environment, as anyone who has had to edit a lot of other people's Microsoft Word documents will attest.

A Small Example

Let's say you like your second-level headings (a subsection heading, like the one at the beginning of this essay) to be large and blue. If you are using MediaWiki, you would write that like this:

==And Now For Something Completely Different==

Anything else results in the wrong result: something that looks wrong. The easiest way to get something that looks right in this instance is to make something that is right.

On the other hand, in the WYSIWYG world, the easiest way to make your heading look like the other headings is to make the text large and blue, usually by pressing a text size enlarger and text color picker buttons. Which, behind the scenes, results in something like this:²

<span style="color: blue; font-size: large">And Now For Something Completely Different</span>

In this world, the easiest way to do something is actually the wrong way to do it. To do it right, your knowledge actually has to be more subtle and arcane than in the plain text world: you have to appreciate a hidden document structure (that is, you have to be conscious of the semantic structure of the document behind the rendered version you're actually viewing--yet you can't see that structure), know the arcane name for a second-level heading (Maybe it's H2--intuitive, but only for HTML users. Maybe it's "subhead" or "subsubhead" if "head" is reserved for a document title), and select it from a dropdown box of styles. You have to know that what you're applying is a style, and pick the right one. This is surely no easier, and may be harder, than the equivalent wikimarkup; it's certainly harder than altering the text appearance ad-hoc.

One might reasonably ask, "What's wrong with that?" And the answer is that it's harder to maintain in various ways, which is fine if you're the only one editing and you want to deal with it. But it's not fine in a collaborative environment.

Specifically:

• The document structure can no longer be interpreted by the software, so the section, for example, will be missing from a generated table of contents.


• A similar objection obtains that you can't link to the heading directly, because there is no anchor.


• If you ever decide a different style of heading is desirable (for example, you're now generating a PDF of your document or just changing the look) you'll have most of your headings in your new look (maroon small caps, for example) but not the several "wrong ones." You've added a great deal of overhead to any such change.

What You Don't See Can Be Important

There's another problem with WYSIWYG editors in this context. Collaborative editing is much more demanding from the perspective of change-tracking and dynamic content. It's important to be able to factor sections of a document into separate chunks, for example, or be able to include or refer to parts of a document dynamically elsewhere.

WYSIWYG-edited documents are full of spurious reformatting and extra whitespace--this happens because users do not see these things. Yet they interfere with tracking changes in the line-oriented text file that underlies the document. An opaque proprietary document format is even worse; the contortions that Microsoft Word, for example, goes to to display changes make things pretty ugly and hard to understand, and don't have nearly the same quality of information as a list of versions and standard diffs (it's more like "cvs annotate"; imagine if that were your only view of document changes?).

Worse still, WYSIWYG editing completely breaks down conceptually given the dynamic nature of most wiki documents. What is the WYSIWYG representation of a TWiki %SEARCH% result or a MediaWiki parserfunctions expression? Or even a template inclusion? Even something as simple as symbolically referring to another section is much harder in a WYSIWYG context. Again, it's much easier to do the wrong thing (link directly to a hardcoded URL, for example), than the right thing.

Adequate Is the Enemy of Good

For a variety of reasons (some of which I've mentioned) well-maintained documents factor out common markup and replace it with symbolic intent. The use of WYSIWYG discourages this. This is related to both phenomena above--making things look right instead of things that are right; and hiding important information. When I create a tag called %BUTTON%, and use it to indicate the names of buttons in my program documentation, I'm capturing an important datum of intent. If on the other hand, I just note that buttons look like [this], then it's up to the good behavior of individual editors to get it right; I've lost the actual intent around the button decoration, and I've lost an opportunity to factor out common formatting into something consistent.

WYSIWYG Editors Make Easy Things Easy

In any written introduction to a plain text markup system, there are a few very easy things covered first: how to make bold text, italic text, change text color and so forth. These also correspond to the buttons that appear on almost every WYSIWYG editor.

I do believe that it's (marginally) easier to "learn" how to make bold, italic or underlined text using a WYSIWYG editor. But it's also pretty easy to learn how to do these few tasks using plain text markup. And certainly no harder to use once learned (it's certainly easier for me to type *bold* than take my hands off the keyboard to click a button before and after typing a short word).

The question is, how valuable is it to make these low-hanging fruit hang incrementally lower on the tree? At the expense of making the slightly more complicated tasks (links, document structure, bulleted lists, tables) actually harder to do correctly? And difficult tasks (dynamic content) essentially impossible? I see little to no value, except perhaps in socialization (a WYSIWYG screen looks friendly and appears easier to the newbie than a blank edit box).

I do think some things could be friendlier and easier than a naked <textarea/> on a web form. Forum-style "helper" editors, that insert plain text markup in response to button pressing would be a good enhancement.

These Issues Are Not Individually Very Important

Any given one of these maintainability and correctness issues is not terribly important. In Perl Best Practices,³ Damian Conway warns against discounting maintainability issues because they're marginal. Collectively, all these tiny issues contribute to sabotage the correctness and maintainability of documents, which is poison to effective document management in a collaborative setting.

On the other hand--do not confuse what I'm saying. I'm not saying that usability is less important than correctness. I'm saying that a WYSIWYG editor makes it harder and is not more usable than being exposed to wikitext markup. It is a humane consideration for editors, assuming they want to produce maintainable documents that other people can edit.

¹ This structure is not a technical detail: I don't mean whether the document is HTML, or wiki markup, or anything like that. Conceptually and philosophically, the document has a structure. Some text has membership in sections, which in turn are part of higher sections. Some runs of text are the names of ships, and appear differently. And so forth.

² And I'm being pretty generous in assuming what it actually generates here.

³ Conway, Damian. Perl Best Practices. 2005. O'Reilly and Associates, Sebastopol, California.