by Michelle Corbin, co-manager 

Hello SIG members!  It’s been a week since I returned home from the Technical Communication Summit, and I have recovered from the time away from the office and I wanted to share a few tidbits from the conference.

We attended leadership day on Sunday, and gathered invaluable information that will help us plan our next set of activities.  I learned a great definition of leadership from incoming president, Linda Oestreich:  “Leadership is the ability to cause others to act in desired ways for the benefit of the organization.”  Ultimately, each community leader was encouraged to determine what we wanted to do from year to year, and then just go do it;  that is, don’t do everything and don’t do what you think you “should” do, but just do what your members want you to do and do what your volunteers sign up to do.  So, Technical Editing SIG members, what do you want us to do? 

We had a very interesting keynote speaker, Simon Singh, who spoke about the making of his documentary about a mathematician solving the proof for an age-old mathematical equation. Although the specifics and details about that mathematical equation did not stick, I did take away two things from listening to his experiences – first, when choosing to edit something, you must consider the audience and context and make sure that it is right, and second, the technical accuracy of your content is critical as you run the risk of losing your audience’s trust.

A very popular session this year (as in past years) was “The Myths and Trends in the Changing English Language.”They talked through several common issues, such as ending a sentence with a preposition, use of the serial comma, and passive voice.  As a fellow “word nerd,” this session was a light-hearted treat, where I got to learn what “snarky” meant.  My one golden nugget from this session was to be reminded that “goodwill is more important than being right.”  As editors, we sometimes need the goodwill more than the rightness of a rule or guideline.

The Technical Editing SIG had its own session of progression table topics — all about editing!  Many thanks to our moderator, Diane Feldman, who helped coordinate these topics with the help of you, our SIG members!  Each table was full each time, and everyone seemed to really engage in the conversations.  Perhaps each presenter might consider summarizing their session in an article for our blog and newsletter! 

The closing keynote speaker (yes, we got two keynotes this year) was Ze Frank, who told two great stories about the designs of airline safety cards and about “accelerated anxiety” and the changing landscape of how everyone wants to join the media conversation – the explosion of blogs, MySpace, YouTube, etc.  He is a designer at heart, but an excellent communicator through his designs.  I laughed out loud frequently and left the conference with a smile on my face.

Although I attended other technical sessions, which I might try to summarize in other posts or articles, I wanted to highlight these above from my experience at the conference.   Did you attend the conference?  What was your favorite session?  Please consider sharing your experiences with our other SIG members!

By Justin Baker, Senior Member

Reprinted from “Capital Letter,” the newsletter of the Washington, D.C. chapter of STC, by permission of author and editor.

What’s in a name? A lot. As technical editors, we know the importance of ensuring that the text we edit is clear. If we are performing developmental editing or copy (language) editing, we know that concepts must be expressed in such a way that the reader does not have to stop and figure out what is being said. We know that the more times a reader has to stop in a text to figure something out, the less the chance that the reader will leave the text with a solid understanding.

There are many elements to look for when editing a text at the development level or language level. One of these elements is terminology. The precise use of terminology is important. The more precise the terms, the more economical and efficient the text (Strunk and White, anyone?). The precise use of terms keeps text uncluttered and makes language more interesting to read and, in some cases, more valuable: the precise use of terms can make a text pregnant with meaning.

All of this, of course, applies to technical terms as well. Sometimes technical terms are misused. Other times a concept or model outgrows the original terms that were used to describe it. This is the case with the terms paper-based documentation and online documentation. These terms have been established in the technical-communication lexicon for years. The logic of their meaning was clear at the time that they emerged in the 1980s and early 90s: in addition to the centuries-old paper document, we also now had documentation on a computer (online). But these terms came into existence before the World Wide Web became dominant and hypertext became the norm for online documents, therefore eschewing the traditional linear, narrative structure.

In the days when text-based interfaces still existed, online documentation was much like paper-based documentation: it had a linear, narrative structure with traditional cross-references that did not lead a reader off on an entirely different path from the original text. At the time, it made sense to use the terms paper-based documentation and online documentation, because the only difference between the two was in their output: one was on paper, and the other was on a computer.

In the 1990s, the World Wide Web became a huge presence in the world of documentation. Because of hyperlinks, the term online documentation began to primarily mean a document that was not necessarily read in linear fashion. The term began to refer to the structure of a document, rather than the medium in which it was published. But the newer, predominant definition of online documentation conflicted with the older definition, which still existed.

These conflicting definitions have opened up a can of worms. Is it online documentation only if it has a hyperlinked structure? Is it online documentation if it is a document designed for print but posted to a Web site as a PDF document? Then there’s the quandary of whether a Web site that is printed out on paper is paper-based documentation or still online documentation.

From this confusion emerges the idea that perhaps it is not best to define a document by its published form. Perhaps it would be better to define a document by its structure—linear documentation or Web-based documentation. If you publish a traditional report on paper or post it to a Web site as a PDF document, it still has a linear structure. Even if you print an HTML document published on a Web site, that document still has a Web structure with hyperlinks, and the author’s intention is that readers will carve out their own narrative (logical) path. One could argue that the Web-based structure of the document is no longer present once it has been printed on paper, since you can’t click a hyperlink on a piece of paper. This is why I have included the author’s intention as part of the definition; if the author intends for readers to carve out their own narrative path, then the document still possesses a Web-based structure. And I argue that this contrasts with a traditional text that has many footnotes. The author of such a text intends for the reader to read in a primarily linear fashion, even if that reader skips ahead to other chapters. The text is still linear.

As technical editors and as members of a technical communication society, we may never be able to turn the tide of usage in the general business community. However, we should strive to use the most accurate terminology, at least within our own profession and communities. Electrical engineers strive to use the most precise terms in their field because it makes their communication more efficient. As technical editors and communicators, we must ensure that such precise language is used in all disciplines in which our work is based.

It is time to change the terms used to describe the different models of documentation. No more paper-based and online. It’s time for linear documentation and Web-based documentation. We as technical editors with our proverbial red pens have the power to help steer this change.

Justin Baker has been a technical writer and editor for nine years. You can reach him at bakerjustin@earthlink.net.

A discussion list summary article by 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.

A discussion list summary article, by Abby Kasper 

As writers, we are constantly challenged to rethink our writing styles and improve the way we present information to global audiences. Recently, the following question stimulated an animated discussion in the discussion list community.

We are considering changing the style we use to introduce a procedure. Does anyone have thoughts about the pros and cons of either of the following styles:

[conceptual overview of a task; for example, adding new employees to a database]

To add a new employee:
1.
2.

OR

[conceptual overview]

Use the following procedure to add a new employee:
1.
2.

Most writers who responded to this query expressed a willingness to use both styles but preferred to introduce a procedure with an infinitive phrase. They then described how they use this style to address two important issues: creating documentation that is easy to translate and documenting procedures concisely.

Writing for Translation
Infinitive phrases have a valuable place in technical writing, but they must be used carefully. The infinitive phrase used by an English-speaking writer may be reduced to a single word when it is translated to another language. As a result, separating the word “to” from the verb associated with it can cause structural problems, so it is important to keep the components of an infinitive phrase together. For example, the following list would translate poorly:

Use this device to:
* measure room temperature
* detect intruders
* generate an audible alarm
Writing Concisely
Using a short but descriptive infinitive phrase to introduce a procedure can reduce the word count of a document and provide visual cues that help the user locate the information required.

Introducing a procedure with an infinitive phrase can reduce the word count of a document by eliminating frequently used phrases such as “Use the following procedure.” Contextual clues (such as numbers) indicate that the user must perform an action, so the clarity of the instructions is not harmed.

To further enhance the clarity of a document, some writers create a heading for product overview information and also format the infinitive phrase as a heading. These visual cues quickly lead users to the information that is most useful to them. A user who needs basic conceptual information about a function of a product can read the overview information before beginning the procedure, and an experienced user trying to remember the first step of a procedure can easily skip the overview information and locate the procedural information.

Conclusion
In conclusion, most technical communicators who responded to this style question prefer to introduce procedures with carefully constructed infinitive phrases, but were willing to use descriptive, complete sentences if the audience needs justified that choice.

By Justin Baker, Senior Member

Reprinted from “Capital Letter,” the newsletter of the Washington, D.C. chapter of STC, by permission of author and editor.

When I was a young technical editor, I was confused by all of the technical editing stages within one editing model—not to mention the competing editing models. Everywhere I turned, there seemed to be a competing name and a competing label for a particular aspect of editing. For example, substantive editing means developmental editing unless you are thinking of a particular editing model.

I was like a movie character in one of those old clichéd film montages where the character walks past one blinking neon sign after another, completely perplexed. To this day, I still do not adhere mentally to The Levels of Edit ¹ with its nine editing levels. I have sought to develop my own editing model based on my experience as a technical editor. Some theoretical physicists believe that the underlying formula that explains the theory of everything in the universe will turn out to be a simple, elegant formula. Life is indeed complex, but at the mountaintop of knowledge, things must have a simplicity that is understood by all. I believe that to be true of the levels of edit.

If some editors are not clear on the levels of edit that it takes to edit a document, then most managers are certainly not clear on the levels of edit, either. As we all know, communicating our profession’s conceptual models to managers is very difficult. Most managers (excluding technical communication managers) think of writing and editing as a black box activity. They see the document go in; they see the document come out. Most managers are blissfully ignorant of the complexities of our job. Their blissful ignorance may be partly our fault. Perhaps we have not communicated the nature of our activities in the simplest possible way.

This is a usability issue. We as technical communicators are focused on usability more and more, so when the conceptual models in our own profession are not easily understandable, then we need to simplify them. I think it is time to simplify and re-label the editing levels so that they are straightforward and intuitive, at least at the top level. The Levels of Edit espouse no less than nine editing levels, and labels for some of these editing levels are surely not intuitive to either some editors or managers. Let’s simplify the editing model down to three editing levels at the very top.

Knowledge Editing
I propose that the first editing level be titled knowledge editing. Knowledge editing refers to the technical subject matter in a document, both in text form as well as in illustration form. In the editing model I propose, the knowledge editing level would be divided into four sub-levels:
• knowledge accuracy,
• knowledge completeness,
• knowledge logic,
• knowledge hierarchy.

The knowledge accuracy and knowledge completeness sub-levels would ensure that the subject matter is accurate and complete. The knowledge logic editing sub-level would ensure that the a-b-c logic of the subject matter is sound. The knowledge hierarchy editing sub-level would ensure that the 1.0, 1.1, 1.1.1 hierarchy of the subject matter is sensible. Of course, the editing sub-levels in this editing level might be performed at the same time as they might be in the proceeding editing levels.

Language Editing
I propose that the second editing level be titled language editing. Language editing refers to the technical subject matter in a document, both in text form as well as in illustration form. Language editing would focus on the manifestation of the knowledge through words and images. This level of editing would encompass the following editing sub-levels:
• sentence structure
• grammar, diction
• punctuation
• spelling
• character mechanics

For visual text, language editing refers to the particular standard visual elements used in any given type of illustration. For example, use case diagrams use particular industry-standard visual elements that must be used in the diagram; for network diagrams, some companies might want to consistently use the same network server icon. The language editing level would ensure that the text language as well as the visual language are standardized.

Layout Editing
I propose that the third editing level be titled layout editing. Layout editing focuses on the following editing sub-levels:
• standard, large-scale document structures
• text and illustration spacing
• large-scale font formatting
• miscellaneous layout mechanisms such as running headers, page numbers, and hyperlinks

Conclusion
In the editing-level conceptual model that I propose, I do not consider it necessary to build in a layer that prioritizes the levels of editing as is dictated in The Levels of Edit or a Council of Biology Editors (CBE) publication² from several years ago that proposed the reprioritization of the editing levels found in the Levels of Edit. Simplicity is best in this situation. It is enough to give technical editors the basic editing levels and sub-levels and let them decide what takes priority.

I have not covered all the possible nooks and crannies of the editing landscape in this brief column, but it doesn’t matter. Even if I had covered every single aspect of editing, there would be arguments about the arrangement of the editing levels and sub-levels. The point is that the editing conceptual model needs to be simplified at least at the top editing level. I say knowledge editing, language editing, and layout editing. You may say something else. And we can debate on the editing sub-levels that lay beneath. I’m merely making a call for clarity.

Justin Baker has been a technical writer and editor for nine years. You can reach him at bakerjustin@earthlink.net.

Endnotes
¹ Van Buren, Robert, and Mary Fran Buehler. The Levels of Edit, 2nd Ed. Pasadena: Jet Propulsion Laboratory California Institute of Technology, 1980.

 ² Nadziejka, David. 1999. Council of Biology Editors Guidelines, Number 4: Levels of Technical Editing. ISBN 0-914349-5-0. Reston, VA: Council of Biology Editors

by Ben Davies, STC Manitoba Program Chair

Reprinted from “Manuscript,” the newsletter of the Manitoba chapter of STC, by permission of author and editor.

For the past year, I’ve been a technical writer for an engineering-based company. As a result, I often deal with difficult-to-understand documents written by technical people. Without reading these documents, an outsider might assume they are complicated because they are filled with complex information; in reality, the documents are complicated because of the way they are written.

The following paragraph is an example of a paragraph that is very complicated because of the way it was written:

This key only activates radio buttons that are de-activated. Questions that need to be answered by activating the appropriate radio button are given multiple options (two or more). By default, one of the option radio buttons will be activated. If you would like to activate an option other than the one activated by default, move to the desired option radio button using the TAB key and press the SPACEBAR. This will activate the desired option radio button and deactivate the one activated by default. For example, when indicating the gender of the Applicant, you may want to activate the Female radio button. Since the Male radio button is activated by default, move to the Female radio button using the TAB key and press the SPACEBAR. This will activate the Female radio button and deactivate the Male radio button.

After reading this paragraph, the following question comes to mind: Is using radio buttons so complicated that you actually need to provide a detailed example?

I call such paragraphs “passion fluff”—text that someone has put a lot of time and effort into writing but that really say nothing.

The “fluff” in the example above is all the times the author re-iterates the same concept in different ways in an attempt to clarify an already convoluted set of instructions. The example itself is “fluff”, because using radio buttons isn’t complicated.

I decided to re-write this paragraph to see if I could take out the passion fluff and came up with the following:

Questions are answered by highlighting the radio button next to the appropriate answer.

Note: Only one radio button can be highlighted per question.

I had an epiphany last year when I realized people don’t like to read, especially when they are trying to complete a task. Therefore, essential information buried in long, convoluted paragraphs is useless. Most technical writers already know this, and I hope I’m preaching to the choir; however, many subject matter experts don’t know this, especially if they came from University where writing long (10+ lines), convoluted, academic-style paragraphs and sentences (like this one) are a way of life.

Contrary to popular belief, academic writing has no place in the business and technical world of documentation. Because of this, it is our job to teach passion fluff writers what is acceptable and what isn’t. Allowing someone to get away with passion fluff does two things: it lowers your expectations of the other person’s writing ability, and it encourages the other person to continue writing incorrectly.

Remember, though, that passion fluff is very difficult to deal with because of the passion that’s involved.

A strategy you could take to help passion fluff writers is to re-write something they’ve written to show the value of clear communication.

The goal of re-writing something isn’t to prove how badly they write, but to make them better writers. Show them what is right, rather than showing them how what they did was wrong.

by Sue Kocher

Editor’s Note:
This article originally appeared in the February 19, 2007, edition of words@sas, a series of articles about Terminology Management issues, published on the internal web site of SAS Institute Inc.  It was originally reprinted in the Q1 2007 issue of Carolina Communique (http://stc-carolina.org/newsletter/tiki-index.php?page=Is+Consistency+Boring).  Now, it graciously appears in our own newsletter. Isn’t reuse grand? – Michelle Corbin

What do customers want from our software and documentation? They want to accomplish tasks, and to obtain information about tasks, as quickly and painlessly as possible. Do they also expect to be entertained along the way? No, not when there is work to be done. Years of usability analysis in the software industry indicates very clearly that clarity and ease-of-use is topmost on the minds of software users. Sure, software users appreciate a look and feel that is aesthetically pleasing, even beautiful. At the very least, they want a user interface design that says “quality.” Bells and whistles are nice, as long as they’re functional. But when it comes to getting work done, most of us wish that cute little animated PC would stop cartwheeling and get the heck out of the way when we jab the X!

A crucial key to the usability of both software interfaces and written material is consistency. The software industry is slowly realizing that technical information is far easier to digest and use if it is predictable. In fact, this is true of language processing generally: in order to understand speech or writing, the brain is constantly engaged in a rapid-fire testing process, predicting or “precomprehending” what is likely to come next, according to what has been understood already. Furthermore, most people read text not word by word, but in chunks. We learn to recognize the “shape” of printed phrases and sentences. That way we don’t have to stop and sound out each word in our heads, or ponder its meaning.

What we want to give our customers, so as not to unduly wear out their brains, is an experience with our products that includes enough “new” information to complete the task efficiently. For this, we must be consistent and predictable wherever possible.

The following examples of consistency issues focus on user documentation. However, the same principles apply to all “language resources,” including the text in user interfaces, in marketing materials, and even in e-mail communications.

Consistency in Documentation

Not so many years ago, technical writers and editors shared a set of assumptions about “good writing” that were mostly instilled by creative writing teachers, or by training in academic research writing. We realized, of course, that technical writing is more formal and straightforward than prose for art or entertainment, yet not as formal or wordy as the language of an academic paper. But we clung to some old habits.

We slowly gave up our inclination to use idiomatic speech, and of course we had to learn the lingo associated with software and particular products. We finally came to realize that there was no need to slavishly follow the old adage, “Say what you’re going to say, say it, and then say what you said” for the simple reason that most users do not read our documentation from start to finish in a serial manner.

But it was hard to dispel the feeling that repeating the same sentences and phrasing multiple times in a single document would be “boring” for our users. Writers sometimes protested that their creativity was being stifled if they were asked to express the same concept or task the same way each time, for the sake of consistency.

How Many Ways Can I Say “Do This”?

Suppose a User’s Guide includes instructions for completing a number of tasks in “Display mode.” In some legacy doc from the old days, you might see a nice, clear sentence like this:

To (do task A) in Display mode, complete the following steps:

But in the same chapter, you might also find these:

In Display mode, you can also (do task B) by completing the steps below.
 
Follow these steps to (do task C) in Display mode:

(Task D) can be accomplished in Display mode by working through the following procedure:

… and any of a myriad other possibilities. Does this make technical documentation “more interesting”? No, but it makes the tasks more exhausting and time-consuming to find and to learn, because the words in each sentence must be read and “parsed” carefully. Even more mental effort is required to understand that all of these sentences are saying the same thing, and that there is a pattern in this chapter for presenting task instructions.

Over the past few years, the SAS Publications Division has come a long way toward standardizing what and how we write. In addition to our comprehensive Style Guide for User Documentation, we now have templates for different types of books, so that users can predict what kind of content a book offers by its title. Developing standards for topic titles was a challenge that took over a year to complete, because everyone had their own “standards”, often well thought out, but that clashed with one another. Our documentation looked like it had been written by several different companies, with completely different ways of organizing and presenting information.

Now users can scan a Table of Contents or a list of search hits to quickly find the task or conceptual information that they need. As writers and editors learn to apply the guidelines, our user documentation continues to improve in clarity and searchability.

Being Creatively Consistent, and Consistently Creative

Imagine how much time, effort, and human resources can be saved by using “copy and paste” to recycle the same message. Imagine how much more smoothly our solutions will work together if they all use similar labels, messages, and designs—that’s intelligent reuse. Far from stifling creativity, the use of consistent phrasing frees writers and developers to focus their creative efforts on making complex concepts and tasks more “user friendly” and effective. Software is complex, because it accomplishes complex tasks for ever-changing markets. Our job is not to impress the user with how huge and dauntingly omnifunctional software is. Our job is to make complex tasks look easy, and to give the user lots of a-ha moments (Ah, I’ve done that before, I know what that means!) along the way.

The Technical Editing SIG is trying something different for our newsletter and Web site. Instead of waiting for a monthly or quarterly distribution, we are posting news items to our blog on our new Web site as we receive them. If you’re a member of the SIG, you’ll be receiving a regular electronic newsletter that provides a rollup of all the articles. But if you want to read the articles as they are posted, all you have to do is subscribe to the RSS feed of the SIG’s blog.

If you’re not familiar with RSS feeds, they are quite easy to use. A feed is a method of syndicating content so users can subscribe to it. These days, there are dozens of available subscription tools and aggregators that make it easy to gather your RSS subscriptions in one place. This is particularly handy if you read more than one blog or listen to more than one podcast.

How do you subscribe to the SIG feed? We created a Subscribe tab at the top of every page so you can see your options. If you don’t use a feed reader or aggregator, you can choose to subscribe via e-mail. If you choose the e-mail subscription, you’ll get a notification within a day after an article is posted.

If you do use a reader, you can use any of the links we provide on the subscription page, or you can manually enter the feed address (http://feeds.feedburner.com/STCTechEdit).

I hope you enjoy our new newsletter and Web format. Happy reading!

A listserv summary article by Emily Alfson

Technical editors are often faced with the question of whether or not to hyphenate a word with a prefix.  Sometimes following traditional grammar rules is enough to make the decision, but in the world of technology where new words are formed every day and the audience spans the globe, the answer to the question of whether or not to hyphenate a word with a prefix has become more complex than ever.  The contributors to the STC Technical Editing SIG discussion list recently pondered the issue of hyphenating words with prefixes and came up with two ways of approaching the issue.

The Grammarians

The grammarians take the more traditional approach to the issue.  If the word in question can be found in a standard reference dictionary, these editors will most likely tell the writer to follow the hyphenation used in the dictionary. 

These editors are more likely to place a hyphen between a prefix and a word if the meaning of the word is likely to be confused by the spelling.   For example, re-sign and resign have very different meanings, as does coop and co-op.

The Intuitives

The intuitive editors tend to show a little more sensitivity to non-native speakers of English and use hyphens more often than not, even if the meaning of the word may seem clear without the hyphen.  These writers and editors are more likely to check a variety of sources to see what the most common spelling of the word.  They might also check other documents within their technical writing group and see how the word was used in the past to see if there was a trend towards one spelling or another.  Then, these editors can draw a conclusion based on what the writers have used in the past and what is used by popular sources of information.

And in conclusion…

As with many of the decisions an editor must make every day, the decision of whether or not to hyphenate a word with a prefix should be based on grammar, an understanding of the audience, and the common usage of the word.  No matter what decision you make, just be consistent with each word and clearly define your guidelines regarding hyphenation.

by John Martin

Reprinted from “Technically Speaking,” the newsletter of the NCSU student chapter of the STC, by permission of the author and editor.

What do you think about someone you see walking around, or riding the bus, with earbuds in? I’ve wondered: What song are they listening to? What kind of music are they listening to? I wonder how loud that music is in their ears!

There’s a name for that “tinny sound that leaks out of somebody else’s iPod.” NPR producer Neva Grant calls it “ear spray.” But I digress…

Personally, I listen to about as many podcasts on my iPod as I do songs. Often, on a bus, when I literally “LOL” at something in a podcast episode, I wonder if people are wondering what could possibly be so funny about a song. And then I realize that what they’re really thinking is, “It’s not the song that’s a looney-tune.”

My newest podcast series subscription is to one called “Grammar Girl,” which I found addictive (or is that addicting—see episode no. 16 for the answer) after hearing the first two episodes. What’s great about them to me is that they address issues that even the most experienced of writers and editors think about, and they are presented in a most concise manner.

According to her website, “Grammar Girl quietly hides in plain sight as the real-life science writer Mignon Fogarty. She makes her living writing highly technical documents for large biotech companies (e.g., Applied Biosystems) and health articles for websites (e.g., the Stanford Cancer Center). Mignon earned a B.A. in English from the University of Washington in Seattle and a M.S. in biology from Stanford University. … Grammar Girl believes that learning is fun, and the vast rules of grammar are wonderful fodder for lifelong study. She strives to be a friendly guide in the writing world.”

Her average podcast is less than five minutes in length, and some topics covered so far in the series include:

• Overuse of the word “of”
• “i.e.” vs. “e.g.”
• “Who” vs. “that” when talking about companies
• “Which” vs. “that”
• “Who” vs. “whom”
• “Effect” vs. “affect”
• “Among” vs. “between”
• Split infinitives (She calls this a “grammar myth.”)
• Style guides (Don’t work anywhere without one!)
• Fighting wordiness and investigating idioms
• “If I were there” vs. “I was there”
• Which words in a title should be capitalized
• Ending a sentence with a preposition (Times have changed!)
• Redundancy with acronyms (e.g., the HIV virus)
• The difference between acronyms, initialisms, and abbreviations
• Helpful tips for effective proofreading
• Single quotation marks vs. double quotation marks
• Generic singular pronouns (e.g., “he” vs. “she” vs. “one” vs. “s/he,” etc.)
• When to use dashes
• When to use colons
• How to identify sentence fragments
• “Its” vs. “it’s”

Grammar Girl is big on mnemonics, and whenever possible, she offers them as a way to remember a certain rule or tip. Here’s one she gives to remember the difference between effect and affect: “The arrow affected the aardvark,” and “the effect was eye-popping.” There are a words in the affect sentence, and e words in the effect sentence.

The other thing that’s great about her is that she is not at all pretentious. She freely admits that she’s there to provide “quick and dirty” tips. Here’s one of them with regards to the use of “who” and “whom”: “Like whom, the pronoun him ends with m. When you’re trying to decide whether to use who or whom, ask yourself if the answer to the question would be he or him. That’s the trick: if you can answer the question being asked with him, then use whom, and it’s easy to remember because they both end with m.”

She gives an example for better understanding: “If you were asking, ‘Who (or whom) do you love?’ the answer would be ‘I love him.’ Him ends with m, so you know to use whom. So it’s, ‘Whom do you love?’

“But if you were trying to ask, ‘Who (or whom) stepped on Squiggly?’ the answer would be, ‘He stepped on Squiggly.’ There’s no m, so you know to use who. So, it’s, ‘Who stepped on Squiggly?’”

Before her quick and dirty tip, of course, she does give the actual grammar rule, in this case: “Use who when you are referring to the subject of a clause, and whom when you are referring to the object of a clause.”

Two other things I really like about Grammar Girl’s teaching style are that she provides historical context to rules when it might help in learning, and she uses current events as an impetus for some episode topics.

An example of historical context use can be found in her episode on apostrophes, where she says, “An interesting side note is that it doesn’t seem so strange that an apostrophe s is used so make words possessive once you realize that in Old English it was common to make words possessive by adding es to the end. For example, the possessive of fox would have been foxes, which was the same as the plural. I assume that caused confusion, and someone suggested replacing the e with an apostrophe to make fox’s in the possessive case. So, apostrophe s for the possessive case was initially meant to show that the e was missing, and then the idea caught on and everyone eventually forgot all about the missing e.”

With regards to topics around current events, a recent podcast discussed the use of the word is in the Christmas carol line, “The Lord Is Come,” another addressed whether Saddam Hussein was hanged or hung, and yet another discussed why people are saying, “Nancy Pelosi is the first woman Speaker of the House,” when they would never say, “He was the first man Speaker of the House.”

Grammatically inquiring minds want to know!

There is a transcript of each episode on the Grammar Girl website, though she is currently polling her audience as to the value of this time-consuming activity for her. The transcript usually contains two sections at the end, one called “References,” which basically contains her citations, and another called, “Further Reading,” which contains pointers to articles of interest on the topic, or to the “nitty gritty” of the topic when the “quick and dirty” doesn’t tell the whole story.

Grammar Girl is committed to continuously improving her product. She often polls her audience on various ways to improve her episodes, and she is currently working to add “slides” to her podcasts, so that, depending on what kind of “client software” you’re using to receive her broadcast, you can see written examples of what she’s talking about, which at times would be incredibly helpful. Eventually, she’d like to delve into video as well.

You can listen to Grammar Girl podcasts even if you don’t have an mp3 player! Just go to her website, at either qdnow.com or grammar.qdnow.com, and you can listen online!

I, as a technical editor, intend to share this “resource” with the writers for whom I edit. (Even though Grammar Girl says it’s okay to end a sentence with a preposition these days, some old habits die hard.)

The official podcast name is “Grammar Girl’s Quick & Dirty Tips for Better Writing.” All quotes in this article are from Grammar Girl episode transcripts at her Web site at qdnow.com.