The Technical Stylist Reviews

Kathy Underwood

The Subversive Copy Editor: Advice from Chicago (Or, How to Negotiate Good Relationships with Your Writers, Your Colleagues, and Yourself) by Carol Fisher Saller (University of Chicago Press, 2009)

For several years, I taught technical editing (among other courses) at the University of Washington. If I were still teaching that course, I would include this book as required reading. Although almost all textbooks on technical editing cover the weighty matter of

Continue reading “The Technical Stylist Reviews”

The Future of Editing in Web 2.0: Wikipedia and the Role of the Editor (Part 1)

Lara Tellis

As a student in the Professional Communication program at Clemson University and a member of the technical editing SIG in STC, I wanted my master’s thesis to explore the challenges editors face in today’s world of rapidly changing technology.

I was particularly interested in Web 2.0 as a vehicle for writers and editors to collaborate. In an article for IEEE Spectrum, Paul McFedries defined Web 2.0 “as a second phase in the development of the World Wide Web in which developers create Web sites that look and act like desktop programs and encourage collaboration and communication between users.” Formerly the domain of an elite circle of programmers, the World Wide Web can now be modified by just about anybody.

The Wikipedia Focus

Among the vast number of Web 2.0 platforms currently available to the general public (WordPress, PBWorks, and Scribd, to name a few), Wikipedia is arguably the most famous. While some applaud its accessibility and the rapidity with which it is updated, others deplore what they see as its lack of standards. If anybody can write or edit articles, how do we know which information can be trusted? The open process by which the Wikipedia editors socially construct the site’s content makes some doubt the encyclopedia’s validity.1 Looking at the discussion page of an article with multiple editors reveals debates about everything from how to avoid libel to the name of the article itself. Nothing is set in stone, so today’s decisions may be overturned tomorrow, and since it is impossible to please everybody, there will always be disgruntled editors who feel that an article is in some way “wrong.”

Choosing Articles

Given the vastness of my source material, I had to narrow my examination to three Wikipedia articles. The articles I chose were diverse both in topic and in quality. The Wikipedia editors have developed a quality scale with various ranks and the criteria an article must meet to obtain a certain rank.

1. Feature Article

According to Wikipedia’s own definition, “featured articles are considered to be the best articles in Wikipedia, as determined by its editors.” Before achieving the coveted feature designation, indicated by a bronze star in its top right corner, an article must undergo a rigorous nomination and review process to ensure that it meets the criteria of accuracy,neutrality, completeness, and style.

For my study, I chose an article that had achieved featured article status back in 2005: “The Hitchhiker’s Guide to the Galaxy.”2

2. Stub Article

On the other end of the quality scale are stub articles. The Wikipedia definition of a stub is: “an article containing only a few sentences of text which is too short to provide encyclopedic coverage of a subject, but not so short as to provide no useful information, and it should be capable of expansion.” Any editor who sees an article meeting stub criteria can attach a stub tag to it. The stub tag indicates that the article is a stub and encourages editors to expand upon it.

The stub I chose to study is “2009 Northwestern Wildcats football team.” At the time of my study (September, 2009), this article was a stub. It had been created from a template and had a table to list information about each football game Northwestern University was scheduled to play in 2009; however, its lack of prose descriptions of the games led to its stub classification.

3. C Class Article

The third article I chose was in the middle of the quality scale, rated C class. This C class ranking is the equivalent of an average grade (an academic “C”). I chose the C class article, “Murder of Annie Le,” not because of its rank, but because it was created in response to a sensational event and expanded rapidly to include new information as it was discovered. In September, 2009, the investigation into the murder of Annie Le, a Yale graduate student who was found strangled to death in the campus lab where she worked, was heavily reported by the news media. This article illustrated one of the main strengths of Wikipedia: the capability to update information soon after it becomes available to the general public. I observed the article’s creation, rapid expansion, and settlement into a more stable rate of growth all within two weeks. Most of the information I discovered about how Wikipedia works was gleaned from my observations about “Murder of Annie Le.”

Insights Relevant to the Role of Editors in the Web 2.0 Environment

For this case study, I analyzed the revisions made to these three articles during the month of September, 2009. Thanks to Wikipedia’s revision history feature, which saves all previous versions of each article and gives users the option of comparing them, I didn’t have to do this study in real time. My coding scheme was a combination of categories developed by Dragga and Gong and Faigley and Witte.3

While the results of the data gleaned from my coding scheme were inconclusive, this process allowed me to make several insights relevant to the role of the editor in the Web 2.0 environment. Look for these results in the next issue of the Corrigo!

For more information on the theory of social construction, see Bruno Latour and Steven Woolgar’s Laboratory Life: The Construction of Scientific Facts. /}

Technical Creativity

Juliette Cannata

When I first entered the English Writing and Rhetoric program at St. Edward’s University in Austin, Texas, I never imagined I would develop such a passion for technical writing and editing. However, after being exposed to real-world technical editing at an early stage in my academic career and getting hands-on technical writing experience, I discovered a new facet to my writing personality.
In my second year at St. Edward’s, I was given the opportunity to apply for a job as a student intern for IBM/Tivoli Software as a technical editor (thanks to my wonderful professor, Dr. Anna Skinner). I got the job and immediately started editing Tivoli Field Guides (TFGs), which are technical documents created by Tivoli employees and customers to address complex technical issues such as installation, troubleshooting, implementation, and monitoring. At the beginning, I relied on my limited revising and editing skills, but I learned more and more with each passing day about the demands and “rules” for the field of technical editing.

The only problem was while I was learning how to be a more effective technical editor, I was also trying to figure out how to do other tasks that my job required, such as maintaining databases, updating expiration dates for TFGs, and interacting with authors. I was given a few sheets of instructions from the previous student intern, but, for the most part, I was left to ask my boss a million questions and figure things out by trial- and-error. As I became more comfortable in my job, this was no longer a problem.

Project Description

It was not until I enrolled in the Technical and Business Writing class my junior year that the problem of transitioning into a new job without any guide or instructions became an issue again. However, this time, it was an issue I was determined to solve.

My professor (Beth Eakman Re) assigned a semester-long project in which each student had to develop, write, design, and create an original handbook. We could choose our own topic, but the handbook had to be useful for a specific community or population. So, during the grueling process of trying to decide what topic I would be interested in enough to spend an entire semester writing about, the memory of trying to learn a job with limited resources popped into my head. I decided that a handbook for the Global Response Team Intern position at Tivoli was necessary to make the transition for future interns more efficient and less overwhelming. So began my first dive into the world of technical writing.

Challenges

The most challenging aspect of this project was learning how to take all the information about writing and designing I learned in class and apply it to this single document. At times I felt overwhelmed by the significance of each decision I made, from the over-all organization of the handbook to the colors I used on each page to the type of binding I chose. I have learned first-hand, in the technical writing world, everything must be intentional. There must be a reason for every word choice and design decision; otherwise, the audience will get lost or lose interest. Using that knowledge, I keep one statement in mind at all times when creating or editing technical documents: To be a technical writer is to be an excellent communicator with a heightened awareness and anticipation of audience needs and expectations.

Positive Outcomes

The most enjoyable aspect of this project was when I realized that technical writing is not devoid of creativity. I will admit that I believed this field to be dry and soul-deadening when I first entered it. However, after completing this project – and working for two years as a technical editor – I have learned that “creative genius” is part of the process of creating effective documents. One of the first questions any technical writer asks him/herself when sitting down to write is: “How am I going to get people to read this?” Answering that question is where the “creative genius” comes in. There are thousands of ways to craft a document in theory but only a few ways to make an effective document in reality. Knowing how to anticipate an audience’s expectations and figuring out all the little ways to keep people engaged while reading (and maybe even manipulating them to read things they would not normally read) takes a certain level of creativity that most people outside this field do not acknowledge.

By the end of the semester, I had produced my first official piece of technical writing: “A Guide for the Global Response Team Intern.” It is a 20-page document that is divided into five sections based on frequency of reference and importance of information: editing/publishing/updating TFGs, TFG locations, DCF submissions; time sheets; and frequently asked questions. All design elements of this handbook conform to IBM design standards, and all elements of content conform to Tivoli documentation standards. I had the opportunity to present this handbook to my supervisor and her manager, and it is officially part of the Tivoli Library.

Having the opportunity to create this handbook and gain experience as a hands-on technical writer, in conjunction with gaining experience as a technical editor, has shown me that this is a dynamic field that is constantly evolving. Although I stumbled into this field almost by accident, I have embraced technical writing as a passion that I will continue to pursue throughout my life.

Acknowledgments

I would like to acknowledge all the professors who have been my inspiration and pillars of encouragement throughout my college career. These professors have taught by example and had more patience with me than I have ever had with myself. They are some of the most intelligent people I know, not just because of their impressive degrees, but because they have real-world experience that they are so generous to share with their students. They are also some of the most inspiring people in my life because they are fountains of passion and love for writing and teaching.

I would also like to thank STC for awarding me the STC Technical Editing SIG Scholarship. I am truly grateful, and I am excited to continue exploring my passion for technical writing and editing!

Juliette Cannata has won the 2010 Diane Feldman Technical Editing SIG Undergraduate Scholarship.