#22128
'It's all in the manual.' How many times have you heard that - or said it in frustration? After all, when you are the person who wrote the manual, you know that all the answers are there. But time and again readers can't find what they need to know, or don't understand the material. Before you blame the reader, look again at how you've presented the material.
Hollis Weber, Jean. Technical Editors Eyrie (1989). Articles>Editing>Technical Writing
#31098
As a technical writer, you'll typically have to create indexes for the print books and for online helps you develop. The type of index we mean here is the classic back-of-book index that shows page numbers on which topics and subtopics occur within the book. An online index is much the same except that you supply hypertext links rather than page numbers.
McMurrey, David A. Illuminati Online (2004). Articles>Editing>Indexing>Technical Writing
#32036
Editing Modular Documentation: Some Best Practices
Much has been said about the creation of modular documentation - from content management systems, to information architecture, to delivery forms, to the usability of modular content (content being easier to use, easier to understand, and easier to find), and so on. However, not much has been said about the editing of that content, and what the editor's role is in such an environment.
Corbin, Michelle and Yoel Strimling. WritersUA (2008). Articles>Documentation>Technical Writing>Technical Editing
#21411
Editing Your Own Documentation 
Technical writers sometimes fall into the trap of thinking that the user is stupid. I have often heard technical writers say things like 'well, if the user can't figure that out, maybe he’s in the wrong job!'
Docsymmetry (2003). Articles>Documentation>Editing>Technical Writing
#30361
Here are some tips that helped me edit my own writing.
Leigh, Heather. Crazy for Words (2007). Articles>Editing>Writing>Technical Writing
#29647
Experiencing Technical Writing as Textual Coordination 
This paper describes a recent study of how of four technical writers managed the many artifacts (existing texts and information technologies for producing and manipulating text) that mediated their writing process. The author describes the study and characterizes several recurrent patterns of mediation, including textual reuse, remediation of information, and the staging of texts and software programs. The author describes the value of a repertoire of information technologies to technical writing and argues that technological skill should be considered a core competency of the field.
Slattery, Shaun. STC Proceedings (2005). Articles>Writing>Technical Editing>Technical Writing
#24197
I labeled wordiness the most obvious fault in technical writing. In retrospect, I think I was wrong. I believe the greatest fault our writing can have is vacuity, or lack of substance. We too often write words that say nothing.
Bush, Donald W. Intercom (2004). Articles>Editing>Technical Editing>Technical Writing
#22691
Don't you think that it is a tragedy that 95 percent of the people who desire to be technical writers have a poor command over the language? I am sure all of us make a mistake or two, once in a while. But to make it in every sentence and paragraph shows utter disrespect for readers.
Kamath, Gurudutt R. IT People (2003). Articles>Editing>Grammar>Technical Writing
#30818
Hockey Sticks and User Assistance: Writing in Times of Resource Constraints
If you have all the resources you need, do the very best job you can in all respects. But if your resources are tight, ask yourself whether you are writing the essential stuff at a level of quality users will notice. Also, ask whether the value of the documentation you are producing aligns with the economic pressures on your company.
Hughes, Michael A. UXmatters (2008). Articles>Writing>Technical Editing
#19673
Editing involves more than just formatting and inserting page numbers. You need to ask, 'How can I improve the communication?'
Bush, Donald W. Intercom (2003). Articles>Editing>Writing>Technical Writing
#22690
Learning the Fine Art of Reviewing
If you asked me what the most painful part of being a technical writer is, my answer would be: 'Getting reviews on time. Getting good feedback and inputs on your work.' For me technical writing has been very pleasurable because I hardly got any review comments. My morale has therefore been very high. Project managers, developers and others are so busy trying to come up with good software (read trying to fix all the goof-ups and bugs!) that they usually tend to give documentation lesser importance. User manuals, who reads them anyway? We do not have time for it!
Kamath, Gurudutt R. IT People (2003). Articles>Editing>Collaboration>Technical Writing
#27461
Now That You've Got a Double Agent, What Do You Do With 'Em?
Having demonstrated the importance of acquiring a double agent for writing projects, we now want to explain the best ways to successfully indoctrinate a double agent. This paper will help you prepare for, orient, train, and become a mentor for a double agent to help make him or her an effective member of your writing team.
Fisher, Judith R., Karen L. Mobley and Michelle M. Wright. STC Proceedings (1994). Articles>Writing>Technical Editing>Collaboration
#22687
One Hundred Simple Tech Writing Errors
Here are the 100 writing errors that the author has encountered in his experience. (Followed by the subsequent article 'Ten More Errors in Technical Writing.')
Kamath, Gurudutt R. IT People (2003). Articles>Editing>Grammar>Technical Writing
#22113
The Role of the Editor in the Technical Writing Team
Editing today covers far more than printed materials. In this discussion, I am assuming a technical editor may be required to deal with: printed materials (for example, books, pamphlets, quick reference cards); electronic (for example, online documentation, online help, web pages); video scripts; computer-based training materials. I am also assuming that the audience for the material being edited is not comprised of other technical people; or if it is, the editor is not the person responsible for ensuring the technical accuracy of the material.
Hollis Weber, Jean. Technical Editors Eyrie (2002). Articles>Editing>Collaboration>Technical Writing
#32043
Tech Writers, Grammar, and the Prescriptive Attitude
Prescriptive grammar is useful for teaching English as a second language, but it has little value for the practicing writer. Clinging to it may provide emotional security, but only at the expense of making writing harder than it needs to be. The culture-wide devotion to it will not be changed in a moment. But conscientious writers can at least change their own habits, and make life easier for themselves.
Byfield, Bruce. TECHWR-L (2008). Articles>Writing>Editing>Technical Writing
#22791
Technical Translation: Craft, Not Commodity
Describes the work of translators and suggests strategies buyers can use to find the best translator for their needs.
Cardillo, Louis M. Intercom (2004). Articles>Editing>Localization>Technical Writing
#31939
Technical Writing's Big Secret
The big secret in technical writing is that most of the harder documents aren't written by the technical writers at all. In fact, many "technical writers" never do any writing at all. Instead, the drafts are written by engineers or marketers. The technical writers perform editorial functions and provide publications services -- copy-editing, layout, review management, and so on.
Plamondon, Robert. High-Tech Technical Writing (2008). Articles>Writing>Technical Writing>Technical Editing
#26967
Der Technische Redakteur erstellt und aktualisiert aussagefähige, umsetzbare, verständliche technische Dokumentationen aller Art.
#22688
Ten More Errors in Technical Writing
So, well, here are 10 more errors. This time we will focus on grammar and punctuation. Most of these are simplistic and obvious. But then they are too common. As usual, I have slipped in some content for the advanced writers too. (This article is a follow-up to 'One Hundred Simple Tech Writing Errors .)
Kamath, Gurudutt R. IT People (2003). Articles>Editing>Grammar>Technical Writing
#35710
Writing Great Documentation: You Need an Editor 
All good writers have a dirty little secret: they’re not really that good at writing. Their editors just make it seem that way. It doesn’t matter how well you’ve mastered the language; nobody, even grammar geeks, gets this stuff right on the first pass. If you really want to produce great documentation, it needs to be edited.
Kaplan-Moss, Jacob. Jacobian (2009). Articles>Documentation>Technical Writing>Technical Editing
