Posts

Posted on

Understanding Passion Fluff

Ben Davies

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.
To highlight a radio button, press the spacebar.
To move between radio buttons, press TAB.
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.

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

Posted on

Introducing Procedures, a Discussion List Summary Article

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.

Posted on

Clarity for Editing

Justin Baker

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 cliched 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 1 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) publication2 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

  1. Van Buren, Robert, and Mary Fran Buehler. The Levels of Edit, 2nd Ed. Pasadena: Jet Propulsion Laboratory California Institute of Technology, 1980.
  2. 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

Reprinted from Capital Letter(external link), the newsletter of the Washington, D.C. chapter of STC, by permission of author and editor.

Posted on

To Hyphenate or Not, That Is the Question

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.

Posted on

Podcasting: Entercation or Edutainment

John Martin

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 http://qdnow.com(external link).

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