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.
Al Geist provided more information: <<I suggested scripting and
having the technical writer standing behind the videographer (or
being the videographer) and the suggestion fell on deaf ears because
he doesn't see where scripts are needed>>
Why not make a virtue of necessity, and treat this as a benefit? You
now have an audience analysis being done when most of us would kill
for that opportunity: you get to see how a real audience works with
the product. Focusing on that specifically will help you cut out all
the other stuff you might otherwise (uselessly) document.
<<As for professional videos, it would be engineers using a home
video camera taking notes as they build one of the systems
(standalone or cluster system).>>
As Patrick Hofmann noted (see my previous message), it doesn't take
professional cinematographers or video equipment to do a great job.
Here, you may also want to consider a digital still camera instead of
a video camera.
Several years ago, I invented a series of "quickstart" manuals
working with an engineer that we whipped together in something like
an hour (plus writing and revision time). He came into my office with
the gizmo, and set it up while I watched, pausing before and after
each key step so I could photograph the before and after. (Having a
digital camera meant I could instantly see whether the photo was good
enough or had to be retaken. It also meant I could take multiple
shots and choose the best one later.)
The photos (with a few callout arrows and judicious highlighting)
accounted for something like 75% of the information content in the
manuals, which meant I only had to write a handful of words for each
photo, emphasizing what could not be emphasized purely visually. Not
only was this fast, the users loved these manuals.
<<Prior to my arrival, the company would pump out service manuals for
systems in a couple of weeks....and those manuals sucked.>>
Not surprisingly. It occurred to me belatedly after replying to your
previous message that if the quality of the old manuals was that bad,
the quality can only improve now that you're on the job. Spend a few
moments asking the trainers and sales staff to keep track of the
compliments you receive. That's useful capital.
One thing to keep in mind: this will be the Ikea of documentation
jobs, which is to say "bare bones, just the facts ma'am". Think
minimalism here: provide the bare minimum that the reader needs to
get the job done well. Treat the reader as intelligent and able to
figure out most of the details by themselves, so that you don't have
to write down those details, and make sure you provide all the
details they can't figure out by themselves. And worry more about
getting the concepts right than polishing the words to a fine glow.
You won't have time for that.
Also, start thinking right now about productivity tricks. For
example, you noted that you're using Word (see below), in which case,
learn to use the Autocorrect function. For example, imagine how much
time you'd save with an autocorrect entry that types "Open the X menu
and select Y" for you every time you type ]om (mnemonic: "open
menu"): you type 3 characters instead of 28, and multiply that time
savings by the number of menu choices you need to describe. That
example may not apply in your case (hardware), but there will be a
great many similar patterns you'll have to repeat by the dozen while
you write: spend a few moments identifying them and building
autocorrects. I literally save an hour or two per week not having to
retype comments (I primarily edit these days).
<<It is also a Word-based organization and there are no other options.>>
So what? Frame may be the better tool, but you can crank out
serviceable documentation just as fast -- possibly faster once you
master the automation -- in Word. Don't get hung up on tools, other
than learning how to use them efficiently: focus on the work.
<<The response I got from my boss was "reduce by half or loose your
jobs.">>
There's a certain amount of satisfaction to finding a new job now,
then giving him 2 weeks notice: "You have no respect for me or my
work, and you'd clearly rather have the engineers write the docs. So
I'll give you what you want -- with pleasure. I'm gone in 2 weeks.
What are your priorities for what's left of my time?"
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
***Now available*** _Effective onscreen editing_
(http://www.geoff-hart.com/home/onscreen-book.htm)
ComponentOne Doc-To-Help gives you everything you need to author and
publish quality Help, Web, and print content. Perfect for technical
authors, developers, and policy writers. Download a FREE trial. http://www.componentone.com/DocToHelp/
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
