From: hamm@austoto.sps.mot.com (Steve Hamm)
Subject: Re: Troff vs FrameMaker Productivity
Reply-To: hamm@ssdt-bluestein.sps.mot.com (Steve Hamm)
Organization: Motorola SPS, Austin, TX
Date: 22 Jul 92 09:46:12


---On 21 Jul 92 16:37:32 GMT, russ@druhi.ATT.COM (RauhauserR) said:

Russ> Has anyone collected hard data on how much more "productive" a
Russ> writer is with FrameMaker as opposed to troff?

Russ> Even if you're lacking hard data, but do have experience in this
Russ> area, I wonder if you'd be willing to offer an estimated figure
Russ> for productivity increase?  Any input, using any basis of
Russ> reasoning, would be gratefully appreciated.

I love it.  Even posted from ATT.COM.  Heh heh.  Some time ago, there
was a posting (from someone else with an att.com address) in
comp.text, in response to the question "Why isn't there a WYSIWYG
troff?"  The answer is interesting, and applies to your question as
well.  There isn't a WYSIWYG troff because, as a part of Documenter's
Workbench, it would be a productivity loss.  Likewise, with FrameMaker,
I would assume the same results apply.  

The question, then, is, "How much *less* productive is FrameMaker than
troff?" (Or any other markup language, for that matter, for the purpose
of producing documentation.)

I attach a copy of the original posting for your perusal.

=-=-=-=-=-=-=-==-=-=--==-=-=-=-=-=-=-=-=-==-=-=--==-=-=-=-=-=-=-=-=-==-=
From: npn@cbnewsl.cb.att.com (nils-peter.nelson)
Newsgroups: comp.text
Subject: Why We Didn't Give You WYSIWYG troff
Date: 2 Aug 91 21:34:30 GMT
Organization: AT&T Bell Laboratories


I've resisted responding up until now to the question
"Does anyone know of a WYSIWYG troff?" but guess I
owe the world an explanation, as far as Bell Labs
is concerned.
First, making the current troff WYSIWYG is technically
infeasible, due to the way it buffer up text internally,
then spits out when it sees fit.
Something that is new, but generates troff as output is
feasible, and there is a program called snaz internally
in Bell Labs that more or less does this. It was designed
for the Blit/5620/630/730 terminals.
But the *real* reason is...
A while ago a large internal documentation organization
inside AT&T had a shoot-out between troff and one of the
well-known Unix WYSIWYG formatters on a Sun 3. Two different,
trained groups were given a large document to produce,
one with troff, the other with WYSIWYG. The troff group
finished substantially ahead.  The experiment was deemed
a failure (since it was supposed to show WYSIWYG improved
productivity) and repeated. Same result.
Subsequent analysis indicated that the WYSIWYG group spent
a lot of time "prettying" up layout at an early stage
of authoring; a good deal of this effort was undone by
subsequent changes to the text.   The troff group was more
or less forbidden to address layout; they used an
SGML-flavored set of macros, based on -mm, that automatically
determined fonts, header placement, page breaks, etc.
The credit goes, really, not to troff, but to a well-defined
batch markup language that allows authors to concentrate
on *content* and leave layout to the software.

Given this fact, and that for those who really want WYSIWYG
there are some 50 commercial alternatives, we elected not
to pursue WYSIWYG troff.  Instead, we capitalize on windowing
systems (layers, mux or X) to do screen-based editing of
batch troff in one window, with troff output in another
window.  This gives the "in-the-office" feedback authors need
without true WYSIWYG. (Rick Beach of Xerox described this
difference cogently in Science several years ago.) The software
here is proof/xproof and xtv (based on xditview).

We did, as you may know, do a WYSIWYG pic, called Picasso,
because drawing is exactly the opposite case-- for
most illustrations object placement is easy and natural
in WYSIWYG, awkward in batch. But our conclusion for text
was: let the software determine the layout, not the
author.  An intentional result of this is a very
consistent document appearance across geographically
disparate groups. (Style is not as easy to enforce with
WYSIWYG systems.)

I'd enjoy seeing responses, since this is an important
issue to all of us.  Lest I be misconstrued, there is
no doubt that WYSIWYG is more productive for advertising
layout, for pictures, and anytime form is more important
than content.  But for the sort of industrial-strength
documentation we do at AT&T, batch markup languages
appear to have an advantage.

--
Steve Hamm ------  Motorola Inc. Semiconductor Systems Design Technology
                   3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph:  512-928-6612  Internet:  hamm@ssdt-bluestein.sps.mot.com   
Fax: 512-928-7662  UUCP:      ...cs.utexas.edu!oakhill!austoto!hamm
Newsgroups: comp.text.frame