NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/text/frame/2446

Internet Message Format | 1992-07-23 | 6.1 KB

Path: sparky!uunet!stanford.edu!agate!elmer-fudd.cs.berkeley.edu!konstan
From: [e-mail] (Joe Konstan)
Newsgroups: comp.text.frame
Subject: Re: Troff vs FrameMaker Productivity
Date: 23 Jul 1992 22:48:01 GMT
Organization: Picasso Research Group, UCB Computer Science Division
Lines: 108
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: elmer-fudd.cs.berkeley.edu

In article <[e-mail]>, [e-mail] (Randal L. Schwartz) writes:
|> regarding the AT&T memo:
|>
|> this exactly fits my experiences as a technical author for the past 15 years.
|>
|> A WYSIWYG is great for 1-up posters and small documents, but the
|> moment something gets to be over 20 pages long or written by more than
|> one author or maintained over time, you lose -- in a major way.

I agree that WYSIWYG is especially good for 1-ups and small docs, but I also
think, that with no more planning than is necessary in a troff-like system, it
can also do a very good job on large documents with multiple authors.

|> Case in point:
|>
|> I co-wrote "Programming Perl" (from O'Reilly and Associates) with
|> Larry Wall (the creator of the Perl language).  We were 1000 miles
|> apart for all but the signing party at its debut.  Yet we achieved
|> clean solid seamless merging of our respective texts because I was
|> able to provide a limited troff macro package that forced us to focus
|> on the writing and not the representation.

You can, and in my opinion should, do the same thing with Framemaker.  I
recall the initial design sessions for the Picasso user manuals (which were
done in troff, but have been (or are being) converted to Framemaker).  Many
days were spent deciding exactly what (semantically) was a chapter, function
block, macro block, subheading, etc., and then writing macros to handle them.
The same could have been done (I believe much more easily) with Framemaker.

And, if you are concerned about people wasting time and getting cute (a
reasonable concern) you can impose the rule that no formats (at all) be
changed by a single writer.  Frame can even enforce this by having you
"use formats" from the standards document.

|> Now, I face a similar challenge on its sequel (tentatively titled
|> "Learning Perl"), but with FrameMaker (on a Mac) rather than troff
|> (all of OR&A's books are being done in Frame these days).  My
|> experience so far has been that the process is *much* slower, because
|> I have to keep thinking about design issues.  And I haven't even
|> *begun* the phase of the work that will involve collaberation, but

You must have handles the design issues in troff as well, but the difference
was that you may have already done a design once before (the benefit of
experience) and/or you were more comfortable there.  My first 10-12 documents
in Frame were a pain as I had to relearn how to design a document
template.

|> For example, sometimes I'd send a piece of troff text to larry.  He'd
|> edit it, and send me back the edited version.  I'd simply run that
|> through diff (even if I had changed the draft in the meanwhile), and
|> boom, there's the parts he changed.  Way too easy to merge!  Try
|> *that* with a Frame doc!

Perhaps, but:

    a)  Frame has features such as automatic change bars that are,
        for me at least, far more useful, and

    b)  For the "diff" solution to work, you'd have to have agreed on
        a whole bunch of line management standards, or you'd just be
        adding in his changes by hand (just as easy with change bars).

|> And I could also send the doc to others.  Troff is nearly universal
|> now that there's a GNU -roff.  And even if they didn't want to format
|> it, the source text is recognizable even with the embedded formatting
|> controls.  MIF?  You've got to be kidding.

Postscript is more universal than troff, and Framemaker still has the
advantage of running on Macs, PC's, etc.  Of course, if you are writing a
book on perl, troff is more universal than Frame, but the PC/Mac market is
huge.  Also, it is much easier to convert from other WP programs (Word, etc.)
to Frame.  MIF isn't designed to be used for marked-up text.  MML or one
of the "rich text" formats would make more sense, but I think postscript
or just plain "save as text" would be better.

|> I'm not even going to bring up what the performance differences are
|> for me between a good command-line interface that I can layer with
|> scripts, and a stoopid point-and-shoot mac-type luser interface.

Perhaps then I shouldn't bring up the performance benefits of keyboard macros,
function keys, etc., along with the fact that I almost never (if Frame fixed
a few of the mouse focus bugs then never at all) really need to use the mouse
except for drawing--something troff isn't very good at.  Also, I won't mention
the flexibility of being able to write "shell scripts" to run agains Frame
files in batch mode to handle all sorts of fancy things.

|> Grumph.  "Learning Perl" is going to be a tough project.  Down with
|> WYSIWYGs for big things!
|>
|> Just another Perl (and Frame) hacker,

Learning Framemaker is also a tough project.  But I think, if you stick with
it for a while, you'll find that it is a powerful enough system to handle big
things and will eventually boost productivity above the troff level.

A final note about the temptation to focus on form over content.  I'm quite
familiar with that as a former college computer magazing publisher working
with Pagemaker 1.0 on small-screen Macs.  We once put out a 48 page (tabloid)
issue which would fairly be described as playing with graphics (from ads to
break out quotes).  But, even then, we realized that a reasonable compromise
was to have authors submit text in any computer readable form (as little
formatting as possible) and then we'd do the layout separately.  Perhaps the
lesson for Frame, troff, etc. for large projects is to let the graphics people
define the formats, and have the authors just write--whether it is in Frame or
troff directly, or in vi or emacs.

Joe Konstan
[e-mail]