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.
Six lessons for online editing tests using Microsoft Word?
Subject:Six lessons for online editing tests using Microsoft Word? From:"Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 10 May 2002 09:08:05 -0400
Bonnie Granat offered us hard-learned editing lessons:
<<Lesson 1: Don't edit online. That is, don't limit your editing to
reading the document on the computer screen>>
People who edit for a living get good enough at working in the new medium
that we come very close to being as good as we are on paper. But apart from
obvious problems of legibility (even with the best computer fonts, 96 dpi
screens don't match 600 dpi laser prints for legibility), changing media
changes the mental context enough that you can approach the job with a fresh
mind's eye. That lets you catch errors that even a second on-screen pass
won't catch. Highly recommended if you have the time.
<<Lesson 2: Make the minimum number of author queries... Even if you think
that "deciduously" could have been meant
to be "decidedly" or "assiduously", choose the most likely intent of the
author and go with that. >>
It's always good to minimize the author's workload, but don't let the word
"minimum" lead you to neglect queries simply because you feel you're asking
too many questions. It's certainly true that the author can see and approve
or reject your choices even if you don't explain them, but you can end up
looking foolish if you make a change without understanding why the author
chose the original word; sometimes there's a good reason for their choice,
even if it doesn't seem likely.
By all means, do your research to confirm a meaning rather than asking a
foolish question, and thereby minimize the amount of reading the author must
do, but remember that queries are inexpensive and authors appreciate them.
Sometimes a comment that explains why you made a change that turns out to be
incorrect will still reveal to the author a problem they hadn't considered,
and lead to a solution.
<<Lesson 3: Take your time.>>
Always take as much time as your schedule and workload permits, and never
forget that even the best editors always make at least two passes through
any manuscript, time permitting, and three isn't at all unusual. Best of
all, if you can do the edit one day and come back to it a day or more later,
you'll find that your mental state has changed enough to reveal many things
you didn't spot the first time through. Time gives distance, and distance
gives objectivity.
<<Lesson 4: Remind yourself that a test is a "test". Errors are not
forgiven. That you have caught many errors and corrected
them does not lessen the impact of your missing crucial errors.>>
And even a non-test is still a test--just one of a different kind. If you
miss important errors, your authors will gradually lose faith in you.
Moreover, finding subtler errors than just typos (e.g., illogic,
inconsistency) will annoy authors ("damn... thought I fixed that!" or "I'm
so ashamed to have made such a bush-league error!") but earn you their
gratitude because those errors won't make it into print.
<<Don't focus, as I did on the first test, on finding the problems with the
words only.>>
This depends very strongly on what the client wants you to do. If you're
just been asked to copyedit a manuscript, you may have no authority or
permission to deal with more difficult or important issues. My partner,
Shoshanna, just came up against this problem in a history manuscript she was
editing; as a trained historian, she had serious objections to some of the
author's conclusions, but was told by her client not to raise these issues.
On the other hand, if the type of editing hasn't been specified, feel free
to provide any substantive comments (logic, consistency, factual error,
rhetorical flow) that you feel would improve the manuscript. I do major
substantive editing on everything I do because I have my employer's or
client's encouragement to critique the content, not just how it's expressed.
Sometimes it's a very good thing I do. I try to avoid pure copyediting jobs
because I feel handcuffed being unable to critique the substance of the
work.
As you noted, re-reading a copy of the document with the changes
incorporated will reveal errors that you yourself introduced during editing
(just typos if you're lucky, mangled sentences if not). Highly recommended.
<<I got fed up with Word at some point, I am beginning to remember, when I
noticed the spacing problem and went to the page with changes and attempted
to fix it but could not see *anything* that caused the problem.>>
Some of these things you should be doing before you start editing; for
example, I routinely turn off track changes and replace double spaces and
carriage returns with singles before I begin. If I have the luxury of time
for a read-through before I actually begin editing, I'll also correct simple
typos without tracking them; while it's tempting to show off my skill by
visibly fixing everything ("look how many errors I caught!"), this doesn't
really help the author. Just be sure that you make such changes cautiously;
sometimes authors really did type the word correctly and you weren't aware
of spelling conventions for their genre.
Other things should be fixed by the client (if they have a production staff)
before the manuscript ever comes to you or will be fixed by the client
subsequently (e.g., during layout). Editing for a client rarely involves
such problems with spacing as changing all body text to use the "body text"
style and formats, for example; conversely, in-house editors often do this
as a matter of course. Always find out what the client wants you to do, and
if you plan to do something they didn't request, make sure you tell them,
and make sure the change is easy to undo if they decide they didn't want it
done.
This leads to another lesson: When in doubt, ask. If you're not sure what a
client wants you to do, save up your questions and ask them all at once;
make sure, for example, that you're using the Microsoft guide rather than
Chicago if that's their house guide. If you can't ask, or they don't want to
be bothered, make up a "style sheet" that contains a complete list of all
the unrequested changes you made. (For example, include the note that
because no style guide was specified in your assignment, you chose to use
the Council of Science Editors guide, and thus, changed all instances of
"assimilation" to "fixation". This both provides justification for your
change and gives the client a checklist they can use to undo any changes
they disagree with.)
<<Lesson 5: Don't be ashamed to use the spelling checker as a
*final-stage* tool.>>
In fact, as a general rule, you should always use the spellchecker before
you return an edit. You'll not only find errors that you missed in your
initial passes, but errors that you introduced yourself (typos and missing
spaces between words in particular).
<<Lesson 6... Let it sit for 24 hours or more and do not look at it.>>
See above. In the editing I do for ESL authors (Japanese scientists writing
for English journals), I always wait a day or two before revising my edits
and returning a manuscript. Moreover, as a quality control measure, a second
editor does a quick read-through to perform a reality check on my
substantive edits and catch anything I missed. That editor will always edit
things slightly differently, but more to the point, provides a fresh mind
and a final chance to catch errors we'd both agree to fix.
<<If there are errors in this e-mail, please understand that I have obsessed
about possible errors only about 50% as much as I obsess over possible
errors in the simplest post I make, so in advance I am begging your
pardon.>>
And may I just point out that there was an extra space before "Microsoft" in
your subject line? I fixed it for you, but honestly... <gdrlh>
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"A life spent making mistakes is not only more honorable, but more useful
than a life spent doing nothing."--George Bernard Shaw
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.