Tag: Vol 9 No 2

Posted on

The Technical Stylist Meets the Definite Article: What Bloody Man Is That?

Kathy Underwood

In Act I, Scene 2, of Macbeth, a blood-soaked sergeant enters the presence of King Duncan, which prompts the king to ask the obvious question:

“What bloody man is that? He can report,
As seemeth by his plight, of the revolt
The newest state.”

What is the answer to this kingly question? That’s a usage pundit reporting some change in language usage that seems likely to provoke controversy. And that’s me after one of those interminable style discussions that characterize editors’ meetings. I sometimes—well, often—feel that I’ve just left the battlefield and that I need to find the nearest medic. It’s not that we’re all contentious. (In fact, very often these discussions are more like rowdy, amusing party games.) It’s just that the topics we address are fraught with complexities that make the plot of the Scottish play look like Dick and Jane. Worse yet, we frequently struggle with questions that few if any customers would ever recognize as questions.

Take the definite article. Please. The editors at SAS continue to struggle with the question of which SAS product names require the definite article and which require the zero article (linguist-speak for no article at all).

How do you make such a decision in the absence of clear guidelines from the usual usage manuals that we consult (Chicago Manual of Style, Harper’s Dictionary of Modern American Usage, etc.)? In the interest of precision, we have to make choices not unlike those parodied in the show Beyond the Fringe(external link) in the 1960s. In a sketch entitled “Portrait from Memory,” Jonathan Miller as Bertrand Russell meets the philosopher G.E. Moore, who, as it happens, is holding a basket of apples on his knees. Russell asks Moore if there are any apples in a basket. Moore says no. Then Russell asks if there are some apples in the basket. Moore says no. Finally, Russell asks Moore if he has apples in the basket. “’Yes,’ he replied. And from that day forth we remained the very closest of friends.” (Can you imagine what Moore would have been like in editors’ meetings?)

For our in-house style guide, my worthy colleague and fellow editor, Joel Byrd, created an article on the use of the definite article with product names. He reified our department’s lengthy and ongoing collaborative discussions and e-mails and produced a very useful table as well as a field test to help us make the best choice. Here is my paraphrased version of the guidelines:

  • Use the definite article if the primary noun is countable (example: “the SAS Forecast Server”).
  • Use the definite article if there is general industry agreement that the primary noun requires a definite article (example: “the SAS Intelligence Platform”).
  • Use the zero article if the primary noun is uncountable (example: “SAS Business Intelligence”).
  • Use the zero article if the primary noun is a metaphor “that does not have a defined, commonly accepted meaning in the software industry” (example: “SAS Management Console”).

The test devised to assist the editor is as follows:

  • Write the primary noun in lowercase and then in uppercase (for example, “console” versus “Console” and “the console” versus “the Console”).
  • Does the name of the object in isolation mean the same thing as it means in the product name? If so, use the.

Based on several examples of SAS product and component names, I decided to create a list of our extant primary nouns so that we could have an at-a-glance guide for new product names and whether or not they should take the definite article.

  • Use the definite article with these primary nouns:
    • platform
    • portal
    • provider
    • server
    • software
  • Use the zero article with these primary nouns:
    • analytics
    • console
    • intelligence
    • studio

This list should be satisfyingly clear. But consider the problem with console. Our basic rules say that if the primary noun is uncountable, we should use the zero article. But the word console is obviously countable. On the other hand, in the land of product names and software products, console is a metaphor and not countable. Very crazy-making. So every time I come across a product name with the word console in it, my editing hand wants to insert the definite article.

There’s an even bigger problem. With any usage guideline, there’s a “missing middle” (one or more ungrounded assumptions) in the syllogism. That is, when and how do we decide that a given agreement has reached a critical point that forces us to change our guidelines? Yes, you guessed it: We have to have another editors’ meeting.

Why is it that grammar and usage rules, which once mastered should provide comfort and confidence, can be so frustrating? Why are there so many exceptions to cope with? And why do all those usage pundits have so many different opinions and remarkably little consensus? I think that those questions are answered succinctly by Otto Jespersen in his introduction to The Philosophy of Grammar (found in the first sentence of Chapter 1):

“The essence of language is human activity—activity on the part of one individual to make himself understood by another, and activity on the part of that other to understand what was in the mind of the first.”

Even if we think of the effects on language of just a few of the more dramatic forms of human activity—revolutions, inventions, and catastrophes—we quickly realize that language is a quivering, changeful thing. From vowel shifts, to spelling, to syntax, language always reflects the psyche of any given group. (And which psyche is more shifting than that in the software industry? A new product or technology can completely change perspective.) That’s especially true when society is in flux. It’s that shared, shifting psyche that dictates what really happens with language. And we might argue that the shifting is where the sublime arises.

As editors, we often have to make many decisions that we know will ultimately prove ill-advised, if not completely wrong, and that any number of our fellow editors will find objectionable. But that’s what human activity, war, peace, and the dialogue of the psyche are all about.

Think of the changes from “on line” to “on-line” to “online” that have occurred over the past few decades. There was no legislation, there was no vote, and there was no universal epiphany. So why did “on line” and “on-line” drop out of use (mostly—they are still used in some settings)? In The Fight for English, the linguistic historian David Crystal says that the short answer to questions about disdained usage is “somebody thought it was wrong.” (See Crystal, page 110. Crystal’s book, by the way, is a very readable history of grammar practice and grammarians over the past few hundred years.)

All editors, and especially those of us who serve on in-house style teams, have to make arbitrary decisions all the time. We must be as autocratic as is essential to produce a cohesive body of documentation. But we can never lose sight of the world outside our doors. We have to listen to that bleeding sergeant even if we don’t want to or haven’t got the time to hear what he has to say.

Posted on

Scholarship Winner: Internships Stretching One’s Abilities as a Communicator

Daniel Seipert

Editor’s Note: Once again this year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the first of such articles from our graduate scholarship winner.

I first discovered my interest in technical editing while an undergraduate at the University of North Carolina at Charlotte, where I earned an internship with the Environmental Assistance Office on campus. As an intern I edited several laboratory reports on soil composition and water quality, some of which provided the extra challenge of editing for authors who were non-native English speakers. I enjoyed this work so much that I decided to pursue my Master’s in technical communication at East Carolina University (ECU). My graduate assistantships at ECU gave me many opportunities to work as an editorial assistant on projects for IEEE Transactions on Professional Communication and the program committee for the 2008 Conference of the Council for Programs on Technical and Scientific Communication. I have also been able to work with the Renaissance Computing Institute at ECU, designing their website, newsletters, and brochures.

Perhaps my most challenging and fulfilling project, however, was a comprehensive edit of 12 chapters for an academic book on the global digital divide. One of the project’s most valuable qualities for me was the opportunity to again edit for English as a Second Language (ESL) authors. On the surface, this process required me to address syntactic and lexical issues common among ESL authors, such as misplaced prepositions, incorrect articles, and non-parallel structures. But, I also had to be aware of any underlying cultural considerations that may have led to these errors, rather than simply attributing them to lack of language knowledge. Even a seemingly straightforward issue such as spelling can be complicated by strong cultural opinions. For example, because each chapter was written by a different author from a different country, it was decided early on to use each author’s preferred spelling in his or her respective chapter, whether American, British, or Australian. I had to study and recognize these spelling variations rather than insensitively correcting them according to American spelling.

However, my role as editor went beyond linguistic copyediting. Indeed, as Enkvist (1997) notes, “the text is the father of the sentence”; thus, sentence-level errors were edited out of necessity, but my focus was comprehensive editing for the organization, conciseness, and style of the chapters as a whole. Some of the common issues addressed in my editorial comments included unrelated information packed into paragraphs, under-supported or ambiguous assertions, redundant and repetitious passages, and inaccurate assumptions about audience knowledge. Each of these items had to be addressed in a way that conformed to the authors’ original strategies and purposes for their chapters, not by merely re-writing bulky sentences. One chapter, for example, discussed the effect of globalization on traditional African music. Styles of music from different nations were listed, but unless the audience shared the author’s local knowledge of African music, they were unlikely to understand the significance of the different styles or their effect on each other. This example, like many others, could not simply be “corrected,” but had to be highlighted by a diplomatic comment to the author, addressing the author’s purpose in discussing African music and providing suggestions on how to better meet that purpose.

While these issues are not unique to ESL texts, editing for them as part of this project provided a particular learning experience for me. One of the overarching challenges was achieving cohesiveness among the different chapters while maintaining the authors’ individual voices. As the readers’ advocate, my goal was to collaborate, not co-author. This process, again, required cultural awareness on my part, as the authorial voices of this project were much more diverse than those in other projects.

On the sentence level, this meant allowing unusual—yet clear and correct—phrasing to remain as a type of “written accent” rather than enforcing my own American accent (Harris and Silva 1993, 531). At the organizational level, this meant being aware of cultural expectations and communication norms, especially the differences between what Edward T. Hall (1976) terms high-context and low-context cultures. As a member of a low-context culture that tends to favor the direct and explicit, I had to recognize that an author from a high-context culture may not necessarily view ambiguous statements or unnecessarily exhaustive introductions as areas needing improvement. In the author’s culture, the “ambiguous” meaning may be implied and the indirect presentation expected. Thus, rather than dictate American structure, my editorial comments reminded authors of the different contexts and expectations their readers may have and the effect the current version of text may have on those readers’ ability to understand the authors’ arguments.

Providing such commentary, however, was a challenge in itself. Because idioms common to my culture may not make sense to those of another, my comments had to be specific and concrete in order to avoid confusion. I could not use the shorthand of figurative language. Conversely, rules of politeness rely on a measure of indirectness, especially in high-context cultures. Thus, if too direct, my comments may be perceived as rude. Balance was required in order for my comments to be both effective and diplomatic.

Despite these challenges, I found the project very fulfilling. Not only did it give me valuable experience as an editor and provide me with promising professional contacts, but it also stretched my abilities as a communicator and collaborator as I learned to respect and interact within a more diverse community of writers.

Finally, I express my sincere gratitude to the Technical Editing SIG for awarding me this scholarship. It is both a great honor and a relief as it enables me to take another step forward in my career.

References

Enkvist, N. E. 1997. “Why we need contrastive rhetoric.” Alternation 4(1): 188–206.
Hall, E. T. 1976. Beyond culture. Garden City, NY: Anchor/Doubleday.
Harris, M., and T. Silva. 1993. “Tutoring ESL students: Issues and options.” College Composition and Communication 44(4): 525–537.

Posted on

Scholarship Winner: Discovering the Breadth and Depth of Technical Communication and Technical Editing

Lindsay Taylor

Editor’s Note: Once again this year, the STC Technical Editing SIG offered scholarships to one undergraduate and one graduate student in technical communication. One part of the scholarship application was to describe a project or research that the applicant was involved in. We asked the scholarship winners to write a newsletter article summarizing their project or research. This is the first of such articles from our undergraduate scholarship winner.

Before taking my first undergraduate courses in technical communication at the University of Wisconsin-Madison, I had never imagined how complex and broad the field of technical communication really is. My coursework made it clear how much more I had to learn about technical communication, such as the different fields one can work in (science, engineering, etc.) or the different approaches to editing (individually and in a team).

To exemplify the variety of lessons I have learned—all precedents for future studies—I would like to describe two projects that were of particular value. Each demonstrates very different but equally important elements of my technical communication education. The first, for an introductory technical communication course, was writing and editing a semester-long research project on treatments for Parkinson’s disease in the fall of 2008. The second project, for a technical editing course, was a comprehensive team technical editing assignment on the UW Engineers Without Borders (EWB) handbook in March of 2009. I will describe what each project taught me about technical communication and how I will use that information in my future work as a technical communicator.

As an English major, I have written many research papers throughout my undergraduate career. In my first semester of the Technical Communication program, however, I was assigned to write a comprehensive, 15-page research paper on a scientific or engineering-related concept. While my background in science prepared me for the material, I was intimidated by the idea of writing a research paper of such magnitude outside of my own discipline. Even my work directing an interdisciplinary writing-tutoring program did not fully prepare me for the writing style used in technical communication, a style very different from what I was used to in the humanities. To write this particular research paper, I read countless samples of science writing and technical documents, meticulously followed my professor’s (Laura Grossenbacher’s) handbook on technical communication, and capitalized on peer-editing sessions with my classmates, all of which exposed me to different styles of technical writing. Though the report was supplemented by the edits and comments of my classmates, the paper was essentially an independent project that tested my ability to think critically and learn a new skill. By the end of the semester, I felt that I had produced an effective research paper and had discovered a new appreciation and passion for technical communication. This individual project reminded me of the importance of revision, word economy, and researching skills, all of which continue to contribute toward my success writing in a variety of disciplines. I know that I will remember this project one day when I am faced with a challenging technical communication assignment that tests my ability to be flexible and open-minded in learning new skills. I also value the independence that this project gave me: the ability to own a document from start to finish.

The second compelling technical editing project I worked on was with UW’s Engineers Without Borders (EWB) handbook in a technical editing course in spring 2009. Last year, two senior UW-EWB members informally produced a comprehensive, 50-page manual for new EWB members, describing everything from the group’s mission to how to use Skype when working in developing countries. The handbook was an important resource but would benefit from improvements in content, organization, and design. Our class was assigned to help improve the overall appearance and effectiveness of the document. In teams of four, our class worked to comprehensively edit the entire document. I’d like to describe this project because the team editing approach was so distinct from writing an individual technical document.

While I have worked on group projects before, I had never quite tackled a project of such magnitude. I learned how to collaborate with a team of editors who all see different positive and negative elements of a document. Just to interact within a group of four editors was challenging, but beyond that, the five groups in the class had to agree upon several universal editing points within the document. This project was particularly fascinating because of the amount of communication that went on among and between groups. Editing this large document would have been time-consuming and rather impractical for just one editor. This team editing project truly taught me about the effectiveness of a group of editors, something that I had not completely understood before this course.

One additional technical editing lesson I learned from the EWB handbook editing project was the great difference between copyediting and comprehensive editing. As a Writing Fellow (a UW writing tutor), I was trained to prioritize global issues in a document; then, as the copyeditor of the Wisconsin Engineer magazine, UW’s undergraduate engineering publication, I focused specifically on local, mechanical edits in documents. However, in addition to these issues, my work on the UW-EWB handbook taught me that the field of technical editing also requires analysis of organization and content and maintaining an open communication line with the author. My group and I closely collaborated with the authors of the handbook, and we were responsible for making universal changes throughout the document on both objective items, such as capitalization, and on more subjective topics, like the tone of the handbook. I discovered that several elements of editing are interdisciplinary, despite the great differences between writing styles and fields.

Both of these projects stemmed from great assignments set by excellent professors. I am grateful for the distinguished professors I was able to learn from during my undergraduate technical communication studies at UW. The lessons I gained from their projects were diverse, yet each provided fruitful practice for a future career in technical editing. I realize now that technical communication crosses many disciplines, topics, and writing styles, and as a recent graduate deciding on a career path, the diversity of the field is the most compelling factor to me. I will retain the lessons I have learned from both of these projects and will apply that knowledge in my continued education of the field of technical communication.

Posted on

2009 Conference Highlights: Tech Edit SIG Excitement at the Conference

Wow, I hope you had a chance to follow some tweets we sent during the conference. If so, you might have heard about the exciting times there. To wrap up:

Awards

At the Honors Banquet, we were extremely pleased (see the photo) to accept the Community of Distinction award on behalf of our volunteers, members, and past leadership board. We’d particularly like to call out the work of these past presidents: Pat Moell, Michelle Corbin, and Dianne Feldman for their contributions to make this award a reality.

Picture of Vanessa Wilburn and Meredith Kinder at awards banquet.

STC president Cindy Currie, TE SIG co-manager Vanessa Wilburn, immediate past present, Mark Clifford, TE SIG co-manager Meredith Kinder, and 1st Vice President Michael Hughes.

Breakfast Meeting and Networking

Over 26 people joined us for the 7:15 am breakfast and networking during our annual business meeting. We shared our thoughts by posting “I love the TE SIG because…” on the walls of the room. See your peers’ thoughts in the photos below. We recapped our activities in the past year and talked about our upcoming plans, such as membership meetings, our use of social networking technologies, more additions to our web site, and the much-loved discussion list. Thanks to Jeff Japp for taking notes. In addition, the group shared its thoughts about how to help STC better promote its conference through better written session descriptions and templates.

Picture of notes Why I Love TE SIG.

Click to read the notes
I love STC because I can talk about problems with people who understand.

I love STC because I can talk about problems with people who understand. Good to know there are other editors out there!

Sessions for Editors

Thanks go to Shirley Burns and Gururaj B.S. for the SIG brochure that also included a list of sessions of interest to editors. We handed out 100 of these brochures to attendees. In addition to that, at the Community Reception on Monday evening, Kelly Shrank helped us meet and greet both potential members and current members, as well as hand out editor goodies: sticky pads in the shape of punctuation marks, fluorescent sticky flags, highlighters, and editing buttons.

Picture of Kelly Shrank

Kelly Schrank
Picture of the Editing Progression

The Editing Progression

We had 67 people attend the Editing Progression (the room was at capacity!). With six dynamic topics, each table had lively debate and conversation about Editing Challenges and Opportunities: Tracking Your Editing Metrics, What Practitioners Can Learn from Students, Keeping Your Editing Skills Sharp, The Editor’s Role in Building Community, The Editor’s Role in Screencast Development, and The Remote Editor. Several attendees commented that this was the best session at the conference!

Share Your Experience

Please enter thoughts about your experience at the conference in the Comments section below. Share what you learned, your summaries of your favorite sessions, or your opinions on the events you attended.