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.
Michelle Vina-Baltsas wonders: <<I just found an error in one of the
manuals I work on and I feel sick. Fortunately, the error does not
pose the user any danger but it looks bad. What do you all do when
this happens? I'm having a bad case of the "I'm not perfect" blues.>>
When in doubt, blame the SMEs and reviewers. <g>
Seriously? That's actually a valid answer if the product developers
changed the software after telling you it was OK to print the manual.
Nothing you can do about that other than whack them upside the head
with a dictionary... or a clue club. You didn't specify the nature of
the error, but a few thoughts:
None of us are perfect, and I say this as an editor with 20 years of
experience and a pretty darn good rep for "missing nothing"... a
reputation that is mostly deserved, with a few notable exceptions.
The tighter the deadline and the more unreasonable the product, the
more errors there will be. Soon as you realize your* not perfect, you
can relax a bit and learn to accept that. Think how much worse the
communication would've been if you hadn't been involved.
* See? <g>
Better still, pay attention to the nature of the error. If it's
something that forms a predictable pattern, you can make a point of
focusing on that pattern as you work; by learning to internalize that
focus, you can learn to eliminate the error semi-automatically. But
some errors are simply unavoidable, and there's nothing you can do
about them other than grimace, fix the problem in the next version,
and move on. If you don't have a strong review and revision process,
and particularly if you don't employ a professional editor*, figure
out how to implement such a system or hire an editor, permanently or
on contract.
* Some writers make very good editors; many don't. But neither type
of writer is as good as a really good editorial specialist.
You only get really good at the things you do most often, and nobody
can both write and edit "most often".
----------------------------------------------------
-- Geoff Hart
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
www.geoff-hart.com
--------------------------------------------------
Coming soon: _Effective onscreen editing_ (http://www.geoff-hart.com/
home/onscreen-book.htm)
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
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-