Corbin, Michelle, Pat Moell, and Mike Boyd. ”Technical editing as quality assurance: adding value to content. (Applied Theory).” Technical Communication 49.3 (August 2002): 286(15). Academic OneFile. Gale. Eastern Michigan University. 5 Oct. 2007
<http://find.galegroup.com.ezproxy.emich.edu/itx/start.do?prodId=AONE>.
Summary
This is a very long article, so I will attempt to hit all the major points without going into too much detail; otherwise this summary will be five-pages long, and that is just too darn much for anyone to handle right now.
Basically, these researchers (Michelle Corbin, Pat Moell, and Mike Boyd) are comparing software testing and technical editing in order to show how the levels-of-edit systems can help to add “value to content” well before the product is released. The “quality assurance” comes through content editing, and this shows that “technical editors add value to the information development process and help to give users the quality content that they deserve” (287).
After the initial introductory pages that outline what they are going to study and why, the researchers begin to explain software testing, and then they compare it to technical editing. It is fascinating how similar they are, and I began to draw comparisons with children’s nonfiction editing, which I discuss further in the Pertaining to Project section of this paper.
It is difficult to explain all of their comparisons in full detail, but I would like to point out some of quotes I found most interesting. They are normally discussing editing at the comprehensive level, though they do point out that the “lower” levels are just as important, as well.
–“[E]ditors can catch structural flaws early in the development cycle, thus improving quality and reducing costs, because additions and changes are not perpetuated within an already flawed structure” (290). This quote is meaningful because it puts into perspective how important a technical editor can be, and it also shows how important it is to get a detail-oriented, well-qualified editor to evaluate work.
–“Technical editors must know how each information deliverable fits with the others, and they must know the users and how those users work with the software” (291). What the researchers are describing here is user-centered editing, and this directly pertains to my project. I also like how they mention multiple users, though I don’t think they were meaning that there is more than one type of user; there is just more than one user. Though this means it doesn’t fit perfectly with my project, it still lends proof that editors, technical or otherwise, act in place of the user and keep the user(s) in mind at all times in the editing process.
–“Technical editors cannot replace the usefulness of actual usability testing; however, they can stand in for the users by becoming the ‘first users’ of the information” (293). This quote backs up the previous quote: Editors continually have the users in mind, even going so far as to stand in their place when using the table of contents and index. Children’s nonfiction editors do this, as well, though they step into the shoes of a third grader versus technical editors, who may be looking at the product through the eyes of an adult professional. Nonetheless, user-centered editing and design are an imperative part of the levels of edit.
This all ties back to quality assurance because the editors are continually making decisions that will affect the outcomes of the product. When they engage in comprehensive editing, they are providing a service not written into their job description—they are acting as user, editor, designer, and writer, all the while making sure the product published is of the highest quality. When they begin their part of the process with comprehensive editing, they are ensuring that no mistakes are left unchanged. They are saving their company time and money. What CEO wouldn’t love that?
In the end, this article is part handbook for technical editors and part advocate for the technical editor as a crucial part of the publishing process. It has a lot of viable information for the technical editor, technical writer, and company in need of this quality assurance.
Pertaining to Project
I chose to look at two articles on opposite ends of the spectrum for a reason—I wanted to start making connections between children’s nonfiction and publishing and between children’s nonfiction editing and technical editing, which user-centered design theories have already been applied to. I will make the connection between them all soon enough.
This article is pertinent to my project because it is helping me to make those connections between kid lit editing and tech editing. I have to admit that they are very similar. This will make the connections between the user-centered design theories and kid lit editing a lot easier. I am already seeing how I can apply user-centered design theories to editing.
Technical editing and kid nonfiction editing have many similarities. The technical editor is the designer of the document, and kid editing is the same. “‘The technical editor is an advocate for the language, the company, the writers, and, most importantly, for the users’” (288). This is also true for children’s nonfiction editors, and, again, being an advocate for the users is the most important aspect of their overall advocacy. Kid nonfiction editors act as user during the editing process, and that can mean stepping into the shoes of the teacher, librarian, or student.
Though this article doesn’t directly say, “We’re applying user-centered design theories to technical editing,” that is what they are basically doing, through the levels of edit. I had never thought to use the levels of edit, which I am now well-versed in thanks to my Technical Editing class, which I took last winter. Though simple and made for the sciences, the levels of edit can be modified for different situations, and they be useful in my study. I will keep this in mind as I progress through the planning parts of the project.