Tag: Vol 7 No 2

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.