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.
Several folks have noted problems with editing on the screen. For one
example (lost the start of the thread and thus can't attribute it),
some claim that it creates a visual mess because of all the changes.
Well, partly that's inherent to the job: if you edit heavily, there's
gonna be lots of re(a)d ink whether you edit on the screen or on
paper. The advantage of working on the screen is that no matter how
messy you get, it's easy to take a moment to clean things up. Can't
do that on paper.
Part of the trick is about how you insert the changes; for example,
rather than fixing three typos in the middle of a 10-character word,
it's faster and the results are clearer if you retype the whole word
from scratch and delete the typo-laden original. Same applies to
groups of words, and possibly even to entire sentences. In addition,
it's easy to switch between displaying all the changes and concealing
the changes to show just the results... you can't get a cleaner
display of edited text than the latter view. <g> Lots of details on
this in my book (see below my sig).
For another example, Jim Morgan wrote: <<Maybe it's just my
astigmatic eyes, but I always catch details on paper that I seem
unable to spot onscreen, hard as I have tried over the years to
eliminate the paper-wasting.>>
Over the years, I've done an enormous amount of mentoring. One thing
I've found is that very few people spend any time customizing their
computer to support the specific work that they're doing. Many things
we miss on the screen can be solved simply by playing with the
settings. In terms of visual problems, there's a whole host of
solutions, including the obvious: use the zoom tool to enlarge the
text to whatever percentage works best for you, and fiddle with your
screen resolution. The two (enlargement and resolution) interact, so
you have to play with both together to see what works for you. For
instance, I routinely enlarge text to 150% compared with what my wife
and several colleagues are comfortable with, in part because they
prefer smaller text and use larger screens. There's a whole chapter
in my book on customizing your computer to make it easier to see what
you're doing.
Those of us who work almost exclusively as editors find that in the
beginning, its useful to do both onscreen editing (first pass) and on-
paper editing (second or final pass) to see what they're missing on
the screen. Since we all do at least two passes through a manuscript
anyways, this doesn't add to the time requirement; on the contrary,
it can reduce the time requirement because you can work more
consistently on the screen using the search function -- thus, fewer
consistency problems missed. Working on paper can teach you what
you're missing on the screen. Once you know that, you can pay
particular attention to that specific problem and learn to watch for it.
Lauren noted <<I edit on paper with a red pen. It is easier for me
to see and share my document changes. I can mark revisions online,
but I won't have my notes about why I made changes...>>
That's why there's a "comment" feature. <g> Insert as many comments
as you need, and trash them when you don't need them anymore. If you
need two sets of comments (one for the author to see and one for only
you to see), used the built-in comment feature for comments to the
author, and use our own coding, such as <private comment> for your
own notes. Then save a personal copy of the file and delete all the
private notes before sending it to the author. You can automate this
easily with a macro.
<<... and I won't have notations, like "stet," to indicate that I had
considered a change but decided against it.>>
Working on the screen, there's no need to type "stet": simply reject
the change you made. (I have keyboard shortcuts for accepting and
rejecting edits so I never need to go to the menu.) If you decided
not to make a change, why bother inserting a note? We editors are the
only ones who care about our thought process. If you're not certain
whether "stet" is correct, insert a comment to remind the author (or
yourself) to confirm that your decision to stet a change is correct.
<<I am also a pack rat while documenting and I keep a stack of
hardcopies with edits until the documentation project is done, in the
event that I need to backtrack or review past changes.>>
Which you can do easily, without killing any trees, by saving a
different version of the document for each stage. This doesn't
require version control software: just add "-original", "-first
edit", "-after Geoff's peer review", and other hints to the end of
the file name, or add the date of the edit to the name. Works exactly
like a paper trail, with the huge advantage that you can use the
search function to find text quickly in any version of a file, and
can copy and paste any text you need instead of having to retype it
from scratch. The larger the file, the more efficient it becomes to
keep an electronic "paper" trail instead of a paper one.
One of the goals in my book is to demonstrate how nothing that you do
changes when you move to onscreen editing from paper: all that
changes is _how_ you do it. Read a copy and see if it helps! <g>
----------------------------------------------------
-- 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)
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-
