You are here: Resources --> 2000 --> Effective onscreen editing. Part one of a four-part series.
Vous êtes ici : Ressources --> 2000 --> Effective onscreen editing. Part one of a four-part series.

Effective onscreen editing. Part one of a four-part series.

by Geoff Hart

Previously published in a different form as: Introduction Hart, G.J. 2000. Effective onscreen editing. Part one of a four-part series. Corrigo, Newsletter of the STC Technical Editing SIG 1(1):1, 4–6.

Editing is increasingly moving off paper and onto the computer screen, and although the essence of the work remains the same, the details change greatly. Unfortunately, the problem with onscreen editing is that it’s like walking: once you’ve been doing it for a while, you do it so automatically that you can't for the life of you remember the details well enough to explain them to someone else. Based on my own experience, supplemented by various discussions on the copyediting–l discussion list, I’ve prepared this summary article to help us remember how to teach that useful skill to others—or acquire it ourselves for the first time. In addition to my own thoughts on this matter, I’ve incorporated and expanded upon comments by Linda Renshaw (Managing Editor of South Carolina Wildlife Magazine) during the course of that online discussion.

For the purposes of this article, I’ve chosen to focus on using a word processor to edit text, irrespective of whether that text eventually appears onscreen or in print. In terms of substantive editing, in which editors spend more time understanding a logic or content problem than they do fixing it, the similarities between onscreen and on-paper edits far outweigh the differences; for example, factual errors are equally wrong on paper and in your word processor, and unclear wording doesn’t become clearer when you print it so you can edit on paper. Rather than exploring the differences in how you should edit for onscreen and print media, I’ll concentrate on the actual mechanics of marking corrections, inserting questions and suggestions, and communicating the results to the author.

Everyone who edits manuscripts onscreen develops a personal, sometimes idiosyncratic, manner of working, and that’s as it should be; no one solution works best for everyone. Nonetheless, every editor encounters certain common problems, and some strategies seem to work better than others and are worth proposing to a new editor confronting the process for the first time. This article reflects what I consider to be efficient and effective for me, but your approach will undoubtedly differ (or, if you’re learning online editing based on this article, will diverge from the one I’ve adopted as you become more experienced). But the approach I outline below can serve as a good starting point for developing your own approach.

Accuracy versus efficiency

Editors have engaged in an ongoing debate for many years about whether onscreen editing can ever approach the accuracy of editing on paper. On the face of it, it appears obvious that paper should win hands down because laser-printed text has higher resolution and contrast, and paper causes less eye fatigue than a flickering monitor. And early studies did indeed show that editors missed fewer errors on paper than onscreen. But the display quality of computer monitors has improved dramatically since those early studies, and long years of practice have helped us improve our onscreen editing skills. I haven’t seen any recent studies on this subject, but anecdotal evidence (including the claims of several experienced editors whose opinions I respect greatly) suggests that accuracy can now approach or exceed that of on-paper editing.

If you’re at all uncertain, try editing a document on the screen, then print out the revised version for a second edit to see what you missed during the first pass; many experienced editors prefer to do their second pass on paper, whereas others reverse the process and edit on paper first. This second pass doesn’t really represent additional work, since you’ll need to read through the document a second time no matter what medium you use for your editing; no professional editor I’ve met considers an edit to be complete after only a single pass through a document, and most of us take multiple passes, looking for different things each time. By identifying the types of problems you routinely miss when you’re working onscreen, you can subsequently learn to focus on these blind spots and improve future onscreen edits. In general, you’ll discover that you catch certain things onscreen that you miss on paper, and vice versa, and experience has taught me that “onscreen vs. on paper” is rarely an either/or issue. If you have the luxury of looking at a document in two different media, you should take that opportunity. For one thing, the more passes you make through a document, the more errors you’ll catch; for another, the change in perspective when looking at the same text in two different media increases the chances of catching errors, just as elapsed time between consecutive on-paper edits lets you approach the task with fresh eyes. (Speaking of which, don’t forget that changing media also gives your eyes a rest, something optometrists recommend strongly.)

Given that the accuracy of onscreen editing can match that of editing on paper, the next question becomes whether working this way is efficient.To be truly efficient, the process must improve both your editing efficiency (speed and accuracy), and the author’s ability to respond to your edits and produce the final, improved manuscript. This is where onscreen editing really shines. For one thing, once you’ve typed your edits into a file, nobody has to retype them and proofread the retyping to detect errors; the corrections are already present in the file, and the author need only accept, reject, or modify them. Many organizations no longer have typists to make corrections on behalf of authors, and where slow-typing authors would have to retype your corrections themselves, this benefit can by itself justify onscreen editing. One final bonus: If, like many technical communicators, you have illegible handwriting, typing your comments makes them far more legible, and thus minimizes the amount of time someone must waste trying to decipher a scrawled comment.

If you plan to do any significant amount of your editing onscreen, take some time to personalize your working environment for optimum efficiency. For example, I prefer a high-contrast display with black text on a white background, but other editors prefer color combinations that I consider bizarre; some justify their choice on the basis of reduced eyestrain or improved accuracy, whereas others simply like certain colors better. Similarly, I prefer a single uncluttered window so I can see as much text as possible without scrolling, whereas others prefer to have multiple windows open into a document. And while I can edit reasonably well with a 12-point Times Roman font early in the day, I find that I sometimes prefer to use a larger sans serif font in the evening, once my eyes have grown fatigued. Check your word processor’s “View” menu to see what other options exist to make reading easier, such as the ability to zoom in on the manuscript. Ideally, you should return the edited manuscript to the author in the same format the author used to create it, but that doesn’t stop you from temporarily formatting it the way you prefer; if the author defined and used paragraph styles, you can change the typeface and font size simply by redefining those styles to fit your preferred work style, then change them back to the author’s original settings once you’re done. (If your software marks your changes as you edit, something I’ll discuss in a subsequent section, redefine the styles before you turn on the tracking of revisions so that the author will never notice that you’ve made them.) The principle is to pay close attention to how you work and to experiment with the software’s settings until you find a combination of screen colors, typeface, and font size that works well for you.

File-exchange issues

When you and the author use the same software, file-exchange poses fewer problems than when you’re using different programs, though there are often small glitches you need to watch for; for example, if your client uses a foreign-language version of your word processor or a different operating system, the character sets probably won’t match perfectly. Exchanging files between the Macintosh and Windows platforms is notorious in this regard, since the upper portion of the two character sets (i.e., the characters that aren’t printed on your keyboard) differs between these two platforms. Worse yet, you sometimes find yourself having to edit files created in software that you don’t own. In all these cases, exchanging files with an author requires some form of file conversion, whether using the software’s “save as” or “export” features or special translation software.

Transfers within an organization typically pose the fewest problems, since most large organizations standardize and debug the file formats and transfer mechanisms. But you won’t always have the luxury of using fully compatible software, and that means you’ll have to face the problem of conversions. Whenever you must convert between file formats, allow some time for testing so you can ensure that the conversion process preserves your revisions and comments. If you and the author are using different software, pay particularly close attention to how successfully insertions, deletions, and comments survive the conversion. Testing will reveal what problems you can expect, and that gives you a chance to develop solutions before you exchange files with the author.

Transferring files to distant clients over the Internet creates additional problems. File-size limitations are the most common problem, but generally represent an inconvenience (e.g., slow transfer times) rather than an actual barrier to file exchange. Compressing files using software such as the WinZip compression software on PCs and the StuffIt compression software on Macs or PCs is a great help, and has the additional bonus that compressed files usually contain error-recovery information that will help them survive the rough trip through cyberspace. Keep in mind that some organizations and some Internet service providers impose limits on file sizes in an effort to reduce their e-mail costs by reducing transfer times; if you’re working on large projects, these automatic limits may exclude even compressed files. You can sometimes ask the organization or service provider to make a temporary or permanent exception in your case to permit large file exchanges. If not, you can sometimes ask the service provider to set up an FTP (file transfer protocol) directory to exchange files, since FTP software isn’t affected by limits set on e-mail. When neither of these options exists, you may have to resort to breaking the file into several smaller files or even sending it on floppy disks or other media.

Until recently, the “protocols” that different computers used to transfer files posed an obstacle, but this issue has become less important. Internet standards such as the MIME extension to the Internet’s original e-mail protocol now help ensure successful file transfers between almost any two computers. With few exceptions, most Internet service providers can now handle these standards, but even that’s not guaranteed. So depending on how modern your client’s setup is, some experimentation may be required before you find a combination of file format and transfer protocol that lets you exchange files correctly.

Click here to read Part 2 of this article.

Click here to read Part 3 of this series.

Click here to read Part 4 of this series.

©2004–2024 Geoffrey Hart. All rights reserved.