[Pmwiki-users] WikiEditor

[Patrick R. Michaud]

On Thu, 24 Oct 2002, Davis, James C. wrote:

> That's actuallly what I am trying to do. Ideally it would be a WYSIWYG
> editor so that authors wouldn't have to deal with ANY markup. 
> ... I would like to make
> authoring web pages as easy as authoring a document in Word, I just have to
> play around with different technologies some more until I find something
> that will work.

An interesting side note:  One of the most frequent comments I hear from
people (often management types) who are exposed to wiki for the first
time is:  "Where's the spell-check button?"  While this is sometimes
a humorous comment, it's also indicative that many times people try
to understand new technologies in terms of familiar ones, and sometimes
the comparison isn't a good one to make.

I think there's a lot to be learned from the lack of good HTML-based
WYSIWYG editors (including Word), and about the concept of WYSIWYG in 
general.  Some thoughts:
  1.  The lack of browser standards means that it will be nearly 
      impossible to create a decent WYSIWYG editor for any web 
      environment.  All that is really possible for now is GUI-based 
      editors to simplify the process, but not WYSIWYG ones that can 
      hide the markup altogether.
  2.  The problem gets much tougher when you are talking about web-based
      *collaboration* systems (such as wiki) as opposed to web *authoring* 
      systems, because in a collaborative environment the editors have to
      be compatible with browsers AND with other editors.  For example, 
      observe that HTML documents created by Microsoft Word or other 
      HTML authoring systems generally cannot be edited by any other editor, 
      at least not cleanly or without loss of information.  The same is 
      true for word processors--e.g., Word and WordPerfect.
  3.  Editors can only work when the underlying document (markup) language
      is extremely stable and widely standardized.  I.e., a GUI-based 
      editor is only good for the markup constructs it knows about--it 
      can't handle the (new) markups it doesn't.  It's left with three
      distasteful choices:  
         expose the unknown markup (markup is no longer hidden), 
         hide the unknown markup (markup is hidden but no longer WYSIWYG), or
         discard the markup (the whole document structure changes).
      By definition, GUI-based editors must cater to the lowest common 
      denominator of the markup constructs.  Consider the "Q:" and "A:" 
      markups I add to several of my wiki installations, which aren't 
      (yet?) a part of standard PmWiki.  Does an editor render these or 
      not?  If yes, how does it know about them?  If not, how does an 
      author know they're there, or to use them instead of the "bold" 
      and "indent" buttons on the toolbar?  (This is also a problem
      in HTML authoring environments, and indeed in word processing
      packages in general.)

I think that existing HTML editors and word processing
packages demonstrate how difficult it is to have multi-platform
collaboration *and* hide the underlying markup.  (Anyone want to have
WordPerfect users editing their Word documents?  How about using
Netscape Composer to edit a FrontPage document?)  Word processors
are only good for collaboration when everyone is using the same 
word processor.  Word processors can hide markup from the user 
(approach WYSIWYG) because they can precisely control how the 
document will be rendered to the final output device (the printer).  
Neither of these conditions are true for web authoring packages.

Thus, wikis take a different approach to authoring--expose the markup 
to the author, but keep the markup as non-intrusive as possible so 
that the text displayed *with its markup* looks as much as possible 
like the rendered text.  This implies an overly simplistic model for
editing, but from such simplicity comes great flexibility and power.
This is also why I strongly resist adding lots of markup capabilities, 
or using HTML markup tags in wiki documents, because it increases the
distance between the edited text and the rendered output.

I'm absolutely in favor of anything that makes authoring documents
easier, but experience tells me that hiding the markup is probably
heading in the wrong direction, at least with current web (browser)
technologies.  Perhaps a more useful approach would be to find ways
to keep the markup visible, but somehow make it less intimidating.  

Pm