Technical editors are people who edit technical information. They work in many fields, including engineering, computer hardware and software, science, medicine, law, banking, and website development for any business or activity.
Technical editors’ primary job is to ensure documents are suitable for their target audience, thus technical editing is really a quality control job.
This website is a place for technical editors to:
- Share knowledge, experiences and resources
- Demonstrate to writers, managers and others the wide range of knowledge and skills technical editors have to offer
Non-editors are welcome too! Much of the information you’ll find here is applicable to writers, managers, and people working in other roles, and many editors have other job titles or multiple roles.
Paul Ford, in Real Editors Ship, says some things I’ve been trying to tell people for years. Other editors will understand what he’s talking about; many of the people who need us most won’t get it. Here’s a quote:
Editors are really valuable, and, the way things are going, undervalued. These are people who are good at process. They think about calendars, schedules, checklists, and get freaked out when schedules slip. Their jobs are to aggregate information, parse it, restructure it, and make sure it meets standards. They are basically QA for language and meaning.
The Diagnosis-Resolution Structure in Troubleshooting Procedures, by David K. Farkas, on the WritersUA website.
In this paper, I define troubleshooting procedures and briefly sketch out how they are developed. Then I analyze the genre’s underlying architectural structure of diagnosis and resolution, showing both simple and complex configurations of symptoms and solution methods. These configurations are in part constrained by the nature of the technical problem; but they are also the consequence of design decisions. Understanding structure enables us to meaningfully classify the very diverse instances of this genre, reveals key design issues, and is apt to contribute to experimental research insofar as structure is central to many of the most useful research questions we can ask.
A reader wrote:
I have a quick question for you about numbered heads in documents.
In general, numbered section heads use the chapter number as the first digit – but that’s only if you have multiple chapters in a book (1.1, 2.1, 3.1…).
What if you have only one chapter in a book? Do the sections become 1, 2, 3…?
I haven’t been able to find anything discussing this, so if you know of any reference material to back this up, I’d be much obliged!
I haven’t tried this extension to OpenOffice.org, because I don’t use Windows, but it sounds interesting (if not misused or abused as often happens with “readability” scores). Would like to hear from someone who has used it.
The Readability Report tool scores your document for readability, cohesion and information density. These scores provide the author with an indication of how well the intended audience will understand the text. The scores use a variety of computational linguistic techniques to determine the reading level of the text.
The American Society of Composers, Authors and Publishers (ASCAP) has launched a campaign to raise money from its members to hire lobbyists to protect them against”the dangers of Copyleft, which they claim groups such as Creative Commons are promoting in order to undermine Copyright.
If you are unfamiliar with the licenses promoted by Creative Commons (CC), you might be taken in by these claims, but they are not true. Lawrence Lessig, cofounder and board member of CC (his day job is Harvard Law School professor and director of the Safra Center for Ethics) explains the situation in this article. In brief, what CC promotes is choice for creators of works (writers, musicians, artists), using more flexible variations on copyright license terms.
At the AODC 2010 conference, Sarah Maddox, who works for Atlassian, an agile development environment, spoke on engaging readers in the documentation and the concept of documentation as an emotional experience.
Sarah explained the advantages to both the customers and the company of involving readers (users) and discussed some of the techniques that Atlassian has been experimenting with. These include social media (blogs, a forum, and Twitter), a “doc sprint” (an intensive time spent producing documents such as tutorials), encouraging users to update community documentation on a wiki, links to readers’ blogs, and an interactive game that customers can use to help them through the complex installation and configuration of a product.
Continue reading →
The 13th Australasian Online Documentation and Content Conference (AODC 2010) was held in Darwin, Australia’s Northern Territory, 12-14 May. I found the conference both highly informative (all of the sessions interested me) and a lot of fun; thus it was well worth the cost.
Some highlights for me included the talks on structured content and DITA, engaging your readers with the documentation, an overview of Google Apps, user assistance design and implementation for iPhone apps—and the chance to fondle an iPad several weeks before they became available in Australia. I’m now mulling over the possibilities for putting some of what I’ve learned—about both structured authoring and engaging readers—into use at OpenOffice.org.
For details of the speakers and their topics, see speakers page and the agenda pages on the AODC website. The speakers are regulars at AODC as well as WritersUA and similar conferences, with new material every year, presented in an entertaining manner.
I am not going to attempt to summarise the sessions, though I’ll mention some topics of particular interest to me in subsequent blog posts.
This article is part of a series of examples of editing illustrations.
This example is taken from one of the OpenOffice.org (OOo) user guides, which was being updated from OOo version 2 to version 3. I show the author’s instructions to the illustrator, the figure the illustrator produced, and my analysis and edit of the figure.
Continue reading →
Geoff Hart’s Effective Onscreen Editing is an essential resource for anyone who edits onscreen, regardless of the word processor in use. Geoff’s examples are from Microsoft Word, but most of his recommendations can be translated readily to OpenOffice.org or other programs. The book is available in both PDF and printed forms, each optimised for its format: the PDF is in landscape format, while the printed book is in portrait format. See this page for details.
Continue reading →
This article is the first of a series of copyediting examples, taken from the OpenOffice.org (OOo) user guides. I won’t be looking at grammar, punctuation, and spelling (the topics most people associate with copyediting) but rather at other errors that copyeditors should also be looking for. These errors include (but are not limited to) incorrect cross-references, missing or duplicated information, incorrect or unclear figure captions, and incorrect fonts.
Look at each of the examples. How many errors can you spot? How many things should you check to determine if they are correct or wrong? (I missed all of these on a previous, rushed, pass through the document. We definitely need more people reviewing/editing/proofreading/final checking the user guides.)
Continue reading →
