1.18 Wikitext vs. WYSIWYG
Wikitext is not a standard, and there are multiple implementations of wikitext, nevertheless, there are some common characteristics of wikitext worth pointing out.
Wikitext was born of a need to allow writers to be able to easily create links to other pages, and to apply basic formatting to pages edited through a Web browser. Wikitext is a markup language. The through-the-web requirement meant that the user did not have the benefit of a WYSIWYG interface.
The benefits of a wikitext editing interface are:
Low barriers to entry; everybody with a browser can edit with it.
It (presumably) gives the author more control over the writing process.
WYSIWYG editors give authors too much flexibility (something that seems to be most often exploited by those authors who are design-impaired, leading to a tossed salad of fonts and colors without any consistent semantic meaning).
In my experience, WYSIWYG editors do a lousy job of making it easy to link to different pages within the wiki. There really isn't an easier way of doing it than that used by wikis, which usually involves the simple wrapping of a page title with doublebrackets like so: [[A Title of a Wiki Page]].
The negatives are:
Users almost universally prefer WYSIWYG editors, because they are more familiar with them.
The lack of syntax highlighting makes wikitext hard to read. You cannot easily scan for section headings, for example.
Companies control the browsers employees use, so the browser limitations can be mitigated.
An excellent discussion of this topic can be found on CMSWatch.
There are three different approaches to resolving the editing problem:
Wikitext (or some other text-oriented markup language like Textile, Markdown, etc.
WYSIWYG interfaces, like those used in word processors.
Syntax highlighting, similar to what is used by software programmers in Integrated Development Environments (IDEs). This posting is written with a software application that uses the syntax highlighting approach. You get the benefit of visual feedback as you type, but you also have absolute control over the HTML that gets generated.
Writers have a lot to learn from software developers.
The biggest problem with WYSIWYG interfaces is that it links the visual design of a site with the content in an environment where the separation of content from design is seen as an asset. Because content published online can be viewed in multiple browsers on a variety of different platforms (from cell phones to televisions to 50 inch plasma television screens), the WYSIWYG interface does not really provide the author with meaningful information. In fact, it might even shield the author from important structural issues that are not apparent when the "page" on the computer screen is supposed to be an accurate representation of the expression of that page on paper.
Philosophically speaking, markup used in HTML should be semantically meaningful; references to visual representations are resisted. For example, the HTML element "strong" is prefered to the HTML element "b". Both elements are displayed in bold, but the use of "strong" explicitly states that the author wants to provide a strong emphasis to this word, whereas the use of "b" only makes that information implicit, and all you know for certain is that the author wanted to make the word bold - perhaps for purely aesthetic reasons.
The reason for this distinction is that content will appear on different platforms, now and in the future, and there may be different visual representations of the same idea of "strong emphasis" used on those platforms. For example, how does one render a bold word when read by a screen reader application intended for the visually impaired? It is much easier to imagine a screen reader strongly emphasizing a word or phrase, however, by changing the one of the voice.
Atom feed
