I'll preface this by confessing that I am very comfortable with plain text editors and intuitively appreciate the difference between content, structure, references and decoration/style/appearance. No doubt this mindset is the product of using the only available editors at the time: ed (plus nroff for output), then emacs made life easier, then ghostscript made it harder again so that ghostview could made it prettier, then scribe and then ... et cetera et cetera.

  • I appreciate that not everyone ran the same gauntlet or is wired the same way .. vive la différence!

My recent test drive of the new RTE made me a little more aware of the different approaches to document creation. So much so that on a visit to Wikipedia today a reference link caught my eye and prompted me to save and read a PDF document on WYSIWYG versus WYSIWYM by Christoph Sauer, 5. August 2006 What you see is Wiki.pdf

Clearly the author is an advocate of Wikitext who laments our failure to adopt a universal standard for wiki markup.

It is a very good read and helped crystallize in my mind some of the reasons for the different opinions of RTE vs. PTE.
I am now very interested to read other papers presenting alternative points of view on this subject. So if you know some good links then please share them here.

Memorable remarks and/or citations include (in order of appearance)
bold and underline highlighting added

  • A Canadian study among 4th grade students (age 8 to 9) showed that indeed wiki markup can even be used by children after a 15 minute introduction [Désilets 06].

  • Not only has the medium changed, but also our habits are changing how we consume and produce content. More and more people become knowledge workers that surf the web to gather information and remix text to create new documents containing information, ideas and concepts at a rapidly growing rate. Those knowledge workers, bloggers for example, often copy and paste code. If you write a larger document in this way from several authors you might have to reformat everything, and you will have to spend a lot of time doing this. Those users are however concentrating on the content and have no time to care for layout while writing. WYSIWYG is not useful for them anymore.

  • The entire section on :

The Essence of a Document

One year before Lesley Lamport in 1986, Fred Brooks published his well know essay called "There is no Silver bullet: Accidents and Essence of Software engineering" [Brooks 86]. He predicted that we would see no advances of scale in programming until we separate accidental task from the essential tasks - and the essence is, as he writes, what is the same in many different representations.
If we transfer this to web authoring the accidental tasks are the format, because it will change in different representations. Whereas the essence, that is the same in many different representations, is the content itself plus its emphasis through structure and references. Structure is represented by headings, bold, italics, etc. while links to other documents and web pages make up the references.
This means that wiki markup is part of the essence of a document--what the author wanted to preserve as a document in order to convey his ideas to the reader.

As a design pattern in software development we know this notion as model view pattern. People that edit in a WYSIWYG editor do not sense this distinction. What we need is a new computer literacy where people are aware of this distinction. Teaching people the difference between model and view with the help of wiki markup in their basic education would produce huge productivity gains in document production.

Somewhere along the way these two ideas crystallized:

  1. Rather than insulating new contributors from wiki markup, the tool delivering a kinder, gentler introduction to editing at Wikia should strive to educate new users on the relative ease with which Wikitext allows style to be applied to content.
    In other words a user ought to be encouraged (via the editor) to discover for them self that editing in Wikitext is very productive and nowhere near as scary as they may have first thought.
  2. Rather than a single window that attempts to cater to two separate phases of the article creation process consider two windows where one or the other is chosen based on which phase the user next "intends to" engage in. Let those two windows be visible above/below one another so that a user cannot help but become educated in the proper use of Wikitext.
    • When the user intends to enter content they use the content window - a WYSIWYM editor
      e.g. much like the primary input window that we use today - regardless of our choice of RTE or PTE
    • When the user intends to apply or fine-tune appearance/style/decoration they use the styling window - a WYSIWYG editor
      e.g. that might closely resemble the preview that we use today - regardless of our choice of RTE or PTE

With the two-window editor idea the cause and effect relationship between markup and rendered result is being taught to the user.

1. While a user is predominantly working in the style window they are able to see in almost real-time the underlying Wikitext and/or HTML that their activity applying and tweaking styles (and optional insertion/deletion of text) is generating.

Why do this?
Because eventually those novice wiki users are going to need to look at a page of Wikitext and yet not be intimidated by it.

2. Users who predominantly work in the content window are able to see a rendered preview of their content in almost real-time but they should also be given the option of turning off that real-time preview especially if it is slowing down the speed with which the essence of an article is being entered and saved. i.e. just like today's preview is triggered by the click of a button.

  • While content is being typed into the content window that same content is being rendered in the style window.
  • While styles are being applied or tweaked via the style window the Wikitext and/or HTML markup that creates those styles is being inserted into the content window - albeit in some feint colored font that allows the content text to stand out from the style annotations.
  • Of course a user who knows the styling Wikitext or HTML code should be free to type that into the content window and that styling should be rendered faithfully in the style window at the same time it is being converted to some inconspicuous font in the content window.
  • Conversely when a user is primarily applying styles in the style window they should be able to click a "select text/insert text" toolbar button to allow on-the-fly edits (perhaps to correct typos or omissions or to add entire blocks of text) those edits should faithfully appear in the content window.

With this dual but separate focus on what a "Wiki editor intends to do" maybe we can have yet another Intenddo WE product in our lives!  :-)