Re: Odd survey explained

[Matthew Flynn <maflynn -at- DTTUS -dot- COM>]

     An interesting statement here.  I think Mr. Bonney overlooks a few
     points:

     1.  Choosing a software package generally requires a nontrivial cash
         outlay.  As such, writers frequently use this list as a reference
         to justify their choice of tools to their bosses.

     2.  I have frequently seen postings on usability studies, readability
         issues, documentation standards, and other audience related issues
         on this forum.  To say that TCs focus too much on software
         solutions is incorrect.  I've never seen a post here suggesting
         that technology is going to design and write their manuals for
         them.

     3.  If you want every manual to look the same, try using the military
         specs.  You end up with manuals that are consistantly organized,
         but invariably disliked by readers (my apologies to those TCs
         writing MILSPEC).

         Form should serve the function of a manual, but "function" can
         vary widely.  I write documentation for tax-related software whose
         primary audience consists of accountants and tax consultants.  As
         such, I try to present my material in a way that is most
         accessable to such an audience.  If I was doc-ing a graphics
         app for artists or a development kit for C++ programmers, I would
         approach these projects differently as well.  The organization
         changes according to the product type and the audience type.  Take
         a look at the third-party books available at your local
         bookstore--they vary widely in organization and design, and still
         are be extremely popular and useful to users of varying tastes and
         needs.

         If you accept this as true, you should see why it is difficult to
         have general conversations of "methodologies" in a forum such as
         this one.  "Technical writers" write about an incredible variety
         of subjects (from washing machines to word processors) for an
         incredible variety of audiences.  To expect them all to use the
         same methodology, and expect audiences to appreciate the result,
         is not reasonable.

         What it all comes down to is that designing documentation is an
         art and not a science.

     4.  Methodologies for other tasks (application development, for
         example) vary widely throughout their respective industries, and
         their application is almost never 100% enforced.  Take a look at
         the variety of ways OOP is implemented, for example, and the
         variety evident in its results.  Sometimes it works, sometimes it
         doesn't.  This is not to say that OOP methodologies are useless,
         just that they are only a template which is built upon.

     5.  If you want to improve the quality of documentation, give writers
         more time AFTER the product they are documenting is complete and
         stable.  Too often we are expected to have documentation done and
         to the printers before the product itself is fit to sell.  It is
         little wonder that it is flawed in such situations.


     Cheers,
     Matthew Flynn                              mailto:maflynn -at- dttus -dot- com
     Technical Writer                           insert:standard disclaimer
     Deloitte & Touche Tax Technologies LLC



______________________________ Reply Separator _________________________________
Subject: Odd survey explained
Author:  don -dot- sargent -at- TEMPLATE -dot- COM at INTERNET-USA
Date:    7/28/97 12:05 PM

[Jack Bonney writes:]

"technical writers" have unreasonably placed their faith in software
packages --  to wit: review all the information and discussion on which
software package to use or to avoid, their features, etc.

nothing exists that resembles a methodology, rather, most discussion
centers around "style" as if every manual should be different for some
unspecified reason --  in fact, there is an annual contest at the
university of waterloo that gives merit for "best looking manual".



--
Don Sargent
Template Software, Inc.       "I might only get three strikes in
Dulles, Virginia             life, but I can hit foul indefinitely."
sargent -at- template -dot- com                       -- me

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html