Book Review of “Effective Onscreen Editing” by Geoff Hart

Virginia Janzig

Geoff Hart’s book, Effective Onscreen Editing (Diaskeuasis Publishing, © 2007), is a readable and useful addition to the general literature on how to be a good editor.

Editor’s Note: To learn more about the book: http://www.geoff-hart.com/home/onscreen-book.htm(external link). To purchase a copy of the book: http://www.geoff-hart.com/download/buy-eoe-book.htm(external link). Geoff is currently revising the book to incorporate review comments that he’s received, fix some infelicitous wording, and incorporate some new stuff he’s discovered since the book was released. Details of these changes and corrections at: http://www.geoff-hart.com/resources/eoe-may2007-errata.htm(external link). The new version should be available online by 11 January 2008 if all goes well. At that time, all purchasers of the previous version will be contacted and offered a free upgrade to the new version.

His main points are that onscreen editing can be fast and effective and can reduce errors when edits are incorporated.

Three of the main topics of the book are what onscreen editing is, what its advantages are, and how to implement it for yourself and introduce it to your team. The focus of the book is how to edit onscreen using Word for either the PC or the Mac.

The book describes using the software tools, editing nonstandard files, editing with software other than Word, finding and using research sources, and safeguarding your work and health. Other topics include information on working with clients and additional detail about Word software.

The book has two primary audiences:

  • Those who have never edited onscreen and need to know how and where to begin, how to be effective, and how to use the tools
  • Those who are currently editing onscreen but want hints and tips on how to be more effective, both with tools and with clients

Most of the information on tools, basic editing techniques, Internet resources, security information, and health concerns is available but can only be found in separate sources. Geoff Hart’s contribution is to bring these topics together in one manageable book and to explain them from an editor’s point of view. He has done an excellent job of describing not only how to be an effective onscreen editor, but also why this methodology is advantageous to our profession. Those managers and editors who are new to this kind of editing can use this book as a set of guidelines to help them understand why and how to implement this technique. Those who already are familiar with onscreen editing can browse to find specific information on new tools, new ways to use familiar tools, how to work with nonstandard files, and much more.

The book has a strong emphasis from the point of view of an independent editor and provides a great deal of information on working with clients. Many of the issues are not relevant to editors in a corporate environment but can be easily passed over.

The chapters on tools, resources, and security provide clear procedures and workarounds. Geoff Hart covers all the tools in Word and how to use them effectively and efficiently. I knew many of them but was surprised and delighted to find some new ones. I also found several ways to improve my use of some of my current tools, such as search techniques, creating effective comments, and using style sheets and exclusion dictionaries. In most cases, I had to test several of the recommendations, which slowed down my reading, but proved that the time and effort were well worth it. For example, on page 215:

“Word offers a nifty shortcut that can quickly reveal whether a global search and replace operation would be safe. Type the search term in the “Find what” field. Then select the option “Highlight all items found in”, immediately below this field, and use the dropdown menu to specify where Word should search for that term (e.g., the main document, headers and footers, comments). Clicking the “Find All” button will highlight all matches in the text in a single step.”

The differences between the PC and the Mac are clear and helpful and are not disruptive. He also covered other software, which makes the book more valuable, especially if you are working with clients who have older or less conventional systems.

Overall, he had good discussions of various editing techniques and especially of Internet resources: how to find them, how to use them, and how to establish the credibility of the source. For example, on page 410:

“As a general rule, give precedence to sites with clear and rigorous editorial policies for controlling the quality of their data.”

In particular, I was pleased to find excellent suggestions for editing less common files, including databases and spreadsheets, as well as Web pages, ASCII, and RTF files. The information also covers editing different tagging languages such as SGML and SML. For example, on page 336:

“The key to opening our horizons wide is the following: most applications, in addition to saving files in their own proprietary format, can also save their files in a range of other formats.”

One of the most important chapters was on the need to save and back up work regularly, as well as make external copies. This chapter also included valuable information on confidentiality, for the client as well as for you.

I do have a few minor criticisms. Three chapters seemed out of place. Chapter 3 is about client relationships, not directly with onscreen editing. It’s important, but I would have made it an appendix. Chapter 13 is about Internet resources. Again, this material is important, but it is not directly part of the onscreen editing process. I would have put it either after the safeguard information or in the appendix portion. Chapter 15 concerns information on backups, upgrades, confidentiality. This information is important information, but it is placed between two chapters directly addressing onscreen editing. I would have made this the last chapter before the two chapters on how to get started with onscreen editing.

I struggled a little with the overuse of long sentences with semicolons. The sentences were all grammatically correct (although I object to the use of “then” as a conjunction). But I found that the long sentences were harder to read, and I frequently had to go back to reread the second clause to make sure that I understood the point.

But these criticisms do not take away from the value of the book. None of the information is extraneous. It is written to editors (and managers) by an experienced editor who has clearly drawn together all the pieces of the work environment that we face daily. He has explained how to make our work easier and more valuable, and has given us a lifeline in a field in which we all sometimes feel we are flailing alone and in the dark. Thank you, Geoff.

Alrighty Then

Danica Rhoades

Sometimes editors need to vent. They need to get a little validation for their feelings. They need to know the crazed need-to-scribble-all-over-a-document-before-shredding-it sensations that soar through their weary minds and bodies when they see the same “wrong” writing repeatedly are normal (sort of)! Luckily, the Technical Editing SIG’s discussion board gives editors the opportunity to do just that.

Recently, a frustrated member provided the following example and question:

“Do procedure A, then do procedure B.

Anyone want to guess what it is about this structure that is driving me nuts?”

The language-savvy members of the SIG were quick to identify the issue: the use of “then” as a conjunction.

While the issue wasn’t tough for the group to pick out, it was somewhat more challenging for them to identify how to deal with it (if in fact it needs to be dealt with). In all, the responses fell into three categories (each assigned a pop-culture title used as a heading below):

  1. Alrighty Then: “Then” as a conjunction is okay, even necessary, in some circumstances.
  2. Then There Were None: “Then” should never be used as a conjunction.
  3. And Then: “Then” should follow “and” to eliminate the issue.

 

Alrighty Then

Multiple discussion participants noted that they use “then” as a conjunction when the second sentence is short.

That said, with procedural writing, there was division among the group.

One member noted a preference for using parallel construction with numbered or bulleted statements, such as this example:

  1. Open the folder.
  2. Copy the contents.
  3. Paste the files into a new location.

Another member argued that the absence of compound statements could change the meaning in a procedural document, such as with these examples:

  1. Remove the four screws securing the print engine to the applicator and then remove the print engine from the applicator.

OR

  1. Remove the four screws securing the print engine to the applicator.
  2. Remove the print engine from the applicator.

This member noted that when the fourth screw is removed, the user needs to have something supporting the print engine or it will crash down, damaging the user and/or the print engine.

Then There Were None

Grammatically speaking, “then” is an adverb, a noun, or an adjective.

Another reason cited for not using “then” as a conjunction was that it hinders readability/comprehension. There can be nuances in meaning in certain contexts or environments. Editors who know their audiences well might elect to use “then” in this manner, but this often slows comprehension.

And Then

The supporters of the “and then” construction share the previously mentioned notion that compound ideas are sometimes necessary. For example, simple steps are often combined in prose in this fashion:

“Open the document, and then click File > Save As.”

A related problem was also identified; using “and” to connect to elements that are not simultaneous:

“Type the file name and click OK.”

Some international readers and translation software read this sentence to mean:

“Type the file name while you click OK.”

The “and then” facet of the group noted the most common way to deal with both the “and” and “then” issues is to use “and then”:

“Type the file name, and then click OK.”

Other Issues to Consider

Regardless of your personal stance on whether “then” is acceptable as a conjunction, there are additional issues that can complicate the situation. For instance: documents that are translated. The irregular use of “then” can create issues for the person translating and for the users of that document. In other situations, “then” can lend ambiguity if there is no “if” preceding the “then.”

Overall, the general sense was that it is most important for the editors to understand their audiences’ understanding and needs. Many documents work well with less-formal language, while others could cause injury or result in broken products if the language is not extremely clear and precise.

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.

General Impressions: “The Technical Editor as Diplomat…”

Michelle Corbin

I recently re-read the journal article “The Technical Editor as Diplomat: Linguistic Strategies for Balancing Clarity and Politeness” by Mackiewicz and Riley (Technical Communication, Volume 50, Number 1, February 2003, pp. 83-94(external link)).

This article discusses 8 different strategies, based on linguistics research, for balancing clarity and politeness when making editing comments, in the hopes of building and enhancing the author-editor relationship. Although I do not agree with all of the strategies and conclusions that the authors make, I did find it a fascinating article – one that made me actually think about and try to articulate my own thoughts on the role that politeness plays when I make my editing comments.

Although this is not a recently published article, I thought it might be nice to use it to kick off this new type of newsletter article in the Technical Editing SIG blog/newsletter. We receive so much information that it is difficult to know what to take the time to read, and the SIG is trying to help you make a decision as to whether to read an article or not – we want to entice and encourage you to read these articles (and who knows, maybe join a conversation about them on the blog or in our discussion list!).

Do you remember reading this article? Did this entice you into reading it (or re-reading it)? Do you have some thoughts about this article? Please consider sharing them on our blog or as part of our discussion list (I decided to cross-post this to both places, in hopes of encouraging cross-reading/cross-participation in our blog and discussion lists. (:biggrin:) ).