They do it here where I'm the one and only writer (a contractor). (The
company designs and builds cement manufacturing plants for cement
manufacturers worldwide.)

While the company's home office in Germany has a stable of good writers
and illustrators, and produce manuals specific to the various components
that comprise a cement manufacturing plant, my books done here in
Atlanta for U.S. clients are called "operating descriptions" and are
pretty much an overview of the various prestart conditions, starting
procedures and shutdown procedures that must be in place for this or
that part of the cement plant (the raw material transport area gets a
book, as does the raw meal facility, as does the preheater & kiln area,
as does the finishing mill, etc.) The books range in length from 40 or
50 pages to 120 or so pages and also include a series of tables at the
back of the book with VERY detailed info on pressures, temps, electrical
stuff, etc. (The client gets a humongous set of binders with the various
machine manuals and vendor manuals as well as my operating
descriptions.)

I guess my books could be called "turn key manuals".

And while the machine manuals from Germany are done very well with line
art and all the rest in an attractive layout, my books are done in Word
with NO graphics or safety warnings and that's all there is to it - by
order of the manager of electrical engineering. I once did an alternate
version of one book with a few line art graphics back last spring to
show my boss the comparison, but he is totally NOT interested. He's an
engineer and doesn't see the need for anything other than what they
already had in place.

Note that previous to my being here, the electrical engineers did the
design work AND wrote the manuals. And that's the way it still is
(because there's far more work than I can do by myself). And yes, the
books done by the engineers are full of terrible grammar, typos,
complicated and hard-to-understand explanations, etc. It just doesn't
matter.

And it will go back to that way completely upon my departure.

Bottom line: do what Gary says: " . . . just dive right in and do the
best job you can."

-- Ken in Atlanta



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Thomas Johnson
Sent: Thursday, December 21, 2006 7:59 AM
To: 'Gary Robinson'; [email protected]
Subject: Re: [TCP] Graphicsless documentation

Hi Gary,

For the life of me, I can't see why anyone would want to do such a
thing.
I'd sure like to hear the rationale as well.

Sometimes it isn't worth chewing through the straps. You've been around
long enough to realize it's probably something someone read in a
management magazine as a, hairbrained-as-it-may-be, way to save a few
bucks. It'll probably come back to bite them in the end. My advice is to
just dive right in and do the best job you can. Maybe someone will come
to their senses and have you include graphics before it's too late. I
think I'd be stashing away the screen shots as I went--just in case. It
would be easy enough and true enough to say you're capturing them to use
as reference.

Have a merry Christmas everyone!
 


Tom Johnson
Technical Writer
Microline Technology Corp.
[EMAIL PROTECTED]
+1 231 935 1585
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Gary Robinson
Sent: Wednesday, December 20, 2006 10:54 PM
To: [email protected]
Subject: [TCP] Graphicsless documentation

I am authoring online help and adjunct documentation for a client.  In a
meeting with the prime contractor today I was instructed that there
should be no graphics in any of the documentation produced for the
client.  Their rationale (irrationale?) was that if the documentation
ever needed updating it would be too much work to update the graphics.
We are using a well known screen capture untility and a authoring tool
that is built to reuse every element in the documentation with ease.  I
pointed out it may take only 2 minutes a graphic to update them if
needed (these are mostly screen captures with no formatting other that
resizing and a hairline border) but to no avail.  I am allowed no
contact with the client so I can't ask them their opinion on this
directive.  Has anyone else produced graphicless documentation?  If so,
what was the rationale?  Inquiring minds, etc.

Regards,

Gary G. Robinson
Technical Communications Consultant
[EMAIL PROTECTED]


__________________________

This e-mail message and any attachment contains private
and confidential information and is intended for the addressee only.  If you 
are not the intended recipient (or responsible
for delivery of the message to such person), please do not read, copy, use or 
disclose this communication to others.
If you have received this message in error, please notify the sender by 
replying to this message, and then delete it from your system.  

Attachments: Please use our "Send us a file" link on http://www.PolysiusUSA.com.

Thank you.
____________________ 
Polysius Corp.  
Atlanta, Ga.   USA
http://www.PolysiusUSA.com
Voice:    770-850-2000
Main Fax: 770-955-8789


______________________________________________

Author Help files and create printed documentation with Doc-To-Help.
New release adds Team Authoring Support, enhanced Web-based help
technology and PDF output. Learn more at www.doctohelp.com/tcp.


Are you a Help Authoring Trainer or Consultant? Let clients find you at 
www.HAT.Matrix.com, the searchable HAT database based on Char James-Tanny's HAT 
Comparison Matrix. Contact [EMAIL PROTECTED] for details.
_______________________________________________

Technical Communication Professionals

Post a message to the list: email [EMAIL PROTECTED]

Subscribe, unsubscribe, archives, account options, list info: 
http://techcommpros.com/mailman/listinfo/tcp_techcommpros.com
Subscribe (email): send a blank message to [EMAIL PROTECTED]
Unsubscribe (email): send a blank message to [EMAIL PROTECTED]

Need help? Contact [EMAIL PROTECTED]

Get the TCP whole experience! http://www.techcommpros.com

Reply via email to