Two key phrases: “I don’t know?” and “It depends.”

Are technical editors (or information architects, for that matter) allowed to use either of these two key phrases:

  • I don’t know.

  • It depends.

I can tell you that I have used both of these phrases, but I especially use “It depends” quite a lot, which of course greatly frustrates my team. In the business of writing, everyone hopes for black and white answers to their grammar questions or even to their design ideas. Team members turn to us, asking questions of all types, and we have to be willing to say “I don’t know,” but also be willing to offer up “It depends” as an answer to those questions.

My Twitter feed served up someone reacting to another tweet, about being willing to say “I don’t know,” and really wanting the stigma to using that answer removed. It immediately made me ask myself if I allowed myself to use those three little words. I do, and depending on who’s asking or the context, I will usually add, “but I can try to find out!”

I think editors (and information architects) are natural born researchers, who don’t want to accept the “I don’t know” answer. As for my very frequent response after doing said research… I often take great pride in responding, “It depends,” because then we all have a chance to explore the question a bit further and determine the direction to go. (A previous team said that they were going to get me a tshirt made with “It depends” on it, because I said it just that much with them. They were really after a yes-no answer.)

Happy editing everyone!

1 Comment

Filed under Technical Editing

Thinking about content strategy

My twitter feed served up the following tweet from Jonathon Colman (‏@jcolman) today (via a retweet by IA Institute (@iainstitute)):

Content ≠ “Write the words”
Design ≠ “Make it pretty”
Content + Design = EXPERIENCE.

Sometimes my title of information architect serves up fascinating and thought provoking information. I still consider myself a technical editor through and through, who happens to do information architecture work when editing content early in the development cycle. However, many of my colleagues have started calling themselves content strategists, so off I went to read this set of slides about building better content.

(I wish I could create slides like these. I wish I could have been in the audience wherever Colman presented these slides. But, I digress.)

There were three slides in particular that I responded to:

  • Slide 38, which shows where content creation fits in designing user experiences. It shows it in a Venn diagram, off to the side, and how it overlaps or is close to information architecture, and many of the other related fields or roles that folks are taking on. I need to study this slide again and again, taking lots of great ideas of content strategy.
  • Slide 62, which encourages everyone involved with content to always, always, always start with the WHY, before even thinking about the HOW, and well before thinking about the WHAT. As technical editors, we often come into the equation at the WHAT level, at the actual content, but we must start being involved with the inner layers of this onion, and bring that WHY into the WHAT that we are editing.
  • Slide 73, which just makes me smile. Slow down and fix (y)our stuff. Okay, he used a more colorful word than stuff. As I take a break from the madness of the fast-paced agile development that I live and breathe these days, any direction to slow down hits right at the heart of providing a quality assurance process, which is how I view technical editing (as my readers know).

Happy editing everyone!

1 Comment

Filed under Technical Editing

Proofreader’s marks

Should technical editors use the full set of proofreader’s marks in marking up content? How many of the standard proofreader’s marks do we even know any more? Back in the day of hardcopy editing, I think many of these marks carried over into the copyeditor and technical editor tools. However, as we started doing more and more of our editing online, in Microsoft Word or Adobe Acrobat, we learned to make do with what those tools provided. We adapted our marks to what was provided. Or, so I thought.

Adrienne Montgomerie recently posted an article to the Copyediting newsletter titled “The Secret Code of Proofreaders” (with the title cleverly including many of the proofreader’s marks). I learned that there are a set of stamps that you can import into Adobe Reader to use to make many more of these marks. I actually thought about downloading and playing around with some of these stamps. But then, Montgomerie also asked the question about whether designers will understand these marks and know what changes are required.

Update October 16, 2014:
My Twitter feed shared this post about proofreader’s marks this morning by Louise Harnby, which introduces and defends the value of the marks and their continued use.

As a technical editor working with very overworked technical writers, I must say that I rely on two of the marks that Adobe Acrobat provide in their reviewing tools: insertion and deletion (although that has become just strikethrough, without the tail on the end). Then, I use the comment bubbles associated with those marks or I insert text bubbles to put my queries and comments next to the place where I want to suggest a change. I think my writers would rebel if I required them to learn (or relearn) some of the standard proofreader’s marks, such as transpose or word break or line break. It is quicker and simpler for both of us to have me just insert a comment that explains that something is two words or that letters or words need to be transposed. Space was at a premium on paper, but not so in digital pages!

Happy editing everyone!


Filed under Copy editing, Technical Editing

A movie…about grammar? Pop the popcorn!

One of my favorite editor bloggers, John E. McIntyre of The Baltimore Sun, wrote a blog post about grammar, inspired by a blog post by Lucy Ferriss at Lingua Franca about the new documentary about grammar! Yes, I’ll geek out and watch said movie. Both blog posts are worth the read, even if you don’t want to watch the movie. After all, the book (blog!) is always better, right?

Comments Off

Filed under Grammar

Critical thinking and editing comments

In the Technical Editing Fundamentals course that I teach with Linda Oestreich, we provide a set of guidelines for how to make effective editing comments. We identify 4 types of comments: imperatives, suggestions, opinions, and queries.

So, when I saw this design-focused article on “3 Kinds of Feedback,” I was more than intrigued. It is nice to see my information architecture role overlapping with my technical editor role. The 3 kinds of feedback defined were: reaction, direction (our imperatives or suggestions), and critique. They propose that to give proper critique, you must use critical thinking, which the author defines as “the process of taking a statement and determining if it is true or false.” Then, in further defining critique: “Critique is a form of analysis that uses critical thinking to determine whether a creation is expected to achieve its desired outcomes.”

Thus, the conclusion I drew from this related article is: Technical editors must use critical thinking in making all of their editing comments, so that we help our writers create high quality content.

Happy editing everyone.

Comments Off

Filed under Technical Editing

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!


Filed under Copy editing, Substantive editing, Technical Editing