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.
I don't usually write to the list, but I'm practicing the art of
community. I'm kind of hermit-like in real life.
I'm not writing to get suggestions as to what to do, though I expect
that some will be forthcoming, that is what we do so well.
There are days when what I do just seems insurmountably difficult.
These are rare days, but when the four corners of the earth rise up
and whack at you all at once... well, it's a bit overwhelming.
We're about two years into the process of going from unstructured
content to DITA. It was not a decision taken lightly. We are a large
group by most standards but the workload is commensurate with the body
count. Three full time writers working on user manuals, one contractor
helping out, and two editors (we share them with the three system
manual writers). We translate into 22 languages. We used to produce
several small updates a year (maybe 20) that ranged in size from a
single page to about 20 pages. Anything larger than that requires we
update the manual.
We had a mature, reliable process. We had consistent information
sources. We knew our own tools. I know it sounds like a fantasy for
technical writers.
A couple of years ago, we were told to reduce our costs. We were also
told that the the product line is expanding. We're now supporting
twice the product line and a faster pace of development.
We now no longer have a clue about what we're doing. We wrestle as
much with our tools as we do the fluctuating processes and demands
that feed us information and schedules. We used a pilot project to
familiarize ourselves with DITA. When we wanted to move to production,
our pilot project processes didn't scale out. The pilot project was
done outside of our content management system because the tools were
not in place to make the link happen. We're deep into production and
our tools support person has left the company. We are having a
horrible time importing our restructured content (1000 topics) into
the CMS. The setup is somewhat laborious and unreliable. Sometimes a
section will import with few or no problems and then refuse to come
back out for editing and updating. The export of content from the CMS
does not maintain the links to graphics so we're freaking about what
we're going to send to translation. That is, if we can get everything
in, we still have three sections (maybe 150 topics total) that are
resisting the import process that has worked for other sections.
Because our workload is already doubled, trouble-shooting the
transition is eating up time and energy we don't have on tap. There is
no money to pay for a hero to come and rescue us.
One thing we did was to switch from a vertical documentation process
to a lateral process. Instead of one individual writing everything for
one product, we split the subject areas up between us and one of acts
as the lead for a particular product release (that person builds the
books, runs the technical review, and signs off on the audit trail
tasks).
All that, and I'm finding that the area I have assigned myself is one
that could drive me mad. It's my own fault. I had been documenting one
product that was being integrated into others, so I'd become somewhat
of an expert on it. But, it's not simple, I can't just say click this
or choose that. I have to explain mathematical and spatial models. And
today, after months of working ten hour days six or seven days a week,
I'm done in. I'm listening to an interview with an engineer who is
eager to have me understand the concepts and operating principles of
his piece of the product. I can't write it. If I could put an AVI of
the screen with a voice over, I would. We minimize screen shots for a
number of reason and we don't include AVI for a number of other
reasons. I can grasp what the engineer is talking about, but I'm
almost too tired to write it. So, I wrote this instead.
I'm supposed to be done on Monday. I think I'll be baked on Monday.
Thanks fro listening,
wanda
--
Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people
are even incapable of forming such opinions.
Albert Einstein
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
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-
