home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / text / frame / 2427 < prev    next >
Encoding:
Text File  |  1992-07-22  |  5.0 KB  |  112 lines
  1. Newsgroups: comp.text.frame
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!oakhill!oakhill!hamm
  3. From: hamm@austoto.sps.mot.com (Steve Hamm)
  4. Subject: Re: Troff vs FrameMaker Productivity
  5. In-Reply-To: russ@druhi.ATT.COM's message of 21 Jul 92 16:37:32 GMT
  6. Message-ID: <HAMM.92Jul22094612@toto.austoto.sps.mot.com>
  7. Sender: news@oakhill.sps.mot.com
  8. Nntp-Posting-Host: toto
  9. Reply-To: hamm@ssdt-bluestein.sps.mot.com (Steve Hamm)
  10. Organization: Motorola SPS, Austin, TX
  11. References: <18486@drutx.ATT.COM>
  12. Date: 22 Jul 92 09:46:12
  13. Lines: 97
  14.  
  15.  
  16. ---On 21 Jul 92 16:37:32 GMT, russ@druhi.ATT.COM (RauhauserR) said:
  17.  
  18. Russ> Has anyone collected hard data on how much more "productive" a
  19. Russ> writer is with FrameMaker as opposed to troff?
  20.  
  21. Russ> Even if you're lacking hard data, but do have experience in this
  22. Russ> area, I wonder if you'd be willing to offer an estimated figure
  23. Russ> for productivity increase?  Any input, using any basis of
  24. Russ> reasoning, would be gratefully appreciated.
  25.  
  26. I love it.  Even posted from ATT.COM.  Heh heh.  Some time ago, there
  27. was a posting (from someone else with an att.com address) in
  28. comp.text, in response to the question "Why isn't there a WYSIWYG
  29. troff?"  The answer is interesting, and applies to your question as
  30. well.  There isn't a WYSIWYG troff because, as a part of Documenter's
  31. Workbench, it would be a productivity loss.  Likewise, with FrameMaker,
  32. I would assume the same results apply.  
  33.  
  34. The question, then, is, "How much *less* productive is FrameMaker than
  35. troff?" (Or any other markup language, for that matter, for the purpose
  36. of producing documentation.)
  37.  
  38. I attach a copy of the original posting for your perusal.
  39.  
  40. =-=-=-=-=-=-=-==-=-=--==-=-=-=-=-=-=-=-=-==-=-=--==-=-=-=-=-=-=-=-=-==-=
  41. From: npn@cbnewsl.cb.att.com (nils-peter.nelson)
  42. Newsgroups: comp.text
  43. Subject: Why We Didn't Give You WYSIWYG troff
  44. Date: 2 Aug 91 21:34:30 GMT
  45. Organization: AT&T Bell Laboratories
  46.  
  47.  
  48. I've resisted responding up until now to the question
  49. "Does anyone know of a WYSIWYG troff?" but guess I
  50. owe the world an explanation, as far as Bell Labs
  51. is concerned.
  52. First, making the current troff WYSIWYG is technically
  53. infeasible, due to the way it buffer up text internally,
  54. then spits out when it sees fit.
  55. Something that is new, but generates troff as output is
  56. feasible, and there is a program called snaz internally
  57. in Bell Labs that more or less does this. It was designed
  58. for the Blit/5620/630/730 terminals.
  59. But the *real* reason is...
  60. A while ago a large internal documentation organization
  61. inside AT&T had a shoot-out between troff and one of the
  62. well-known Unix WYSIWYG formatters on a Sun 3. Two different,
  63. trained groups were given a large document to produce,
  64. one with troff, the other with WYSIWYG. The troff group
  65. finished substantially ahead.  The experiment was deemed
  66. a failure (since it was supposed to show WYSIWYG improved
  67. productivity) and repeated. Same result.
  68. Subsequent analysis indicated that the WYSIWYG group spent
  69. a lot of time "prettying" up layout at an early stage
  70. of authoring; a good deal of this effort was undone by
  71. subsequent changes to the text.   The troff group was more
  72. or less forbidden to address layout; they used an
  73. SGML-flavored set of macros, based on -mm, that automatically
  74. determined fonts, header placement, page breaks, etc.
  75. The credit goes, really, not to troff, but to a well-defined
  76. batch markup language that allows authors to concentrate
  77. on *content* and leave layout to the software.
  78.  
  79. Given this fact, and that for those who really want WYSIWYG
  80. there are some 50 commercial alternatives, we elected not
  81. to pursue WYSIWYG troff.  Instead, we capitalize on windowing
  82. systems (layers, mux or X) to do screen-based editing of
  83. batch troff in one window, with troff output in another
  84. window.  This gives the "in-the-office" feedback authors need
  85. without true WYSIWYG. (Rick Beach of Xerox described this
  86. difference cogently in Science several years ago.) The software
  87. here is proof/xproof and xtv (based on xditview).
  88.  
  89. We did, as you may know, do a WYSIWYG pic, called Picasso,
  90. because drawing is exactly the opposite case-- for
  91. most illustrations object placement is easy and natural
  92. in WYSIWYG, awkward in batch. But our conclusion for text
  93. was: let the software determine the layout, not the
  94. author.  An intentional result of this is a very
  95. consistent document appearance across geographically
  96. disparate groups. (Style is not as easy to enforce with
  97. WYSIWYG systems.)
  98.  
  99. I'd enjoy seeing responses, since this is an important
  100. issue to all of us.  Lest I be misconstrued, there is
  101. no doubt that WYSIWYG is more productive for advertising
  102. layout, for pictures, and anytime form is more important
  103. than content.  But for the sort of industrial-strength
  104. documentation we do at AT&T, batch markup languages
  105. appear to have an advantage.
  106.  
  107. --
  108. Steve Hamm ------  Motorola Inc. Semiconductor Systems Design Technology
  109.                    3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
  110. Ph:  512-928-6612  Internet:  hamm@ssdt-bluestein.sps.mot.com   
  111. Fax: 512-928-7662  UUCP:      ...cs.utexas.edu!oakhill!austoto!hamm
  112.