Embed Size (px)
DESCRIPTION
This presentation was held at the STC Summit 2005 in Seattle. It shows how technical authors, hit by the offshoring of tech comms, can find plenty of work in the machinery business. After all, that business domain is less likely to be offshored and there are many more small machinery companies than global software corporations.
Citation preview
Getting your hands dirtyJang F.M. Graat
IF UnLtd B.V. - Netherlands
What will I tell you ?
What the machinery business is like
Why this business is interesting for us
How to understand machinery people
How to make machinery understood
Why only writing is not enough
Which skills would be really handy
How did I get here ?
Studied Physics, Psychology, Philosophy
Decided I could become a programmer
Became a tech writer & trainer instead
Started my own company in 1994
Wrote software manuals, online help
Work in the machinery business now
Where are you ?
Working in the software industry ?
Laid off recently or expecting it soon ?
Afraid of outsourcing or “off-shoring” ?
Not keen on moving toward MarCom ?
Not interested in training or sales ?
Not afraid of noise, dirt and grease ?
Machinery Businessthrough a freelance tech writer’s eyes
True WYSIWYG
If you don’t see it, it is not there
No last-minute cosmetic overhauls
It either works or does not work
Real hardware
No hidden features or options
Covers are for safety, not to cover up
Buttons are real, physical, buttons
Real danger
Safety is paramount for machinery
Abuse may cause serious injuries
Manual must show residual dangers
Real products
You see what the machine does
Everything has an intended purpose
Malfunctions cost real money
Business Potentialwhy the machinery business needs tech writers
Typical machines...
... are not produced in large numbers
... come in enormous varieties
... are often heavily customized
... need complete documentation
... cannot be moved around easily
Some examples
Shrink-Wrap Conveyor Belt Filter Cutter
Some examples
Glue Pump Safety Device
Some examples
Cigarette Maker
Typical designers...
... have no time for documentation
... assume everyone is an engineer
... live in a wordless world
Wordless 2D-world
3D-world, still wordless
Typical engineers...
... have no time for documentation
... assume you are better educated
... live in an engineer’s world
Reading & Writinglearning the lingo of the machinery business
Learn the jargon
Read manuals of similar products
Ask the engineer (when he has time)
Check out “howstuffworks.com”
Watch stuff on Discovery Channel
Browse engineering magazines
Read engineering primers
Learn to “read”...
... 2D and 3D assembly drawings
... common design principles
... technical construction documents
... 3rd party documentation
... how engineers work & think
Know your audience
Operators
Maintenance staff
Service staff
Writing for “dummies”
“What is this button for ?”
“What do I need to do ?”
“How do I do that ?”
Include everyday maintenance
Don’t expect any knowledge
Use photos where possible
Operators, no techies
As clear as you can
Simplified diagrams
Writing for “techies”
Follow modular machine design
Expect basic technical skills
Do not expect machine knowledge
Don’t include too many details
OK to use technical drawings
Get service engineer to review
Modular design
..
Using images
Digital photographs
Rendered 3D models
Technical illustrations
Assembly drawings
Pneumatic drawings
Electrical diagrams
Operators
Service staff
}
}
3rd Party Docs
Copies in appendix to service manual
Rewrite important procedures
Check procedures for correctness
Ask for translations on time
Writing is not enoughskills & knowledge that will come in handy
Digital photographs
Use a tripod and no flash
Check whether everything is visible
High resolution and little compression
Crop and scale down in Photoshop
Cut the environment where needed
Link into the document
Simplified English
Don’t try to be entertaining
Structure your descriptions
Write for maximum redundancy
Minimize - and define - the jargon
Use Simplified Technical English
Safety regulations
Clients often don’t know about them
Good documentation is crucial
Safety notes must not be overdone
ISO 9000 & 14000 and others
CE directives 98/37/EEG and others
Reality check
Don’t take procedures for granted
Engineers have too much knowledge
3rd party docs are usually for techies
Dress to get dirty
When in doubt, ask for help
Other services
Bringing in documentation technology
Handling translation outsourcing
Consulting on safety issues
Bringing help docs into the machine
Usability testing of GUI (touchpanels)
Consulting on cool new features
Questions ?Jang F.M. Graat
