More Than Grammar: Expectations of Technical Editing New Hires

Shelley Thomas

As an academic who teaches technical editing to undergraduates, I wanted to know what employers’ expectations are for their new hires. In September, I asked the discussion list: “What would you expect from a new hire who has completed a technical editing course (beyond being well-versed in grammar, mechanics, and punctuation)?”

I received 18 responses to my question, and the range of issues raised by the listserv participants surprised me. While some of the responses stressed knowledge of the basics (strong knowledge of grammar, punctuation, and style guides), other responses were less focused on editing mechanics, concentrating instead on adept interpersonal skills and familiarity with various technologies. The technical editor’s responsibilities extend beyond grammar checking; the editor must be able to ensure consistency, logical structure, completeness, usability, and effective communication among all parties.

Grammar and Mechanics

While any company should be able to safely assume that a new technical editor would have a solid command of grammar, punctuation, usage, and mechanics, this is not always the case. Several respondents emphasized that this basic knowledge, which I assumed applicants would possess, was lacking. One respondent, Candy Jenkins, said, “I don’t believe enough emphasis is stressed on grammar and mechanics in institutions of higher learning, so having a good foundation in that is important.” Many companies use editing tests to ensure that their applicants have this most basic editing knowledge.

Style Guide

New editors must be familiar with standard proofreading marks and be experienced with using more than one style guide, especially the more widely used guides such as APA, Chicago, and AP. Because editors are divided regarding the use of soft copy and hard copy edits (see “Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy,” Corrigo, July 2007), editors continue to use proofreading symbols and authors rely on a standardization of these symbols to understand the edits. With the knowledge of various style guides comes an ability to create and maintain an in-house style guide (or a document-specific style sheet) to promote consistency. Furthermore, new editors must acquaint themselves with whatever style guide the company uses. Virginia Janzig remarked, “The editor needs to find out what style guide is used and then use it even if the editor doesn’t agree with some of the guidelines.” This knowledge allows the editor to edit with confidence by referencing a standard to support edits and make only necessary changes.

Interpersonal Skills

Editors must be able to adeptly defend their edits across many levels of an organization’s hierarchy. Their edits must be based on sound reasoning (or a notation in a style guide) and readability (as defined by the user or audience). To do this successfully, a new editor must make intelligent edits, write helpful and respectful queries, and persuasively communicate the changes to the author(s). These skills allow the editor to assist the author and to advocate for the user without projecting an “I-just-got-my-degree-and-know-it-all” attitude. When a new editor explains her edits to an author, she must do so with tact. And, according to Jennifer Coury, “[Editors] should always be able to gracefully explain [their] edits (either by e-mail or on in person).” Not only should effective editors be able to write clear queries within the document, they should also be able to discuss the emendations with the author through e-mail, in person, or on the phone.

Teamwork

While many technical writers and editors wish they could work alone, it just isn’t so. “Gone are the days when the editor sits alone in a corner, rarely to be approached except in times of grammar crises,” wrote Catherine Rudiger. New editors, especially, must integrate themselves into whatever project, big or small, they need to accomplish. This element requires, as Stephanie Weiss explains, “teamwork, flexibility, follow-through, and project management skills.” All too often, junior employees defer to their more senior colleagues. A successful technical editor, regardless of rank, must communicate clearly to writers of all skill levels and not be intimidated by a person’s degree or seniority. Good communication allows consistent editing of documents across organizational lines and document versions.

Documentation consistency requires an editor to look beyond sentence-level edits to examine page design, template use, layout, and font. With this editing task, a new hire must refer to a style guide or documentation guidelines to maintain the organization’s “look and feel” for documents, whether delivered in e-versions or in hard copy.

Technology

New hires must be familiar with various technologies: Web, content management systems (CMSs), advanced features of word processing, XML/DITA, and FrameMaker, to name only a few. As Jim Purcell wrote, “Nothing irritates writers more than editors who know language but have no idea about technology.” A familiarity with technology allows a new hire to acclimate quickly to a new position without extensive (and expensive) training. With the job market growing ever tighter, new employees in technical writing and editing must demonstrate complex skill sets. This includes, as Christina Bottomley emphasized, “the ability to upload docs to a website, learn a CMS, follow a style guide, and update changes in multiple docs.” An interest in technology helps new hires investigate editing options and delivery methods. It also and keeps them on the cutting edge of software packages.

Translation

In the global economy, technical writers and editors must prepare for their documents to be translated into other languages. With this in mind, an editor must be able to “meet the challenges of creating documents that will be translated” and understand “strategies for keeping translation costs low,” according to Julie Kumasaka. This editing skill involves an eye for consistency in usage and terminology, avoidance of jargon and idioms, and clarity of expression. In addition, a new editor may have to justify these types of edits to an author persuasively and confidently. Furthermore, knowledge of another language aids in the task of translation and deepens an editor’s understanding of English usage.

Conclusion

As I have researched undergraduate technical editing courses across the country, I have found that many address the issues expressed in this discussion This discussion opened my eyes to the complex nature of technical editing and created an avenue for more effective instruction. The editor is ultimately responsible for ensuring the author’s message seamlessly reaches its audience. At times, educators become removed from the work world, and we (educators) need to update our skill set and corporate knowledge. From the detailed comments I received, educators cannot take anything for granted when it comes to preparing undergraduates for “the real world.”

 

The Impact of XML on Technical Editing

Justin Baker

I remember hearing a lot of chatter at the beginning of this decade about something called XML. I remember hearing about the unknown implications for editors: Would the paradigm of structured documentation and single-sourcing models make editors all but obsolete? I saw myself in a museum behind thick glass. Because of this thing called XML, were we all doomed to go the way of the Gutenberg press?

Well, hardly.

I’ve learned a little about XML over the last seven years, and I feel a little more at ease. To understand XML’s impact on technical editing, let’s first look at a brief overview of the major editing phases of linear-based documentation. We will then examine the nature of XML before finally moving on to how XML affects technical editing.

Linear-based documentation (traditionally called paper-based documentation), has three major editing phases in my own mental editing model: (1) Knowledge Editing, (2) Language Editing, and (3) Layout Editing.

  • Knowledge Editing refers to the technical subject matter in a document both in verbal form (words) as well as in visual form (images). I divide Knowledge Editing into four sublevels: Knowledge Accuracy, Knowledge Completeness, Knowledge Logic, and Knowledge Hierarchy. The first two editing sublevels ensure that the subject matter is accurate and complete. The third editing sublevel ensures that the basic logic of the subject matter is sound, and the fourth editing sublevel ensures that the 1.0, 1.1, 1.1.1 hierarchy of the subject matter is sensible.
  • Language Editing refers to the technical subject matter in a document both in verbal form and visual form. Language Editing focuses on the exposition of the knowledge through words and images. Language Editing encompasses sentence structure, grammar, diction, punctuation, spelling, and character mechanics (font and display attributes). Language Editing focuses on the particular standard visual elements to be used in any given type of illustration. For example, for network diagrams, some companies might want to consistently use the same network-server icon. Language Editing ensures that both the verbal language and the visual language are standardized.
  • Layout Editing focuses on the following document areas:
    • Industry-standard, large-scale document page layout patterns (for example, a traditional template for a specific industry project plan)
    • Text and illustration spacing
    • Large-scale font formatting (small-scale, or individual, font formatting is part of character mechanics under Language Editing)
    • Miscellaneous layout mechanisms such as running headers, page numbers, and hyperlinks

Now that I have laid the editing foundation for this examination, let’s examine the nature of XML before we see how it affects the editing model.

XML (eXtensible Markup Language) is a metadata language that allows you to tag a chunk of text with labels that explain the nature of that chunk of text. XML promotes the use of tags that indicate “this is a name” or “this is an inventory part.” XML also controls the structure of a document to a large degree. Using the same set of labels, or XML tags, you can dictate the pattern of particular chunks of text. Perhaps you simply have a set of XML tags that are “heading” and “paragraph.” You can dictate rules for the structure of the document such as a paragraph must always appear right after a heading or a figure can never appear without a caption. The library of XML tags and the organizational rules for their use within a specific document is referred to as a document type definition (DTD) or an XML schema. So, we have tags that describe the nature of chunks of text within a document, and we have restrictions about how the document can be structured.

For the purposes of this article, there is at least one more way that XML can control a document: layout. A complimentary standard of XML called the XML Stylesheet Language (XSL) can dictate how particular XML tags are displayed. While XML focuses on describing the nature of text, XSL dictates whether a chunk of text appears bolded, or centered, or whatever. With XML and XSL, the nature of text and the formatting of text are kept completely separate.

So how does XML affect technical editing? Well, XML doesn’t control every aspect of technical editing to the point that you and I are relegated to the role of spellchecker, but XML does take a significant amount of control away from the technical editor.

How Does XML Affect Knowledge Editing? XML cannot control the accuracy or completeness of text. Unless XML is instilled with artificial intelligence in the future, it never can, and it never will. However, XML does control knowledge logic and hierarchy to a degree. For example, an XML DTD can control whether chunks of text tagged with a paragraph tag can occur after chunks of text tagged with a heading tag. However, XML cannot control the logic and hierarchy within the tagged chunks of text.

The XML DTD may be able to control the structural logic of the text to some rudimentary degree (for example, the pattern of tagged text must be heading-paragraph-heading-paragraph-subparagraph), but it cannot control the substantive logic within a paragraphs or within a sentence. You could have what is called a well-formed XML document, in which the pattern of heading text chunks and paragraph text chunks satisfies the rules of the XML DTD, but those text chunks could contain complete gibberish, and the XML DTD would not know the difference.

How Does XML Affect Language Editing? XML has the least control in this area. You can tag a chunk of text with a paragraph tag, but that tagging cannot control the sentence structure, grammar, diction, punctuation, or spelling. You can still write a horribly structured sentence, and the XML DTD would never know the difference. Bad spelling could also be rampant in an XML document. As part of the style rules in the related XSL, the character mechanics can be controlled: headings can be made to be a particular font size, case, etc.

How Does XML Affect Layout Editing? This is where XML dominates technical editing across the board. Everything within the layout editing can be controlled by the DTD and the DTD-related XSL: industry-standard, large-scale document page layout patterns; specific text and illustration spacing; large-scale font formatting; and miscellaneous layout mechanisms such as running headers, page numbers, and hyperlinks. With a document developed using XML, the technical editor doesn’t need to focus on these layout aspects. XML allows the technical editor to focus on knowledge and language.

As you can see, XML does not relegate technical editors to the trash bin of technical documentation history. Even with the restrictions of XML, technical writers have a lot of room to maneuver, and therefore a lot of room to make mistakes. Where there are mistakes, there are technical editors. Technical editors are still needed to edit for accuracy and completeness, and to a large degree, a human brain is still needed to ensure correct logic and hierarchy. All the traditional language skills are still needed. Layout is governed largely by XML, but, for those of you who always loathed setting margins and making text bold at a 14-point font size, your day of deliverance has come. Until an XML language is developed with an artificial intelligence that can recognize the illogical structure within any given sentence or that two sentences have been turned around, a technical editor will be needed.

General Impressions: “In Praise of Editors”

Last month, on Salon.com, Gary Kamiya wrote a very interesting article titled “Let us now praise editors,” which you can read here: http://www.salon.com/opinion/kamiya/2007/07/24/editing(external link). Janice Gelb sent this article to our discussion list, quoting a few passages from it, and I was surprised that we did not start any discussions around it.

As I finished the article, I was left with a series of questions that I thought we might enjoy discussing. Please feel free to write a comment here to our blog, but please also subscribe to our discussion list, and see what gets going over there.

Here are the questions that this article raised for me:

  • Are editors less confident than writers? Kamiya said that “a good editor needs to be as self-confident as a writer” (mainly because we are dealing in a subjective realm of trying to improve the writing for the reader).
  • Is writing harder than editing? Kamiya said that writing is very creative, whereas editing is reactive. Initially, I agreed with that statement, but upon reflection I’m not so sure.
  • Are editors an endangered species, especially with online and Internet publishing? I’d like to think that those writers, those businesses, those publishers who value high quality writing for their readers will not allow us to go the way of the dodo bird. Kamiya stated: “The art of editing is running against the cultural tide. We are in an age of volume; editing is about refinement. It’s about getting deeper into a piece, its ideas, its structure, its language.” This was one of the few places in the article that Kamiya acknowledged that editing is more than just grammar and style, but it was appropriately located.

Kamiya ends his article by truly singing the praises of editors and suggests, “Someone is noticing. Someone is reading. Someone cares.” I sure hope he is right. What do you think? Is someone noticing?

Editorial Ethics: The Role of the Editor Before Peer Review

Geoff Hart

Editors who work with authors before a manuscript is sent for review face certain challenges. Since we’re often the first to see a manuscript, we sometimes encounter problems we must help solve before they come back to bite the author.

These problems fall into a variety of categories, of which I see three repeatedly in my work:

  • Content
  • Logic
  • Plagiarism

In this article, I’ll discuss the nature of these problems, provide examples from my own career as a science editor, and suggest how similar problems might arise in other types of editing. I’ll conclude with some thoughts on how to confront the problems in an efficient, positive manner.

Problems with the content

Over the years, I’ve found that the more editing work I do, the more poorly designed scientific studies I discover. Once the science is complete, often after several years of fieldwork, there’s nothing much that can be done about the problems with the study. Instead, I have to deal with the consequences: something that may appear unpublishable, at least at first glance, because of seemingly fatal flaws in the experimental design. The equivalent in other branches of technical communication might be working with beginner authors or with professionals such as engineers for whom writing is a distant last in their list of priorities—or skills. The situation may be compounded by tight deadlines that prevent the authors from going back and fixing things.

As an editor, I can’t solve these problems, and in some cases, it’s doubtful whether I have the expertise to justify trying. What I can do is try to ensure that the flaws are not hidden and to suggest coping strategies that might mitigate the flaws. For example, I routinely advise authors that it’s wise to be open and honest about flaws in their study rather than trying to conceal those flaws. The peer reviewers chosen by science journals are generally every bit as smart as the author; indeed, they’re specially chosen for their expertise in a subject, and for their willingness to pounce on the slightest flaw in a paper. Many also look carefully for any appearance of unethical behavior, and will pounce even harder on authors who are trying to conceal a serious flaw or claim better results than their data justify. An author who, despite my advice, insists on concealing flaws in their research, inevitably ends up wasting several months waiting for the results of the peer review, the reviewer will force them to do what I told them to do in the first place and resubmit the manuscript for another round of review, hoping that the changes will now be acceptable to the reviewer. Why not save those months by stating up front that the research needs to be confirmed with additional data and specifying any flaws that must be addressed and resolved through future research? All scientists understand and accept the fact that it’s sometimes necessary to discover better ways to do research by screwing up an initial study.

Similar situations arise in other forms of technical communication. Take, for example, the autonumbering feature in Microsoft Word, which is broadly known to have stopped working more than 10 years ago. Microsoft’s refusal to fix this buggy feature is understandable; the bug is rooted so deeply in the plumbing of Word that trying to fix it might destabilize other, more important features of the software, which is something Microsoft simply can’t afford to do. An even more serious problem lies in the Master Document feature, which can actually cause serious file corruption and data loss (http://word.mvps.org/FAQs/General/WhyMasterDocsCorrupt.htm(external link)) — unlike the autonumbering bug, which causes only frustration and wasted time. Refusing to acknowledge these problems is one thing. But retaining the features both in the software and in the user documentation is unethical. Well-known solutions exist to both bugs, using nothing more than the features already present in Word. That being the case, why not recommend using these solutions instead of solutions that don’t work? That would be a more ethical way to proceed. Unfortunately, this example illustrates the problem faced by many editors: we lack the power to do anything more than raise a problem and propose a solution, and very few of us have the luxury of being able to resign and go elsewhere if that solution is not accepted.

Problems with logic

Every so often, we find ourselves in the happy situation of knowing more than our author, and having a chance to save an author from looking foolish. One paper I edited by an eminent Asian scientist proposed a perfectly plausible explanation for the author’s experimental results. There was just one small problem: the author had neglected a simpler explanation that was every bit as logical, and failing to at least mention that alternative explanation would have humiliated the author before an audience of their peers. (This knowledge was the kind of thing any graduate student should have been aware of, and that any peer reviewer would leap upon as an explanation. I’ve been deliberately vague here in describing the problem because I would hate for the author in question to come across this article.) It took me nearly half an hour to frame an explanation of the problem in such a way as to spare the author loss of face, and it was a great pleasure in subsequent years to see the author including my explanation in his other papers.

In scientific publishing, it’s the responsibility of journal reviewers to reject bad science or faulty logic, so when I’m right and an author still ignores my advice, I can usually be confident they’ll receive similar advice from someone (i.e., the journal) with the authority to force them to take the comment seriously. I can satisfy my ethical responsibilities by raising the problem, explaining its consequences, and doing my best to persuade the author to deal with it honestly and well; I know that if I don’t succeed, someone else will do the job for me. (“Giving up” would be less ethically acceptable when you’re the last person who will see the manuscript before it is published, but as in my previous example, sometimes we have no choice but to accept that we can’t change the situation.) In other branches of technical communication, we may lack this kind of built-in quality control process, and it becomes a considerably more serious problem. If we know a product is unusable or potentially even dangerous, and we cannot persuade its developers to fix the problem, the problem may appear only once the product hits the market—at which point the real world has its say: purchasers reject the project, leading to potentially large lost sales, or possibly someone is injured and the lawyers get involved, leading to potentially large punitive fines. In such cases, ethics force us to at least consider going around a recalcitrant author or developer and making our case to their manager. Sometimes we may even need to ask ourselves whether we should leak a problem to the press to ensure that action is taken before a problem arises, not after.

Potential plagiarism

Most of us encounter a greater or lesser degree of plagiarism at some point in our careers. That’s particularly true if we work with authors for whom English is a second language, since they may lack the skill to create fluent English sentences by themselves and thus have a greater incentive to simply copy someone else’s wording. Other authors, including those for whom English is a first language, simply don’t understand copyright, and believe that it’s acceptable to create an entire document out of other people’s sentences so long as they attribute the source of the text. In most cases, it’s not; at a minimum, direct quotations should appear between paired quotation marks, and an entire manuscript filled with thickets of quotation marks would, at best, look unusual. In each case, we must be alert to the potential problems that may arise—ranging from simple embarrassment to serious legal consequences.

In one particularly memorable case, an author I was working for decided to try publishing essentially identical papers in two journals. (This is often referred to as self-plagiarism.) Journals, predictably, aren’t fond of this practice because it deprives them of unique content when another journal publishes the same paper; it’s also seen as a sly and inappropriate way to pad the list of publications in one’s résumé. When I recognized what was happening, I informed the author of the problem, and explained that whether or not he agreed with my take on the ethics of the situation, it was an unwise trick to play; he was writing in a specialized field where the odds were high that the same peer reviewers would be chosen by both journals. The author ignored my advice, and sure enough, was caught. Both papers were rejected. In addition, one journal warned the author that all future articles he submitted would be carefully screened.

In fields such as science, much of the discourse is built upon citing other people’s studies and comparing one’s own results with those studies. This is standard practice and covered under the doctrine of fair use. So long as an author attributes the original author’s words or data by citing the source, they’re generally following the letter of the law and the standard practice of their discipline. In such cases, we can often reach a compromise in which we modify some of the original wording (as is expected in our role as editor) to create a paraphrase of the original words and ensure that the source is cited. This allows the author to keep their words, satisfy ethics by acknowledging the source of the words, and avoid potential legal entanglements.

Depending on the nature of the job, it’s not necessarily our formal responsibility (as part of our job description or a contract signed with a client) to go looking for such problems. But even if it isn’t, it’s our responsibility to inform the author of such problems when we find them. Finding them often isn’t all that hard. For example, when working with many of my foreign authors, quoted text often stands out clearly from its surroundings because it has an entirely different voice from the rest of the paper and uses words that (based on the word use in the rest of the manuscript) I wouldn’t expect the author to have in their vocabulary. Given the number of papers currently available online, particularly as “pre-publication” versions that authors post on their own Web sites before they sign over copyright to a publisher, a quick Google of the suspicious phrase often turns up its source.

Often, we cannot force the author to do anything about this, and often we can find ourselves in deep waters if we try too hard. A few years ago, a friend nearly got herself fired when she reported that a senior manager at her company had plagiarized something in a way that was almost certain to lead to legal action against the company; by raising the issue and pursuing it in a highly ethical manner, she saved her employer from a significant problem, but in so doing, stepped on some powerful and unforgiving toes.

Breaking the bad news diplomatically

As editors, we rarely have the authority to force an author to fix a problem, and even when we do, “force” is rarely the right solution. Instead, it’s better to work with the author in such a way that we’re seen as an ally, not an obstacle. As illustrated in my examples (ignoring a field of inquiry in a literature review, an inadequate study design, plagiarism), the solution often lies in explaining the problem in such a way that its importance and the consequences are clear to the author, then providing suggestions that help the author solve the problem. If we make our solution sufficiently easy to accept, then it’s easier for authors to accept the solution than it is to fight us over the issue. In the case of plagiarism, wording such as the following might suffice:

“While I was researching concept to ensure that I understood what you were saying, I noticed that this complete sentence was taken, without modification, from reference. Although this practice is borderline acceptable if you cite the original source, it is considered plagiarism by many publishers, and may cause you serious trouble during the review process. For example, there is a significant risk that the author of the paper you are quoting will be one of the peer reviewers selected by the journal, and when they recognize their own words, they are likely to ask the journal to reject your paper and possibly even reject future papers that you submit. My advice is to rewrite the sentence as follows proposed new wording, rewrite it in your own words, or place the entire sentence in quotation marks; whichever solution you choose, you must provide a literature citation that defines the source of the text. Reviewers like to see their own work quoted, and are more likely to accept your manuscript if you do so.”

The goal is to carefully raise the issue, always with an emphasis on helping the author avoid trouble. Sometimes, you can’t succeed, as in the case of self-plagiarism that I described. In that case, it may be acceptable to allow the standard quality control process to solve the problem for you; in my example, the journal’s peer review process filled that need, but in the workplace, a quiet word to one of the managers or others who will sign off on a review can at least focus their attention on the problem. In other cases, the solution requires us to understand what factors will make the author take our advice seriously.

For most of us, it’s easy to believe that the consequences of such ethical questions are small potatoes in the larger scheme of things, and to pass responsibility for solving the problems to someone else. The temptation to do so is even stronger when we’re under deadline pressure or when we fear that we’ll get ourselves in trouble by making too much noise. Unfortunately, this abdication of our responsibility sometimes leads to very serious consequences indeed. The loss of the space shuttle Challenger and death of all its crew (http://en.wikipedia.org/wiki/Space_Shuttle_Challenger_Disaster(external link)) illustrates the consequences of a failure to make the necessary effort. The Challenger disaster had many causes, and there have been many detailed examinations of the causes of the disaster. I’m not an authority on the consensus opinion of all these studies, however I recently came across an intriguing explanation that hasn’t been explored perhaps as deeply as it should have been. In this case, the author challenged the conventional explanation that the engineers did not clearly explain the risk of launching the shuttle, instead proposing that the managers who made the decision were governed by economic considerations (they needed a successful launch to demonstrate the reliability of their rocket engines and secure additional contracts). Is this true? Possibly. But I find it hard to believe that any manager could have ignored a recommendation in which the consequences were clear:

“We all believe that if you launch the shuttle, you are likely to kill all its astronauts. The technical reasons for this are spelled out in Appendix 1. That’s bad enough, but you will also set back manned space exploration for many months, if not years [the actual delay was nearly 3 years], and will do irreparable damage to our company’s reputation, ensuring the loss of the contracts you hope to gain by launching the shuttle tomorrow despite our warnings. In this context, we are confident that delaying the launch by 1 to 2 additional days will be a minor problem, and we recommend that the launch be delayed.”

As in the case of my friend who nearly lost her job for blowing the whistle on plagiarism, this wording would not have gained the engineers any friends, but it would have saved several lives and protected the company against considerable lost income too, thus soothing some of the sting of the painfully direct wording.

If you’re lucky, most ethical problems that you face as an editor will be far less severe. But as I’ve illustrated in this article, it’s unwise (not to mention unethical) to simply assume someone else will spot and fix ethical problems for us.

Paper, Screen, or Scissors? Editing on Hard Copy or Soft Copy

Tim Slager

The question posted in our discussion list: Should editors edit on hard copy or soft copy? The answer: Yes. Or, it depends. Essentially it is not a matter of should; it is a matter of personal preference and what works best in different situations.
The exchange on the STC Technical Editing SIG discussion list in response to this question went on for several days and included 20 posts, which is higher than average for our moderate-traffic list. Apparently, we tend to be passionate about how we do what we do.

Hard Copy

On one side are those who print a copy and mark it up. Several people mentioned that they notice more errors when they edit hard-copy documents. Hard copy also has these advantages:

  • Easier to flip back and forth to compare for consistency
  • Very portable
  • Easier to see punctuation marks and spelling errors
  • Easier on the eyes
  • Less risk of computer-related stress injury for the editor
  • Easier to mark suggested moves of text
  • Often easier to see corrections in contrasting ink

But the tide is turning, even for those who prefer hard copy. Some people will compromise by marking up hard copy, and then scanning it to make a PDF file. One poster likes to edit hard copy and make changes in soft copy. Another marks up the hard copy and then transcribes comments to soft copy, both for legibility and to tone down “intemperate remarks” (on those rare occasions when one makes it onto paper).

Ultimately, it’s a matter of taste: an “online version of the document is helpful…but I still prefer to deliver markup on hard copy.” One poster still prefers “my trusty red pen.” Another suggests: “Perhaps that is in part due to eyesight issues and in part due to lifelong habits and learning modes.” Some prefer “a quieter, slower paced approach,” and believe it leads to better quality.

Soft Copy

Not everyone wants a slower paced approach, however. When there is a lot of work to be done, speed counts. For some, hard copy may be the preferred approach, but “time and cost considerations” take precedence and “in my current job, I work most often with soft copies.” Several noted that soft copy is faster, and time is money. “Online editing is a cost-saving measure,” said one poster “I can return a document for author review in nearly half the time it takes the other editors.”

The “flipping back and forth” in hard copy can be distracting to some. You might notice structural problems that, in some cases, are better left alone.

The tools that are available with a computer offer a big advantage to online editing. Several people noted that searching for repeated problems is easy with soft copy. One commented, “I’m sure I provide better edits now that I have access to PDF files” for searching. Change tracking tools can be troublesome at times but allow writers to view markups in much the same way they can with hard copy.

Certainly, for many of us soft-copy editing is a big part of our job responsibilities. In fact, later posts in the thread turned mostly to an exchange of advice for how to work with Adobe Acrobat, Word, and other online editing tools as well as with document management and version control software.

One editor took a job on the condition that she could “continue working… completely online.” She goes on to say, “I definitely prefer soft-copy edits, and will do a hard-copy edit only when specifically requested by the author.”

Another noted, “I’ll edit on hard copy if I have to, but I much prefer soft copy at this point.” I sense some ambivalence here, though: was there a change in preference? Someone else perceived that “younger team members do prefer soft copy; it seems they are more comfortable with the technique and it is quicker for them.”

There’s More Than One Way to Do Things

The person who observed the preference of younger editors for soft copy, counters by noting that “many others my age or older might still prefer hard copy.” Different people and different circumstances call for different approaches.

One editor summarizes it like this: “Both types of editing can yield acceptable results. As to preferences, different editors will give you different answers. I might give you a different answer at different times, depending on what I’m doing and how I’m feeling.”

Another says, “I think that both are acceptable….I prefer to edit hard copies when proofreading but I vastly prefer soft copies for comprehensive editing.”

This either-or view seems to characterize the variety in the larger community of editors. No one implies that their approach is the only one.

There seems to be a general, if at times reluctant, sense that the move is toward more online editing. One post states that the choice of software that is used for soft copy editing is pivotal, and that such tools keep improving. It concludes with, “I doubt that there was much serious copy editing going on at PC screens 20 years ago, but ten years from now doing it on paper might also be a relative rarity.”

The first response to the question of which method was better begins with what sounds like a hard-line opinion: “Editing hard copy is best.” But this same post ends with “I edit by reading hard copy and making changes in soft copy. That seems to combine the best of the choices. Hope this opinionated answer helps.”

In the end, it seems to be a split opinion.