|
–Geoff-Hart.com: Editing, Writing, and Translation —Home —Services —Books —Articles —Resources —Fiction —Contact me —Français |
You are here: Articles --> 2001 --> Effective onscreen editing. Part four of a four-part series.
Vous êtes ici : Essais --> 2001 --> Effective onscreen editing. Part four of a four-part series.
by Geoff Hart
Previously published in a different form as: Hart, G.J. 2001. Effective onscreen editing. Part four of a four-part series. Corrigo, Newsletter of the STC Technical Editing SIG. 1(4):1, 4–6.
Click here to read Part 1 of this series.
Click here to read Part 2 of this series.
Click here to read Part 3 of this series.
One of the thornier problems in moving to onscreen editing involves communicating your proposed changes to authors—and I use the words communicating and proposed advisedly. Few of us have the authority to simply impose changes; most of us must let authors review and perhaps reject our edits. Since whatever corrections you make onscreen will look just like the text the author originally typed unless you somehow make the comments stand out, how do you identify where you’ve made a change? By making the appearance of what you type differ from what the author typed.
Whatever software you use for editing, you will be inserting new text into the file and deleting or modifying existing text. Word processors differ primarily in how the changes appear to the author, but there are two main situations you must deal with:
If you’re in the unfortunate situation of using different software from the author, the file formats are rarely fully compatible, and that means that you can’t rely entirely on your software’s built-in revision-tracking features. (See the next section for details.) In the worst-case scenario, no formatting information will transfer, and you’ll have to enter your edits without any formatting whatsoever. This happens far less often than it used to, but the problem may still arise if (for example) you have clients who prepare most of their text in a text editor (e.g., programmers working in HTML or working with a UNIX shell account). If that’s the case, you’ll have to identify your edits using only the keys available on the keyboard.
A low-tech approach works just fine in many cases, though it’s more tedious to enter the edits and more time-consuming for the author to review and implement them. In this approach, you select a standard set of paired characters, such as < and > or ## and ##, and use them to bracket your comments and thereby separate them from the original text; your comments go directly between the paired characters. A typical result might resemble the example in Figure 1. If the two word processors are sufficiently compatible that you can change the color of the text you insert and the author’s software translates the color information properly, you can instead enter your comments in a different color (e.g., red) to make them easier for the author to see. If several people will review the same document, you can include your initials inside the markers so the author will know whom to contact with questions.
Figure 1. Edits marked using only the keyboard.
This <replace “this” with “the”?> correct <missing word here: method?> of editing onscreen will depend <delete “will” and change “depend” to “depends”?> on the author.
The third problem is that comments entered in this manner can be easy to miss, and at the end of the production process, someone must do a final check to ensure that no comments have been left unaddressed and that no embarrassments remain behind in the file for your audience to discover.
As Figure 1 shows, embedding your edits in this manner can create sentences that are quite complex for the author to decipher, so it’s particularly important to determine what types of changes you can make “silently” (i.e., without having to identify them for the author). For example, if you’re certain that you’re not erroneously correcting an accepted spelling, it’s much more efficient for both you and the author if you simply correct the spelling errors and don’t mark those changes. However, if you’re unfamiliar with the subject matter, you risk changing words that should have been left as-is. If you can contact the author, you should instead confirm that the proposed change is acceptable; once you’ve received confirmation, you can go ahead and make the changes. If you can’t contact the author, insert a comment that explains the problem and proposes the solution (e.g., “Can we replace all instances of ‘utilize’ with ‘use’? That’s less intimidating to our audience.”). It’s not always wise to ask authors to make such changes, because an inexperienced author using a powerful search and replace function can do extensive damage to a file, and that damage may not be caught if (as is often the case when you’re a freelance editor) you won’t see the file again for a final check.
Longer comments and questions complicate the author’s review process because they take up lots of space, and break the flow of the text. Worse yet, it’s far too easy for authors to accidentally delete both your embedded comments and interspersed chunks of correct, unedited original text. Another solution might be to insert your edits in the form of footnotes, which generally transfer successfully between different word processors. Using a footnote for a long query works well because the author can see both the original problem text and your suggested revision simultaneously; the footnote usually appears in its own window, which authors can resize and reposition to suit their working style. However, if the manuscript already contains footnotes, you’ll have to modify this approach so that your comments don’t disrupt the existing footnote scheme and so that your edits don’t remain behind to become part of the footnotes in the final publication. (Although this problem rarely arises in most technical writing, it can be considerably more serious in fields such as academic editing.) In this case, the solution is to insert a small numbered marker, such as [#1], where the comment should appear, and then type the comment in a separate file that you can provide to the author. You’ll need to develop a review process that provides a final check to ensure that no comments are left behind; editing on paper is one such approach.
A final alternative is to simply make your corrections without indicating them. This approach works best with word processors that offer a “compare documents” feature, which examines the original and edited manuscripts and highlights the parts of the file that differ between the two (i.e., places where you made changes). Reviewing these differences lets the author see what you’ve done and provides an opportunity to confirm or reject your changes. This comparison can also provide a safety net for both you and the author, since it can indicate where you’ve inadvertently deleted a large chunk of text, or copied a large chunk twice through a careless copy and paste operation.
If you anticipate major editorial surgery on a manuscript, marking your changes as I’ve discussed in the previous section can prove prohibitively difficult. In that case, you should use compatible software, since this lets you insert comments using built-in revision-tracking tools designed specifically to improve your editing efficiency and the author’s efficiency in reviewing and implementing your edits. Using the same software as your authors makes the editing considerably easier than if you have to invent your own coding scheme, since you can go right ahead and edit. Modern word processors such as Microsoft Word let you extensively customize how your edits will appear onscreen (e.g., deletions could appear with a strikethrough or in green, additions could be underlined or in red). I learned to edit on paper, with the traditional red pen, so I use red text for insertions and red strikethrough to indicate deletions; a typical edit might look like the example in Figure 2.
Figure 2. Onscreen editing using Microsoft Word’s “Track changes” function.
The This correct method of editing onscreen will depends on the author.
It's helpful to standardize the appearance of insertions and deletions so that anyone who reviews your edits must learn only a single system; ideally, you should standardize all forms of editing so that authors who aren’t yet comfortable with reviewing edited manuscripts will have an easier time learning the system. Even so, there’s always room for flexibility; for example, you could use different colors to identify different reviewers, with all other settings the same. Negotiate a solution that works best for you, any additional reviewers, and your author. [A look back from 2005: Some software, and particularly Microsoft Word, lets each person customize the display of how revisions will appear, thereby eliminating this problem.—GH]
If you’re using revision tracking, many of the strategies and problems are the same as those that arise when you’re editing with software that’s incompatible with the author’s software. For example, any repeated changes that you must make throughout a manuscript will clutter up the screen with countless changes that the author should not have to approve. Instead, rather than asking the author to approve each change from “colour” to “color” (Americanizing British text), ask for approval first, then turn off the revision tracking feature and make the change. That way, the author can focus on more substantive changes.
This suggests a general rule: Wherever possible, perform strictly mechanical edits such as removing double spaces and correcting spelling before you turn on revision tracking. Your goal should be to edit in such a manner that the author must do as little work as possible to review and implement your corrections. For example:
If you replace entire words or phrases rather than making several changes within them, your edits will be easier for the author to follow. Moreover, working this way has an additional benefit (Figure 3): the author can accept your replacement in two steps (one to accept the new, inserted text, and a second one to accept the deletion of the text you replaced). In contrast, if you make multiple changes within a single word or phrase, the author must approve each insertion and deletion individually, and this can dramatically increase the amount of work required to accept or reject your changes. Another bonus is that editors who can type quickly often find it faster and easier to retype an entire word or phrase than to move the cursor one letter at a time using the arrow keys to make a series of small corrections.
Figure 3. Sometimes it’s easier for both the editor and the author if you replace entire words or phrases rather than fixing a series of errors one at a time. Compare the following edits:
Theires weare
sevveral
errrs in
trhjiusa sentence.
There are several Theirs were
sevverl errors in
this rjua sentence.
Editing involves a lot more than simply adding and deleting words; sometimes you identify important substantive issues that the author must resolve. That means you’ll have to insert comments such as “I’m not sure what you mean here… do you mean…?” and “Are you sure this number is correct? According to my physics text the value should be…” Substantive comments include both questions and any other remarks that ask the author to make a decision: to reorder the presentation, check facts, confirm that you’ve understood and reworded something correctly, or even add or delete whole paragraphs of information. You can also explain why you’ve made a change (e.g., “There’s nothing particularly wrong with this word, but the preferred word is…”), identify missing information (e.g., “A brief description of this item, perhaps even a photo, would help here.”), and indicate places where you’ve reorganized the flow of text (e.g., “House style is to place the Abstract before the Introduction.”).
As with additions and deletions, it’s generally more helpful to insert comments so they appear before what they refer to so that the author knows what to focus on after reading your comment; in effect, you establish the context for the problem and your proposed solution before you ask the author to examine the original text. Depending on the software, inserted comments may be marked in the text as yellow sticky notes, footnotes, or labeled boxes (Figure 4); the comments themselves appear in a second window or in a popup of some sort when the author double-clicks on the note. It’s a matter of personal preference whether you close such windows and leave more onscreen room for the document itself, or leave them open as you edit.
The last step in any onscreen edit is to rigorously scan the file to confirm that you haven't left any comments embedded in the text. In some cases, the missed comments represent important, unresolved issues; in all cases, it would be embarrassing if they appeared in print or in the final onscreen document.
Figure 4. Inserted comments in Word 97.
| This line contains an inserted comment[GH1]. | Note: If you double-clicked on the [GH1] in Word, you would see the comment text. |
If you and the author agree to adopt this approach, make sure you understand how the software handles such insertions. For example, Word 97 uses a paragraph style called "Comment text" to format your comments. If this style doesn’t use the same typographic specifications as the text you’re editing, copying text from the comments and pasting it into the main document will introduce changes in the typeface or type size within the main document, and these may come back to haunt you later during layout and proofreading. For example, the typical default setup for some software uses smaller or even different fonts for the comments; the default setup for my version of Word originally used 12-point Times Roman for the manuscript and 10-point Times Roman for the comments.
Editing tables composed of words or numbers poses little difficulty, since most word processors treat the tables as editable text. (Adobe’s PageMaker software is a notorious exception; authors or designers often create tables using Adobe’s Table software, which creates the tables as uneditable graphics.) Graphics pose more difficulties because you can’t edit them directly unless you own the illustration software the author used to create the graphic. The most common solution involves inserting comments in the text beside the figure or its caption that explicitly state what corrections the graphic requires. In some cases, it’s simpler to print the graphic and annotate it by hand; in others, it may be worthwhile to use Adobe’s Acrobat and Acrobat Exchange to produce a PDF file that you can annotate directly. In any event, work with the author to identify a solution that facilitates your work without making the author’s task unduly complicated.
In moving from on-paper to onscreen editing, the core competencies of being an editor remain the same, but the ways you apply the tools change. The advantages of onscreen editing, including clearer communication and a more efficient way to implement revisions, nonetheless outweigh any drawbacks. This article should help improve the efficiency of your onscreen editing and the author’s task of responding to and incorporating your revisions. But don’t let my recommendations become your final process: experiment until you find out what works best for you and your authors—and what doesn’t work!—and use some of my suggestions as the starting point for developing your own shortcuts and efficiency enhancers.
I’d like to thank Andrea Balinson, Shoshanna Green, Jane Lyle, and Linda Renshaw for their comments on an earlier version of this manuscript.
The “Technical Editor’s Eyrie” Web site is a useful resource run by Jean Weber. You can also order her book Electronic editing: editing in the computer age by downloading a PDF version or ordering a printed copy. The book discusses onscreen editing in far more detail than I can provide here.
To learn the details of onscreen editing that are only summarized in this article, see my book Effective Onscreen Editing.
©2004–2024 Geoffrey Hart. All rights reserved.