A humorous counter-argument

I haven’t posted to this blog in a little while, and I’m hoping that this humorous post will snap me out of my quiet and get me writing again (I have 3 ideas cued up, just need the hour or two to get the thoughts out on the blank screen).

Last year, I wrote about how much grammar a technical editor needs to know. Yes, I know, how heretical for me to postulate or ponder such an idea, even suggesting in the end that we don’t need to be grammarians.

Today, I ran across a very humorous (and geeky) cartoon that provides a counter argument. It is from the Words, Words, Words Facebook page:

Humorous cartoon about having to learn grammar

Happy editing everyone! I’m off to learn some more about grammar.

1 Comment

Filed under Grammar

Specialist or generalist?

Rosemary Shipton posted an interesting discussion question, What Should an Editor Be? (a generalist or a specialist), to The Editors’ Weekly, the official blog of the Editors’ Association of Canada. This question might very well have different answers for freelance editors than for in-house editors. As an “in-house” editor at IBM, I started to ponder this idea of specializing in a certain type of editing.

In this blog post, Shipton talked about only 3 types of editing: “structural, stylistic and copy editing.” I say “only” because many different types of editing have been defined over the years, beginning with the classic levels of edit from Van Buren and Buehler, who defined 9 different types of editing that combine to form 5 different levels. (You can read more about these levels of edit and the evolution of the different types of editing out on Wikipedia, of all places, where I am actually cited a couple of times – pardon the shameless plug!) This classic levels of edit system pretty much mandated that a technical editor be a generalist, able to do all 9 types of editing.

Certain industries or publishing environments might allow for specialists, however, and they are likely the only ones that might be able to appreciate the finer distinctions among structural, stylistic, and copy editing. My all-time favorite editing job was actually my first editing job as a development editor for a retail computer book publisher. While I did not completely turn off the copy editing or stylistic editing in that role, I primarily focused on structural editing, helping authors develop their books from the proposal and outline stage. By specializing and focusing on just those editing tasks, the chapters that the copy editor then received were well-organized, well-written chapters; the copy editors focused solely on the words and sentences, ensuring that grammar and company style rules were followed. This specialization doesn’t seem applicable across industries.

Shipton also commented that many clients lump all types of editing together as copy editing instead of viewing copy editing as one specific type of editing. This view is also suggested by Weber in her chapter “Copyediting and Beyond” in the book New Perspectives in Technical Editing (2010, pp. 85-105); she shows a Venn diagram of the overlapping nature and relationships of the different types of editing, with copy editing one of the larger circles. (You can also get a sense of her views about classifying editorial tasks, including tasks like technical editing and copy editing, on her site Technical Editors’ Eyrie.) I have a much narrower definition of copy editing, however, where copy editing focuses more on word and sentence-level issues; I think completing many types of editing together is more akin to technical editing overall.

Because I see technical editing as a combination of many types of editing (substantive, usability, copy, and policy), I don’t think technical editors can afford to specialize in one type of editing. We might be stronger in one type of editing than another, but we must be strong enough in all of the types of editing to be able to deliver readable and usable information to our users. Whether you have 9 types of editing or just 3 types of editing, I think a technical editor must have some amount of proficiency in all of the types, which means that we must be generalists to be the arbiters of quality for our users.

Happy editing everyone!

4 Comments

Filed under Copy editing, Substantive editing, Technical Editing

Making information findable…what must technical editors do?

I recently re-read this blog post about findability (by Mark Baker on Every Page is Page One) and what writers need to do to their topics to ensure that users get to the information that they want. (Peter Morville popularized the concept of findability in his information architecture book, Ambient Findability.) This got me thinking: As a technical editor, what must I do to make information more findable? Here’s what sprung to mind:

First and foremost, I anticipate how the user thinks about the subject. I need to understand what technical terms in the information are a part of the users’ natural language and which are just confusing jargon. I need to bring the users’ language to the table when editing the information. This is especially true for titles and initial paragraphs, which search engines rely on to determine how to rank order search results. Front-loading topics with the language of the user (with their search terms) makes the information more findable.

Next, I must remember that the whole is greater than the sum of its parts. I cannot edit just the text; I must edit all aspects of the information, including all navigational aids such as a contents view, the index, and inline links. Links especially enhance the findability of information, both the information that is edited and the information that is linked to. I need to consider when, where, why, and how writers include inline links to related information. I need to test the links, but I must also evaluate the links to determine if they are necessary or if they provide useful additional information.

Lastly, I need to edit the topics for an optimal length. One of the tricks of search engine optimization (SEO), or making your information findable, is making sure that the content is not too long. Some search engines rank pages higher if their overall word count is between 300 and 500 words.

By front-loading topics with the search keywords of your users, by including links to relevant information, and then by making the topics not too long, you achieve a clustering of search keywords, ultimately making the topic more findable.

Happy editing everyone!

Leave a comment

Filed under Technical Editing

Nonknowledge: Intelligent, nonspecialist engagement

I was absolutely fascinated by William Germmano’s Lingua Franca post “Nonknowledge (and Why It’s Good in Editors).” While it focused on nonknowledge being a critical tool for acquisitions editors or for scholarly publishing, it expressed a belief that I have about technical editors not needing to be an expert in whatever subject they are editing.

I must call out this particular quote:

…a difference between ignorance (as not knowing about a subject) and nonknowledge, as a state of highly intelligent, nonspecialist engagement. That distanced, nonspecialist attentiveness…”

In my career as a technical editor, I have worked on products meant for programmers, physicians, network engineers, data scientists, and marketing professionals. I have used my nonspecialist engagement or my nonspecialist attentiveness, along with my natural curiosity, to learn enough about the products that we are writing about, such that I can find the logical and potential technical issues inherent in the drafts of documentation that I edit.

I think technical writers must cross over the line and become technical specialists, gathering actual knowledge of the subject, in order to write useful documentation. However, technical editors can take advantage of their nonknowledge, or perhaps the highly limited knowledge, to provide a critical review of the information, pointing out logic breaks, missing information, or areas of confusion. Technical editors must use a beginner’s mind to untangle some highly technical information. I like the label of nonknowledge even more.

Happy editing everyone.

2 Comments

Filed under Technical Editing

Consistency among editors

Writers are often frustrated by the idea that if two different editors looked at the same document they would not mark it up the same way. While certainly a large portion would be similar, maybe even the same, many differences would exist. Even if editing to the same style guide, editors will react or respond to the content differently. One editor might let a long sentence go, whereas another editor will break it into two. It is possible that the same editor seeing similar content at two different times might edit similar sentences differently. (Yes, I’ve done this.) As editors, we must fight against our own biases or soapboxes or “bugaboos” (as I like to call them) to bring consistency to our own editing but also among other editors that we might work with. Of course, when working with other editors, we sometimes pick up these bugaboos from them, bringing some consistency to the teams.

This notion of consistency among editors was inspired by An American Editor writing about a futile quest for perfection in editing. I wholeheartedly agree that there can be no perfection in editing. As technical editors, we cannot be perfectionists. Sometimes, good enough is perfect, and we must listen to Voltaire who said “The perfect is the enemy of good.”

1 Comment

Filed under Technical Editing

What is grammar, and exactly why it matters

Quite a few of my posts this year were all about how much grammar technical editors need to know to be good editors. This morning, my Twitter feed led me to the following blog post that sums up my views precisely. Go read this blog post: “Grammar, brain surgery, and idiots: Why pedants and creative hippies have got it wrong.” Instead of just retweeting this link, I had to make it a part of my own blog, to end my musings on this topic for the year, and hopefully move on to something else of interest.

2 Comments

Filed under Grammar

Technical editors help reduce writer errors

I recently read a blog post on the “Every Page Is Page One” blog called “Reducing writer errors.” I’ve been reading the series of posts by Mark Baker about improving the content creation process, and I thought for sure that this particular post would mention technical editors. Alas, I was wrong. He talks about checklists (not editing checklists, just checklists), and he mentions (and discounts) technical reviews by SMEs, as a way to reduce the errors that writers make. He concludes his post with a nice list of systemic or process-oriented ideas for reducing errors. However, he never once considers adding a technical editor to the team to ensure the quality of the information and reduce the number of writer errors in the content creation process. I realize that not many writers have the opportunity to collaborate with a technical editor, but it saddens me that editors were not even mentioned as one way to reduce writer errors.

Leave a comment

Filed under Technical Editing