As we move out of the Dark Age of Kupu and into the Enlightened Age of Xinha we are faced with an interesting set of issues and opportunities: not only do we have to determine the degree of user control we allow but also—and to some degree as consequence to that—we have to question certain fundamental assumptions about the (in)appropriateness of the WYSIWYG model. For other information regarding our WYSIWYG decisions see: What WYSYWIG is Up To and the WYSYIWYG Wishlist.
User Control
In recent conversations with Jackie I argued for limiting (though I prefer to say managing) user options to increase user happiness. My justification for this is best described by the adjacent line graphs.
Our editor should make it easy for our users to create documents for the web, but it should not provide so many options as to be stressful or confusing. As Kathy Sierra says, “the amount of pain and effort should match the user’s perceived payoff”. Our users want control and ownership of their pages, and that is something with which we provide them, but at what point do we provide so many options that the user no longer feels in control of the page?
We need to tailor the editor to fulfill the needs of our users: basic word processing, including basic inline type styling (bold, italic, underline, strikethrough, color); list creation (ordered and unordered, definition lists(?), and nesting); table creation and management (table stying, row and column manipulation); image inclusion; hyperlinking and page creation (wicked, internal, and external should be consolidated). But, we don’t need to provide much more… in fact we probably shouldn’t provide things like: font families, absolute font sizes, perhaps even text alginment (left, right, center)…
The WYSIWYG Model
…because the WYSIWYG model, as we have been thinking about it, may not be the ideal way of fulfilling these (perceived) needs. As Luke and I discussed it: the WYSIWYG model is predicated on emulating the experience of a typical word processor, specifically in regards to designing for presentation, and thus fails engage with the medium that is the web. As stated above, our editor should make it easy for our users to create documents for the web. The concept we have been working with emphasizes presentation (how things look) when it should equally emphasize structure (how things work) and semantics (what things mean).
To provide our users with a better experience we need to better understand web standards (like A List Apart) and incorporate all three modes of thinking/editing into our editor in a way that is easy for users to understand. WYMEditor, an example Luke pointed out, works on a WYSIWYM model and emphasizes the meaning of content over its presentation.
The WYSIWYM Model: Ideas About Implementation
It’s possible and desirable to implement core elements of the WYSIWYM model in our editor in several ways:
+ Clean Markup
Example: If something like text-alignment is crucial (which it’s not) then non-exclusive block-level CSS classes are the place where it should be defined, not the “align” or even “style” attributes.
Producing acceptable (X)HTML is perhaps the technically most difficult yet also more important thing for our editor to do. There is little point in focusing on the presentational niceties if the markup won’t render correctly anyway. The markup produced should strive to be structurally and semantically proper, conform to standards, and not be contaminated by visual information like font styles and weights, borders, colors, etc.
We can accomplish by limiting certain tags (like the evil “font” tag), running operations on the output markup to ensure a base level of acceptability, and outsourcing visual information to pre-defined CSS classes that are applied at the block level wherever possible. Ideally the editor could even be aware of the block-level context and provide only those styles which are appropriate to that block type (for example table styles for tables, list styles for lists, etc). By constraining users’ choices intelligently we make it easier for the user to get things done. Furthermore, if we don’t provide clean markup then any future support for theming or alternate styles will result in extreme pain for both us and our users.
+ Semantic/Structural User-end Views
The editor should make the structure of the page transparent to our users, either by default or through a toggle (like the ¶ button in Microsoft Word). As you can see from their demo, WYMeditor does a good job of this (they clearly leave out presentational elements as they are committed to a “pure” WYSIWYM model). This level of information benefits our users because they learn to think of the web as distinct from print media and enables them to build pages that will function across themes and Deliverations without breaking.
We can accomplish a similar effect using CSS specific to the editor context that adds borders, backgrounds, margin, padding, and (vernacular) labels to the block-level elements as we determine to be appropriate.
Wiki Pages vs Collaborative Documents
As an aside, we should have the editor be somewhat context dependent. Quoting/paraphrasing an earlier comment Cholmes made on the the WYSYIWYG Wishlist: when people are in the collaborative document editing space it’d be nice if they could have access to the full range of fonts, sizes, etc. because that’s the area we want people treating it like a word processor, not the wiki pages. We’d have to discuss how we would make collaborative documents migratable to wiki docs from this perspective as well as a variety of other issues specific to the differences between these two document types.