The Official Publication of the STC Technical Editing SIG
David Kowalsky
A second edition of Geoff Hart’s comprehensive Effective Onscreen Editing: new tools for an old profession was published in 2010 (available in both print and e-book versions from Diaskeuasis Publishing).
Continue reading “Book Review Effective Onscreen Editing by Geoff Hart”
In keeping with our promise to provide an article on watercooler chats, here is a summary article of the most recent watercooler chat. This chat was held on May 12, 2010, and it focused on using the TE SIG Web site.
Rick Sapir, the TE SIG webmaster started out by highlighting the two “cool” items on the site.
Rick also mentioned the two important things to know about our site.
Chat participants were encouraged to use the wiki. Rick indicated that all pages on the site are wiki pages. He stated that anyone could volunteer for the role of a site editor, and it was easy to create, update, or edit pages. However, Rick mentioned that for some reason, it seemed like people were hesitant to do so. Rick felt that the hesitancy is unwarranted because it is impossible to break any content and it is very easy to undo a change on our Web site.
The TE SIG Web site has certainly improved over the past two years! However, Rick commented that based on the results
of a recent Web site feedback survey, it seemed like some users felt that there was so much “stuff” that they did not know where to begin. One of the opinions expressed in the chat was that a newsletter article would help.
As a follow up, this summary article indicates what you can do to navigate through the Web site more easily.
For the interesting perspectives that were exchanged on the chat, you can see the chat transcript.
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.
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.
Daniel Beck
Editor’s Note: 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 second of such articles from our undergraduate scholarship winner.
This past spring, I took the last in a series of technical writing courses offered here at the University of Central Florida (UCF), creatively titled “Technical Documentation.” Unlike the two previous courses in the series, I was set loose with minimal supervision. My objective for the semester was to find a client, propose a project, and complete the work of the project entirely on my own. The instructor in the course would only review my work and provide substantial feedback once, at the middle of the semester.
I felt that the class was a terrific opportunity to try something I hadn’t done before. I had missed some opportunities to work as an editor in my technical communication coursework. With this course, I had an opportunity to take advantage of and get some much-needed experience working with the results of other writers’ work.
My part-time employer, the UCF’s Course Development and Web Services, had just the project for me. They had some documentation that was in desperate need of revision. UCF was transitioning from one Web e-learning platform to another. It was a somewhat painful process that I’m sure many people are familiar with — after spending years using one tool, thousands of users were ushered on to another.
The difficulty of this change was exacerbated by the lack of well-maintained documentation. The documentation provided by the software vendor had not been updated in years; it only somewhat reflected the software in use on UCF’s servers. Furthermore, the documentation was internally inconsistent. Supplements to the documentation produced by Course Development and Web Services were visually and textually inconsistent with the vendor-supplied documentation.
Naturally, I chose to overextend myself that semester by trying to single-handedly solve all of these problems. It was a long, tiring process of reviewing hundreds of pages of instructions and attempting to coordinate their strengths and mitigate their weaknesses. Pages and pages had to be entirely rewritten; dozens of screenshots had to be recreated to match the software in use. And throughout it all, the details of the project were left up to me.
Of course, I learned some interesting practical lessons. For instance, I “discovered” — probably in much the same way that Columbus “discovered” the Americas — a cheap trick for testing documentation out on an audience. In the day-to-day activities at Course Development and Web Services, I often responded to support requests via email from faculty members. Frequently I used portions of my documentation revision project as the basis for responses to email questions. It was easy, cheap testing. Instead of writing up one-off instructions for the faculty, I would send them portions of the documentation. I got unambiguous feedback without ever having to convince any faculty members to complete a survey or an interview: either the documentation resolved the issue or didn’t.
I also learned that my weakness for playing with flashy new technology might someday be a problem for me. I committed myself early on in the project to use a new project management tool that Course Development and Web Services had purchased. It was fun to learn, but I think I spent more time figuring out the tool than actually using it to get the job done. As it turns out, one person doesn’t need a project management tool, one person just needs a to-do list. While working alone, I found that the project management software was overkill for the amount of tracking and reporting I needed to do. I could imagine such a tool being useful for a team of writers, but for me it was just a distraction.
But the most important lessons I learned had to do with what it actually means to be a technical writer or editor. As the semester dragged on, I began to appreciate what other technical writers mean when they refer to the “lone technical writer,” a phrase I had heard often, but didn’t fully understand, despite many STC chapter meetings and two Summits. There is so much value in having at least the camaraderie, if not the outright assistance, of other writers working with you.
And it was that lesson that ultimately led to a big realization as to what it is about technical communication that really appeals to me. The loneliness of being the “lone technical writer” let me finally figure out that it’s not about the writing. Though long hours in front of a keyboard, actually writing, can be fun, it’s not the point to write or edit for its own sake. Rather, the point is to reach out to others in a fascinating and productive way. Since I did not have the benefit of being in the same room as those potential other people, I learned to ask myself, again and again, how can I make what I do an improvement for me, a future writer or editor, my coworkers, and my audience?
Micah Stanley
A summary of a panel discussion at the Bay Area Editors’ Forum.
Panelists: Patricia Egan, Robyn Brode Orsini, and Lyn Smirnov
Forum date: Wednesday, September 24, 2008
Forum organizers: Patricia Egan and Karen Asbelle
Our September meeting focused on the educational opportunities available to those who want to enter technical editing. Three distinguished technical editors led the discussion: Patricia Egan, who teaches in the Technical Communication program at UC Berkeley Extension; Robyn Brode Orsini, who teaches Professional Editing in the SF State Technical and Professional Writing program; and Lyn Smirnov, technical writing instructor at De Anza College in Cupertino.
One of the main functions of an editor is to serve as “another pair of eyes”–evaluating and refining an author’s work to make it as clear as possible. In technical communication, an editor’s role is often critical to a project’s success. One classic example is Edward Tufte’s analysis of the O-ring charts that NASA engineers used before the space shuttle Challenger’s fateful launch, as shown in his book Visual Explanations. The data in the charts were so poorly presented graphically that it’s easy to see how the engineers glossed over the information. If the data had been shown in a more easily comprehensible way, the Challenger disaster might have been avoided.
So, what’s the difference between technical editing and general editing?
It comes down to subject matter. When asked to name some industries where technical editing is used, the panelists listed these examples: software and computers, medical, manufacturing, finance, engineering, science, bio-tech, legal, government, and gaming. According to Orsini, the need for technical editors in the fields of “green” technology and sustainable energy sources is definitely on the rise: “We’re at a major tipping point in that industry, and the need for technical editors will be huge.” The panel agreed that the first thing you need when entering technical editing is interest in the subject matter. “You might have a degree in it, you might have a professional background in it, or you may have interest in it and you want to just go in and learn, but you have to decide what interests you and go after it,” said Orsini.
What if you have an interest in a particular field, but no experience?
Get creative. One audience member expressed an interest in the biotech field but said that all of her experience was in software development. Smirnov immediately suggested applying the audience member’s background to the biotech field by seeking out those companies that develop medical software. “Reach out to them and see if you can come in through the high-tech side; then you can absorb all the buzzwords by osmosis and slide in. You may be narrowing your choices initially, but you would be leveraging your strengths to get your foot in the door.”
Egan offered a handout discussing how technical editors add value to content and contribute to quality assurance as a compelling case for including technical editors in the publication process from the earliest stages of development, as described by Corbin, Moell, and Boyd. (Corbin, M., Moell, P., and Boyd, M. (2002, August). Technical editing as quality assurance: Adding value to content. Technical Communication, 49(3), 286-300.) Even if an editor is not a subject matter expert in a particular field, he or she can certainly bring significant value to a project. Egan recounted a project early in her career when she was asked to edit a peer-reviewed article written by a team of researchers from two different companies with four different native languages represented–and the article was being published in the Netherlands. “I was very clear and told them, ‘I can’t validate your content; I don’t have that background. What I can do is make sure that your work conforms to a style guide and ensure that there are no inconsistencies in the article.’”
The Bay Area has long been a technology hub in America; many employment opportunities exist for technical editors with an interest in a specific industry and the necessary skills. According to Egan, one of those necessary skills is successfully passing an editing test. When she first moved here, Egan was sent by a recruiter to a potential employer who administered an editing test that lasted an entire day. A grueling experience to be sure, but Egan passed and got the assignment. One of the first handouts she gives her students is an article Geoffrey J.S. Hart wrote for Intercom, the magazine of the Society for Technical Communication. The article explains what to expect from such a test and some strategies for successfully completing it. (Hart, G. J. S. (2003, April). Editing tests for writers. Intercom, 12-15.)
As educators in technical editing, the panelists also reviewed the specific aspects of their respective programs and the educational opportunities available to those who may want to enter the field. Each program takes a comprehensive approach by teaching the general skills necessary–grammar and syntax review, editorial querying, creating style sheets, creating and developing the author-editor relationship–and then applying those skills to real-world situations in technical communication.
In Smirnov’s experience, “A technical editor needs to be a jack-of-all-trades. You need to be able to go in and do the ‘deep dives’ as well as the copyedits.” Smirnov said that most of her students are working professionals who want to branch out into new aspects of their field and develop new skill sets to give themselves a competitive advantage. Orsini summed it up this way: “There are many approaches to entering the field of technical editing. When I started editing corporate annual reports, I didn’t know what I was doing. But I was fascinated by what was being presented, so I sat down, analyzed the information, and took it one step at a time.”