[Pmwiki-users] WikiEditor

[Patrick R. Michaud]

BTW, my previous message should not be interpreted to discourage others
from developing add-ons or contributions to PmWiki.  I'm definitely
interested in improving PmWiki, and I'm very impressed with the 
WikiEditor that James is creating.  I sincerely compliment him on
the work he's doing and hope he will continue development on it
or something like it.

My purpose in the previous message was simply to contribute my own
experiences with document authoring systems, and hopefully allow us
to avoid some of the "failures" I've perceived in existing document
authoring systems that prompted me to use wiki (and create PmWiki)
in the first place.

Pm


On Thu, 24 Oct 2002, Patrick R. Michaud wrote:

> 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
> 
> 
> _______________________________________________
> Pmwiki-users mailing list
> Pmwiki-users at pmichaud.com
> http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com
>