It is imperative for every editor to have certain tools and techniques handy when embarking on an editorial journey. With tools, I don’t mean the omnipresent grammar and spell checks, track changes, and commenting tools, though these are essentials for any editor. I am talking about specific tools that the editor must ask for or create before starting any editing job. The Tool Kit a technical editor must always seek two things from the writers’ they are editing for:
- A style guide, specific for the project in question
- A reviewer’s checklist, based on the aforementioned style guide
If the writer offers a generic style guide, for instance, the Microsoft Manual of Style, it is the editor’s job to ask for specifics from the guide that are relevant to the project and most importantly ask for exceptions, if any. It is my experience that most writing jobs start with an industry-popular style guide as the baseline but eventually exceptions and nuances relevant to the project start emerging. A competent writer makes a note of these deviations and compiles a project or company-specific style guide. If the writer hasn’t been able to do so, a safe-and-sure editor will commence any editing job only after interviewing the writer and making note of all peculiarities and particulars of the styles and editorial standards to be followed. Many times these may be notes or emails that are shared, or forwarded to the editor; whatever be the format, the editor has to put these together in one place and then only start editing.
In most companies, compiling (if not creating) an editorial style guide with effective writing guidelines is the job of the editor. A documented style guide enables:
- A writer to create a good document from the start
- An editor to make consistent and comprehensive review observations
- Both to agree on most items that may require corrections, thus reducing conflicts
Creating a wiki style guide using Microsoft SharePoint can be an effective way to keep on adding items to the style guide in a collaborative environment, using version control. Maintaining a standard terminology list or an abbreviations list, grammar and usage pet peeves, and any such items that can be tackled at the writing phase, ensure that the editor spends more time on significant aspects of a document, while also keeping a tab on these.
A style guide is usually an elaborate document, more so, if you are using a popular style guide that runs into hundreds of pages. And if you add project-specific exceptions, there is more material than any writer or editor can internalize in one go, or use effectively in the heat of a writing/editing project. A review checklist is a handy tool that enables writers and editors to make a note of project-specifics in an MS Excel sheet or Acrobat form, and use them to cross-check items as they go along. For instance, I use individual review checklists for page helps because I need to check for HTML related items and have another one for user manuals to keep a check on final PDF properties.
As a writing and editing professional, I have always encouraged the creation and use of review checklists for self-reviews and peer-edits. A master review checklist should be created using the prescribed style guide. Customized checklists should be created for each and every assignment, for each project will have at least one exception, even if it is in the nomenclature of the document. A customized checklist enables the writer to ensure that all unique items are listed and when this checklist is handed over to the editor, the latter knows exactly what to look for. Relevant dates can be included in the checklist. Of course, if the writer is not maintaining a review checklist, it is the editor’s onus to create one and dig out any deviations after conversation with the writer.
The Editing Technique
Each editor has a unique style of editing and reviewing. Listed here are some generic techniques that can benefit any editor:
- Ask for timelines and expectations: Always talk to the writer and get a clarity on when the comments are expected back, the source documents, the SMEs, the product, the style guide, the review checklist, and specifically ask for anything that may be unique to the assignment. Start your work only after you are clear on how much time you have and the extent of review the writer is expecting. All other items can help you get clarifications, as needed, especially if the writer is not immediately available to handle your questions.
- Use consistent commenting blurbs: Don’t make a document bleed by using all sorts of colors, font sizes and blurbs. Choose a couple of commenting identifiers and stick to them, for example a highlight for a wrong spelling and a comment box for an illustration.
- Proofread: Review each word for typos and usage, and each sentence for context, grammar, and tone. Do these before you actually start reviewing the document for usage and technical accuracy and before editing for content organization, document structure, and flow. This ensures that when you actually start editing, you are not distracted by issues you have already proofread.
- Read backwards: At the proofreading stage it can be beneficial to read backwards, for example, from the last paragraph on the page to the first. This safeguards an industrious editor from the temptations of editing, when the need is of proofreading.
- Do not rely solely on the spell check: Before you run the spell check or enable autocorrect, ensure you have selected the correct dictionary – US, UK, International, or as relevant. Add words to the dictionary as you go along and always run the spell check. But do not rely blindly on the spell check. There are always typos that the spell check does not identify.
- Do not ignore graphics and captions: Don’t get sucked into the vortex of words. Give due respect to the graphical elements, table headings, figures and captions, for they hide a number of inadvertent errors.
- Take a break: Before each stage of proof reading, reviewing, and editing, take a break so as to clear your mind of the cobwebs of words and to be able to look at the document with a fresh perspective.
- Zoom a page or take a print: Use a higher zoom percentage or take a print out, if the document is not too large. Read aloud, if possible. It is easier to identify errors in a printed version but this may not be a feasible way to review and logging comments in a soft copy is always easier and better. As a stickler for the Save Paper movement, I do not prefer taking print, but I do view a document in various preview percentages. Have you observed that when you look at a presentation at the projected screen during a meeting you are able to identify errors that didn’t seem to exist on your computer! Well, this is the zoom effect.
- Use and test: Check a document for usability, if it contains procedures and test it to see if everything that’s in there makes sense to you as a reader. If a procedure does not enable you to perform the desired action, or if you can’t make sense of what a sentence intends to say, chances are the end users are not going to be happy campers.
- Comment appropriately: Maintain a tone of courtesy in your comments. Do not attack, do not react, do not lose your cool, and remember that if it sounds rude to you, it will sound rude to the writer. Phrase comments as questions or suggestions, and, when possible, give logical reasons for your comments. Courteous and logical comments are easier to accept by the writer. Comments in a soft copy version are also easier to tackle.
- Stop before you send: Do not click the Send button as yet. Close the reviewed document and look at it again the next day. Read your comments. Edit a few comments that may be complex or sound impolite. Combine a few as global comments to reduce the comment count. Eliminate a few, if it can be done and identify a few more, if you can. Basically, edit your editorial comments. Give it a thought, give it some time, and then only send it to the writer.
- Keep a review log: Time permitting, a review log should be maintained and shared after each review. It is a record of defects and the reason behind them, thus helping a writer to reduce similar defects in upcoming work. It can be used to generate quality control metrics and give a formal credence to the acceptance of review comments.
That brings us to the end of all that I had to share about effective editing tools and techniques. Since, we end this article with a mention of review logs, it may be interesting to explore classification and logging of defects, and using them as an effective metrics for documentation control, in our next issue.
About the Author
Aneesha Myles Shewani is Manager, Technical Editing, working primarily on application user manuals, page helps and end-user training material. She is currently employed with Fiserv and has expertise in establishing style guides and editorial standards for print, online, and mobile media. Aneesha is part of the STC India, Editing Special Interest Group, as Ideation Manager for 2014. She spends her leisure time in reading and writing about a variety of topics, ranging from historical literature to science fiction. Aneesha also writes fiction and some of her work can be read on her blog: www.felinemusings.com.
One Comment
Comments are closed.