Re: DSSSL and WYSIWYG Editing
Greg Kostello wrote:
> I find it interesting that you would assert that statement which is
> contrary to the evolution of document generation tools over the last
Evolutionary directions change. You don't have really powerful gills, do
you? =) What if someone asked you five years ago if millions of people
would be back to editing documents in text editors by 1997. You would
have thought I was nuts (so would I!). And who would have thought that
plain old ASCII email would be so popular? Only a small percentage of
the email documents I get take advantage even of the limited formatting
available in many modern email programs.
I don't believe that that particular devolution will last forever but it
isn't at all clear to me that the next big document UI paradigm will be
the same as the last one.
> As computers and software has become more powerful, document
> authoring tools have become more and more WYSIWYG. Sure some people want
> to be able to edit in draft mode, but people now always have the option
> of editing in full WYSIWYG mode.
I'm not arguing that that option should ever be removed. But the more
complicated documents become the less people will be *interested* in
wasting screen real estate with headers, footers and generated tables of
contents. And despite all of the research and usability testing WYSIWYG
editing is still *hard*. I've spent many hours "debugging" lists that
misnumbered themselves, margins that extend too far or not far enough
> While the tech-doc market may require
> function over form, the office-document market has moved in the opposite
Offices that emphasize form for internal-use documents will eventually
put themselves out of business.
> IMHO, if DSSSL moves in a direction which precludes the ability to
> easily and efficiently author in a WYSIWYG mode, then I believe in is
> unlikely to be adopted.
DSSSL was designed with WYSIWYG in mind. You can make DSSSL stylesheets
that do not look very WYSIWYG until the generated text is generated but
the same holds of standard wordprocessors.
> There are ways to give users visual cues to changes in structure. For
> example, section break is used in Word and a visual component can be
> displayed if desired.
Then you are moving away from WYSIWYG. What you've got now is What You
See Is More Than What You Get.
> I have been around long enough to remember when people said that images
> could not and should not be shown in a editor. They are too inefficient
> and they get in the way. Nor should we show different fonts, nor
> multiple columns, nor fractional point fonts, headers, footer, etc.,
> etc. Now, of course, these are standard features on modern word
> processors. IMHO, this is a step forward, not a step backwards.
I agree. But the *next step forward* will be to make much of that stuff
increasingly optional and decreasingly "in your face" while you are
authoring. Images are content so they should usually be displayed. Many
other things you mention are powerful visual cues to structure and
should usually be displayed. A lot of other stuff should be relegated to
In other words WYSIWYG should be delegated from a user model to a
metaphor and must be combined with other metaphors (such as three
dimensional steps representing element nesting, the "tag" metaphor, tree
and web metaphors) to emphasize structure and efficiency over form.
There will always be a minority of the population for whom form is most
important, of course, the designers, typographers etc. Even they will
probably switch modes when they are working on medium sized documents
where structure, links etc. are important.