Patrick R. Michaud
pmichaud at sci.tamucc.edu
Thu Oct 24 19:41:32 CDT 2002
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
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.
More information about the pmwiki-users