I really liked this “Copyeditor’s Typographic Oath,” except the part about it being a typographic oath. This oath was originally presented in an article titled “The Need for Guidelines” posted by Erin Brenner on Copyediting.com. In this same article she presents “Commandments for Copyeditors” that the Editorial Eye published a bit ago. All of these lists are rules to live by as editors.
I really love the first rule or commandment: Do no harm. I think this speaks to making a change only when you can back it up by a guideline or standard. I think this is tempered with the third one: Respect the reader. I think this should actually come before the second one: Respect the writer. I think if we adhere to the first rule (do no harm), then we are automatically respecting the writer’s work. Many of the others seem more project-management oriented, where these first three speak to the fundamental values of the editing process.
This oath was presented again in a new series of articles about avoiding editing paralysis, Part 1 being about Having the Right Attitude. Brenner talks about how the first rule breeds perfectionism in new editors, keeping them in fear of making any mistakes, suggesting that editors cannot make mistakes. I’ve never bought in to that, and I always talk with my writers about how I definitely can make mistakes. We’ll often discuss my editing comments and the guidelines or standard that inspired them, and together we decide what is right for the reader.
Happy editing everyone!
Are technical editors (or information architects, for that matter) allowed to use either of these two key phrases:
I don’t know.
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!
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!
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!
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?
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.
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:
Happy editing everyone! I’m off to learn some more about grammar.