Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site glacier.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!glacier!reid
From: reid@glacier.ARPA (Brian Reid)
Newsgroups: net.text
Subject: Re: WYSIWYG
Message-ID: <2592@glacier.ARPA>
Date: Sun, 22-Dec-85 15:48:04 EST
Article-I.D.: glacier.2592
Posted: Sun Dec 22 15:48:04 1985
Date-Received: Wed, 25-Dec-85 00:58:39 EST
Reply-To: reid@su-glacier.ARPA (Brian Reid)
Organization: Stanford University, Computer Systems Lab
Lines: 83

Whoa. Chuq tells me that what I say is not an argument. That's true. It was
an explanation. Never once have I claimed that people who use WYSIWYG
systems are wrong or stupid or immoral, or at least more so than people who
don't. What I have done is offered several claims that WYSIWYG systems are
NOT the way of the future, and specifically that they are not an improvement
over earlier ways of doing things. WYSIWYG systems do provide functionality
that was not present in compiler-model systems, but they do so at the cost
of omitting significant other capabilities.


WYSIWYG systems are better for these kinds of things:

  * Situations where the author has responsibility for the design and
appearance of the final document.

  * Situations where the details of the appearance are an important part of
the presentation, and must therefore be considered in conjunction with the
content (e.g. advertisements, bulletin boards, signs).

  * Material that is unlikely to be re-used or re-published in a different
format than it is currently being produced in.

  * Documents whose structure is not important, or at least where it is
unlikely to change much if it is important.


Compiler-model systems are better for these kinds of things:

  * Situations where someone besides author has responsibility for the
design and appearance of the final document, especially if the author has
opinions in this area and might try to manipulate the appearance anyhow.

  * Situations where the details of the appearance are secondary, and the
content is the primary means of communication (e.g. textbooks, memoranda)

  * Material that is likely to be re-used in a different format or context.
For example, a paper that you are writing could become a chapter in a book
or an appendix in a research proposal. It would be unfortunate to have to
edit the paper just to change its appearance to the new format.

  * Documents where structure is important, or where the structure is likely
to change significantly during the life of the document. For example, if you
move three sections from Chapter 2 to Chapter 7, will they automatically
renumber themselves from 2.4, 2.5, and 2.6 into 7.1, 7.2, and 7.3, or will
somebody have to do that by hand? If the Preface says "Please see Chapter 2
for details" and then somebody moves those details to Chapter 7, will the
Preface automatically change to read "Please see Chapter 7 for details"?
Compiler-model systems can do things like that easily; WYSIWYG systems in
general cannot.

Now, there are different compiler-model systems around. On this UNIX net we
like to talk about Troff, Scribe, and TeX. There is also IBM's GML, and
their idiotic "generalization" of it called SGML that IBM is trying to push
as an international standard (and succeeding, alas, in Europe--Europeans
really like SGML). There is IBM Script and Waterloo Script and Univac DPS
and Montreal's Compo and UBC's Texture and III's PageIII. Xerox has a
bizarre and wonderful language called Interscript.  There are dozens and
dozens more. 

Arguments about WYSIWYG vs. compiler-model systems are not equivalent to
arguments about whether "make that word be italic" or "\fIword\fR" is the
right way to ask for an italic word. There certainly is a language issue, of
what is the best way to record the appearance-independent properties of
documents, that is important, and that they WYSIWYG people ignore
completely.

In 1975-76 I took my best ideas for how to do this and encapsulated them in
Scribe; it hasn't changed much since then. My ideas have. Ignoring whether
or not there are bugs in the Scribe compiler, or in the Unilogic scribe
compiler (Mark of the Unicorn isn't allowed to call theirs Scribe or they
will get sued, but it is roughly the same language), I claim that still, 10
years later, the Scribe document representation language, and its imitators
such as LaTeX and Final Word and Perfect Writer, are one of the best schemes
for representing documents. Perhaps my original compiler for this language
is not the world's best formatting compiler, but it more or less works.
We're not discussing compilers, though, we're discussing paradigms, and the
"document as abstract language" paradigm, as represented by Scribe, LaTex,
Final Word, Perfect Writer, is alive and well and useful. It's time for
somebody to design a newer better abstract document language and write a
good compiler for it.
-- 
	Brian Reid	decwrl!glacier!reid
	Stanford	reid@SU-Glacier.ARPA