[Pmwiki-users] WikiEditor

Davis, James C. jdavis at cob.tamucc.edu
Fri Oct 25 10:47:11 CDT 2002

> 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 agree that wiki can't be compared to a word processor, but incorporating
some features of a word processor would make it more familiar and possibly
would encourage its use. I'll admit that even I wished it had a spell
checker sometimes, and I have even cut and pasted text into Word to run
spell check. A spell checker would probably have to be a server side add-on
because sending an entire dictionary file to the client is probably not
something you would want to do.

> 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:

I agree. I have been frustrated by this for some time and the best HTML
editor I have found so far is vi (well, it's the best editor for anything
text-based, and it makes you code pretty colors, and gVim on Windows is
cool). The only WYSIWYG editor that comes close is Dreamweaver, but I
usually find myself editing the HTML and using split screen to preview the
page as I edit it.

>   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.

Yeah, I would have to agree with this as well. I have been a web developer
long enough to know that "browser standards" is an oxymoron. Another
approach is browser detection and only displaying the editor only for
browsers that will support it.

>   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
>       at least not cleanly or without loss of information.  The same is 
>       true for word processors--e.g., Word and WordPerfect.

This is very true. Word does a horrible job (in my opinion) of converting
documents to HTML. Wiki, however, has the potential of being different if it
has a clearly defined standard that is adhered to closely.

>   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),
>          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.)

Here is where I have another idea. What about a dynamic editor that can
adapt to changes in the underlying markup language? If the editor is
integrated into the system as it is with wiki, it can be written so that it
will know about any changes to the markup language. WikiEditor does some of
this already because many of the regular expression patterns are not defined
statically in the JavaScript code, but are inserted dynamically using php
variables defined in PmWiki. Maybe PmWiki could work off of some sort of
grammar file that defines all markup and its HTML equivalent. Then editors
could also use this file in the same way. Any local add-ons (such as "Q:"
and "A:") could be put in another file and included (similar to local.php).

On a side note: When are we going to see client-side perl widely supported
in browsers? JavaScript is sometimes a royal pain in the @$$.

> 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

I think I will abandon the idea of hiding the markup. I think it would be
beneficial for people to learn markup anyways as it is almost always faster
to edit the markup than WYSIWYG (once you learn it). I still, however, think
that real-time previewing would be useful if it can be dynamic and actually
be a true preview. I don't know if anyone else ever got WikiEditor to work,
but when it does it updates the preview with each keystroke. I think this
would be a great tool for people who are new to wiki and trying to learn the
markup. Even for veteran wikiers, I think being able to see the page in its
rendered form, exactly as it will appear in your browser, would be nice.
This is more useful, I guess, for people or organizations who are using wiki
for actual web sites rather than just for collaboration. I know that this
was not the original intent for wiki, but I believe in exploiting technology
to the fullest extent. I will continue to work on this project and attempt
to make it as cross-browser and platform independent as possible. Thank you
for your comments.

James Davis

More information about the pmwiki-users mailing list