framers Digest, Vol 77, Issue 17

Combs, Richard richard.combs at Polycom.com
Thu Mar 22 09:47:33 PDT 2012


I don't take legal advice - or political advice - from someone who talks about "Tort's Third Law" as if some fellow named Tort wrote it.

From: framers-bounces at lists.frameusers.com [mailto:framers-bounces at lists.frameusers.com] On Behalf Of Keith Smyth
Sent: Wednesday, March 21, 2012 4:22 PM
To: framers at lists.frameusers.com
Subject: Re: framers Digest, Vol 77, Issue 17

Ken, it might be a good idea to inform you MANAGER of the Third Tort Law.

You need to protect yourself by getting written instructions on what to include, and not include in the document. I saw this happen to an individual I was working with. Fortunately, he had signed instructions from the Product Manager to not include some safety instructions, as it would "upset the customer". So when a customer got burned badly, the customer went after the company, the company went after the writer, and the writer offered up the program manager, who got fired, and sued. Yeah, CYA.

Tort's Third Law
It is a good idea to be versed in Tort Law, specifically Tort's Third Law.  The emphasis of the Tort Law is consumer protection.  Tort Law did for the consumer what the unions did for the worker.  According to the Third Law, "A product is defective when, at the time of sale or distribution, it contains a manufacturing defect, is defective in design or is defective because of INADEQUATE INSTRUCTIONS OR WARNINGS."

This is important to any of us in the technical writing domain, as it puts the onus on us to provide adequate (and standard) instructions, which includes warnings in the instructions (and on labels if that is a part of our job). Most writers are completely oblivious to their responsibility under the Tort Law and many companies are equally oblivious (or choose to ignore).
As such, they are also ignorant to the fact that they can be sued in a liability action, as a company and as individuals, for their failure to provide adequate instructions and warnings.

To make matters even more complicated, it's a double-edged sword for a writer.   Business loves to hate the Tort Law and tends to kill the messenger.  If you, as the writer, are doing a proper job, you are the messenger.

There are also very few places that teach you this stuff - even the university tech writing courses overlook it.
If you muck around without knowing the standards and the law, you could get yourself and your clients sued.

BTW, The Big B (big business) is currently throwing a lot of money at our political types to try and weaken the Tort Law and relieve themselves of the burden of liability (recalling those bloody toys that kill or maim kids is such a blessed nuisance and just munches away at the bottom line).

In addition, any politicians who do not play ball will find themselves up against some pretty big bucks intent on running them out on a rail. The republicans in particular are fond of coming to the aid of Big B and can be counted on to slam dunk your protection under the current law.

--
Keith L. Smyth
President
Smyth Consulting
---------------------------------------------------------------------------------------------
Voting for someone because they are black is as racist
as voting against someone because they are black.

Beware an intrusive  government.

GOD BLESS THE UNITED STATES

---------------------------------------------------------------------------------------------
Technical Documentation Consultant


________________________________

Message: 6
Date: Tue, 20 Mar 2012 18:59:00 -0700 (PDT)
From: Ken Poshedly <poshedly at bellsouth.net<mailto:poshedly at bellsouth.net>>
To: FrameMaker Users List <framers at lists.frameusers.com<mailto:framers at lists.frameusers.com>>
Subject: best use of graphics in FM
Message-ID:
    <1332295140.67108.YahooMailRC at web180813.mail.gq1.yahoo.com<mailto:1332295140.67108.YahooMailRC at web180813.mail.gq1.yahoo.com>>
Content-Type: text/plain; charset="us-ascii"

FrameMaker 8.0 on a PC with Windows XP Professional

Except for bloated file sizes, in the long run, does it really matter if you
reference graphics or if you embed them inside your publications?

My coworker is a guy who was tech pubs manager at another heavy equipment
company but was convinced by our employer to move south from PA for this job. He
comes for a primarily graphics background, having started a long time ago as a
pen-and-ink tech illustrator. His writing skills are fair at best, but he
considers himself an authority on tech pubs because he had been the manager of
his group. And our company never did fulfill its promises to him if he left his
previous employer.

While we do get along pretty well, we do differ on this aspect of FrameMaker
graphics -- to embed or to reference?

We are the only two tech writers -- with no tech pubs manager -- and we work in
metro Atlanta, Georgia, for a multinational Chinese company in which the Chinese
engineers in Shanghai and elsewhere over there write the original documentation
for heavy machinery in the Chinese language (taking as long as they want), then
send the stuff to a group of kids in their 20s (sorry, but I'm way past that
age) in Shanghai who are not even allowed anywhere near the machinery but simply
translate the stuff as best they can into "Chinglish". The machinery and their
books are then put on ships and my coworker and I are then told we have two
weeks to "Americanize" the Chinglish stuff. That means reformatting,
reorganizing and rewriting the stuff for American heavy equiment owners.

Thus, we have next to no time to do things correctly. And I've been told over
and over that for the most part, "technical writing" does not exist as a
profession in China and it is simply assigned to anybody and everybody. Their
books look absolutely beautiful and they know how to mimic our page layouts, but
it all breaks down when one tries to use the books to actually operate this
extremely dangerous machinery because the terms, grammar, punctuation, etc., are
all so inconsistent, incorrect and well, you get the idea. And the U.S.
president of the company is only here in the U.S. for about 4 years and follows
ONLY the Chinese methods. (For one thing, no salary increases; you simply stay
at your starting level or quit. And, by the way, very few if any promotions. I'm
there 3 years and looking to move on.)

Unfortunately, at his prior location, another FM user (more knowledgeable than
my coworker) showed my coworker what I call a "hack" to get a document done in a
fraction of the time that it would ordinarily take. Specifically, he uses
"PrintScreen32" to take screen shots of existing graphics in the Word or pdf
Chinglish books we get from the home office and then pastes them directly into
his FM document. No muss, no fuss -- and no record of any filename or any other
details about any of the graphics in his documents.

He also does this with text blocks (sometimes entire pages) from the Chinglish
books and simply pastes those text blocks into his FM documents. The results
are  horrendous because no real editing can be done (and errors in the original
text abound). He simply creates small FrameMaker text blocks over incorrect
words or sentences and types in the few words or sentences needed to fix
something. So his FM documents are pretty much "pictures" of text with white
boxes of corrected words that give his pages that "ransom-letter look".

This method allows him to "complete" a document much faster than doing it what I
call "the right way".

I, on the other hand, have no problem with taking screen shots and saving them
as legitimate graphics with an art control numbers (as listed in an Excel file
created just for this purpose) that can be either referenced or embedded in
other documents. It's true that my method takes a few steps more (thus more
time), but the result is a findable graphics that can be reused over and over.
(I also know how to copy text and properly paste it in an FM document.)

Many of our graphics are used again and again, and many are one-timers. Plus,
embedding pert near 100 or 200 graphics in a document tends to create a
humongous filesize. For instance, a 225-page manual done by my coworker as
described above  (that I've had to completely redo correctly with edits
throughout following its technical review) and that has over 200 embedded
graphics and text blocks was about 800 megabytes in size. I routinely get a
warning that there may not be enough computer memory to open the document, but
it does open, taking about 45 seconds or more. He says that it is poor software
and refuses to admit that his way is stupid. The file is smaller since I've
redone it.

So the questions are:
* Does anybody here have a fast way of saving screenshots as legit graphics for
later reuse, and if so, what is your method and how many seconds would you say
it takes?
* Am I being too controlling on this matter? (I suspect yes.)
* If I'm not too controlling in this, are there any other arguments I can use to
bolster my side of the story?

Th-Th-That's all folks!!

-- Ken in Atlanta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frameusers.com/pipermail/framers-frameusers.com/attachments/20120322/8fec07d1/attachment.htm>


More information about the framers mailing list