TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Finally - Conference Notes From:BurkBrick -at- AOL -dot- COM Date:Sun, 12 Jun 1994 22:41:01 EDT
Finally, folks, here it is . . . the report on the conference you ve all been
waiting for . . . (sorry it took me so long) . . .
Barb s Most Excellent STC Conference Adventure
Keynote speaker: Gordon MacKenzie
They shouldn t put such a wonderful speaker at the beginning of a conference.
He made everyone else pale in comparison. What an act to follow!
His talk was on maintaining creativity in a bureaucratic environment. He won
my heart from the start by telling us that when he was preparing this speech,
he had all kinds of ideas, but when he started putting them together in a
speech, he lost the essence of his ideas. So, he thought, why merge them into
neat little paragraphs that all flow nicely together? Instead, I ll give
everyone a sheet of 18 little drawings and clothespin them to a clothesline
on the stage, and people can pick the idea they want to hear me talk about!
Number 19 was the shut up and go away idea.
My favorite idea is number 13, which is a picture of a cow s udder. When it
was selected, he said that companies consist of two kinds of people: bean
counters and creative types. These two types of people clash when they meet,
and don t understand the other group. The bean counters look at a group of
cows, comfortably chewing their cuds in the sun, and says, Hm . . . if they
weren t spending all day in the sun chewing their cud, we could put them on
the milkers and get more milk out of them. What they don t realize is that
the cow needs to spend the time chewing its cud to make milk, much as
creative people need to chew their cud to keep coming up with creative
ideas. This was particularly meaningful for me because my husband, a design
engineer, was recently asked if he could come up with an industry
breakthrough, preferably patentable, in the next two or three months.
Then there s idea number 3: a picture of dog s legs under a pool table. This
was inspired by a stop he made into a bar for lunch. As he was eating his
lunch, he noticed dog legs under the pool table. He didn t think much of it
at first, but then noticed that they didn t move. So then he figured it was a
stuffed dog, until he noticed that the tail wagged. He thought maybe he
didn t see it quite right, so he stared at the tail. Sure enough, it wagged
again. He didn t want to say anything, but on the way out, he took the long
way to the other side of the pool table. The dog was indeed alive, and had
its mouth stuck in the tray the balls rolled down. The dog had caught the
ball on the way down, but then couldn t get his mouth back out with the ball
in it, so he just stood there. Gordon said he just had to ask - why don t you
help this poor dog? The regulars said, Oh, he does that every day; makes him
happy. He ll quit after a few hours. Moral? Don t hang on to things that
keep you in one place. Give yourself some flexibility.
I ll just do one more of Gordon s ideas - hopefully other people will pick up
the slack (or better yet, maybe we can get videotapes to show at the local
chapter meetings for those who couldn t go to the conference). Idea #6:
Orville Wright didn t have a pilot s license.
Well, after Gordon s inspiring speech, I headed off to my first Technical
Session, and off to a week of happy tiredness!
What did I learn? Following are some of the sessions I attended and tidbits I
got out of them that I thought others might find useful as well.
How to Write Your Own Contract (Louis C. Constanzo, Constanzo Communications)
I recently had a contract drawn up, so I used this session to compare notes.
Tidbits:
7 Make sure the person who signs the contract is authorized by the company to
do so. This seems obvious, but I ve never thought to ask.
7 Think about specifying accuracy levels. One contractor includes a clause
that states that there will be fewer than 1 in 1000 errors and that the
documents can be read by someone with an average literacy level.
7 Add a clause that allows you to retain a copy of the work for sample
purposes only.
Jump Right In! An Approach to Developing Hypertext (Jodi K. Blake, Paul D.
Hasenwinkel, and Charles Christopher Sanchez, all from Andersen Consulting)
I might have to start doing online help, and this looked like a good
learn-how-to-plan session, which it was.
Particularly useful tidbits:
7 Things to consider when deciding which software to use: decide if online
help will be stand-alone or integrated into the product. What tools does the
software use - authoring, editing, linking, graphics? How hard is it to learn
for both the documenters and the end-users? What hardware is supported and
what will users need to have to run it? How much vendor support will you get?
7 Establish standards up front for writing style, graphics, linking,
indexing.
7 Determine the amount of time it will take by the numbers of topics or
panels.
7 Mapping took about 30% of the project time.
7 Compose topics from the bottom (specific) to top (general). This prevents
redundancies and gives information on what should be linked. HOWEVER: use a
system so you don t lose links.
7 Quality assurance reviews - ideally, one person to ensure consistency.
7 Before linking, text should be as finalized as possible.
Technical Editing & Writing in the Future: What future technologies will mean
This wasn t what I thought it was going to be, so I left early, but got a few
useful ideas:
7 In computer-based training materials, provide a check sheet so users can
check off what they've done. Color screen grabs help them track the workbook
to program. Tell the user how long each section will take. Do skill checks at
the end of each module.
7 30% of their users had difficulty using a computer mouse.
Humor in Technical Communication - Are You Kidding? (Mark Hanigan and Carolyn
Watt)
Couldn t resist this one!
Tidbits:
7 Humor makes message easier to understand and to remember.
7 If you use a humorous illustration to show how not to do something, you
must also show them how to do it - otherwise the reader will remember the
wrong way.
7 It s usually better to make fun of yourself, the program, or the company
rather than the outside.
7 If you can t lighten up the text, lighten up the examples.
7 If your documents need to be translated, be careful when you use humor -
even symbols can mean different things in different countries and cultures.
Mark humorous items for translators. A translator spoke up and said he would
love to see funny things - it would be more fun than most of the dry stuff
and a challenge to make it funny in more than one language.
7 How do you convince the boss? Humor increases document circulation. One
participant said that he had to work on a newsletter about lawn mowers, and
asked if he could make it humorous. Sure, no one reads it anyway, said his
boss. In the first issue, he included an article about a product that has a
similar chemical makeup to anti-perspirant. So he put a cartoon in showing a
lawn mower spraying its pits. Newsletter circulation soared, and distributors
kept asking for more cuz people keep taking them.
7 Run humorous items by both men and women - things that men think are
hysterical, women think are stupid and vice versa.
7 Research documents: International Journal of Humor Research; Dept. of
English; Purdue University; W. Lafayette, IN, 47907; Victor Raskin. e-mail
address: raskin -at- j -dot- cc -dot- purdue -dot- edu -dot-
Manual Evaluation Workshop
Don t be afraid to go to one of these if you get the chance. The reviewer
pointed out many useful hints. He also mentioned that using Doc-To-Help might
be a good way to index Word for Windows documents - this is something I ll
have to check out!
Things I want to remember for next year:
Find someone to talk to about the speakers and read the Proceedings to figure
out what you want to go to. Many topic titles and descriptions didn t match
the presentations. This doesn t necessarily mean they were bad presentations.
However, it s frustrating to choose between two topics you re interested in
and find out that the one you picked wasn t what you thought it was going to
be. Then you have to run over to the convention center to get to the other
interesting one, which you ve just missed half of.
Be friendly! I met many wonderful people and learned a lot from people I just
struck up a conversation with on the street. Get your STC name tag as soon as
possible - when you know who your comrades are, it s easy to strike up
conversations. Before we got the name tags, though, I was a little timid
about walking up to strangers and asking them if they belonged to STC.
I got to meet lots of people from the techwr-l list. Interesting - I thought
I was putting faces with names, but I ve found myself putting voices to their
writing! LaVonna did a wonderful job in getting us stickers, so we could spot
each other, plus organizing a meeting place in the Welcome Reception.
The PIC lunch and the Welcome Reception were the best preplanned events I
went to. I generally found that I was better off leaving time open so I could
get together for lunch and dinner with new friends, though.
I hope this gives you some feel for what the conference was like and that the
little bits of knowledge I shared here are helpful to you, too. It s
impossible to tell you everything I saw, did, and learned, but I tried to
give you the flavor of my experience at the conference.