#23398
A problem that sometimes occurs, when authors ask my advice about the method of presenting an instruction, is that they use words that I think will not necessarily be understood by people whose mother-tongue is not English.
Farrington, Gordon. TC-FORUM (1999). Articles>Documentation>Writing>Technical Writing
#21408
Mistakes Technical Writers Make 
Inexperienced technical writers typically make a number of avoidable mistakes, including parroting the SME and hard-coding xrefs. Here is a description of some mistakes to avoid.
Docsymmetry (2003). Articles>Documentation>Technical Writing
#31109
Musings on User-Generated Documentation
User-generated documentation is a big issue in technical communication circles. If properly done, tapping into the knowledge of users can improve the quality and breadth of your documentation.
DMN Communications (2008). Articles>Documentation>Technical Writing>Wikis
#29695
The Presentation of Safety Information in Product Manuals 
Technical communicators may be asked to design and develop safety information for a product manual. During this process, technical communicators can add value to the presentation of safety information. In addition to adhering to a manufacturer’s internal guideline for the content and formatting of safety information, other factors can be considered as well. This paper presents the following factors: (1) an overview of common failure-to-warn allegations, (2) an analysis of current practices in automotive owner’s manuals for presenting safety information, and (3) an update on a new ANSI Z535 consensus standard for the presentation of safety information in product manuals.
Wisniewski, Elaine. STC Proceedings (2005). Articles>Documentation>Risk Communication>Technical Writing
#21228
The Procedure Writer©: A Wizard, A Writing Guide And Nine Magic Templates
The Procedure Writer is an easily navigable collection of steps: a wizard with seven windows, nine templates, and instructions that offer the user-cum-writer the maximum freedom in determining how a module is written. At the same time, the instructions and the nature of the templates are designed to obligate the writer/user to follow P&P standards.
King, Geoffrey, Tom Tomasovic and Mandy Huang. STC Proceedings (1996). Articles>Documentation>Writing>Technical Writing
#30561
Reducing Complexity in Documentation
With more emphasis being placed on customer satisfaction, technical writers need to focus on information strategies that will lead to happier customers. The complexity of the information is one common complaint of customers. Writers need to understand what customers think is complex. Then, writers need to develop strategies to combat these complexities.
Roscoe-Iverson, Ellen. STC Proceedings (1993). Articles>Documentation>Technical Writing>Minimalism
#20639
The Rhetoric of Critical Procedures
One important aspect of technical writing is the production and use of procedures. Though technical writing serves a variety of purposes, teaching, informing, persuading, and even questioning, one of its primary and most common purposes is the 'how-to' function of providing procedures. There is a great deal of information available on writing procedures, the vast majority of it focusing on software documentation and product documentation.
Boelter, Walter H. Orange Journal, The (2003). Articles>Documentation>Rhetoric>Technical Writing
#24314
Robert Pirsig’s Message for Documentation Quality
Teachers of technical communication frequently recommend that their students read Robert Pirsig's Zen and the Art of Motorcycle Maintenance (1974) for his views on the complex relationships between technology and human values. As a former technical writer, Pirsig also offers some useful advice about Quality and its relation to the usability of technical documentation. Revisiting Pirsig’s works, including the more recently published Lila (1991), reveals concepts about Quality in documentation that are especially relevant to the usability testing of the documentation for today’s rapidly evolving technologies. This paper examines Pirsig’s views on the some of the characteristics of effective technical communication, and it offers advice to educators and trainers for incorporating Pirsig’s concepts about Quality into their teaching of techniques for the usability testing, and hence quality, of user documentation.
Shirk, Henrietta Nickels and Howard T. Smith. STC Proceedings (1998). Articles>Documentation>Quality>Technical Writing
#28083
S1000D: A Standard for Technical Documentation
S1000D is a military standard for the creation and delivery of technical documentation. Many companies can benefit from its methodology. Review its history and principal concepts, and learn important information to keep in mind when applying the standard to your work.
Weidenbrueck, Dieter. Intercom (2006). Articles>Documentation>Standards>Technical Writing
#24660
Security Policy and Procedures Documentation
With the nation intensifying its homeland security and industry focusing on computer security, the experienced technical communicator can assist with documenting procedures.
Albing, Bill. KeyContent.org (2004). Articles>Documentation>Policies and Procedures>Technical Writing
#24657
Software Development Kit (SDK) Documents in 10 Simple Steps
Here are the ten simple steps to successful software development kit (SDK) documentation.
Buck, Catherine. KeyContent.org (2004). Articles>Documentation>SDK>Technical Writing
#27584
Software documentation or source code documentation is written text that accompanies computer software. It either explains how it operates or how to use it. In fact, the term software documentation means different things to different people. This article describes the term as used by the largest groups of users.
#20555
Software Documentation Process: Symbios Logic
This panel presents the software documentation processes of three companies. Participating on an interface design team allows writers to contribute to a software’s usability and to develop supporting documentation early in the software’s development cycle. This presentation summarizes the crossfunctional team’s process and strategies for designing the interface and for preparing usable support products. I will also review the successes and problems we encountered as we created online help and a printed user guide. Writers can learn about Symbios Logic’s interface design team as one approach to creating usable software with accurate, quality documentation. At Symbios Logic, one of our goals is to develop data storage products supported by accurate, easy-to-use documentation. The major challenge we face in completing this documentation is meeting the release dates for our products. To achieve this goal, we are re-designing our latest software by combining both interface and documentation development into one design process.
Burroughs, Dia H. STC Proceedings (1996). Articles>Documentation>Writing>Technical Writing
#21234
Starting with the Vendor's Documentation
When a company purchases software for in-house implementation technical writers can contribute to the implementation and training by customizing the vendor’s documentation. This paper describes three strategies with case histories: rewrite; revise and expand; supplement. It offers hours-per-page statistics for comparison and outlines a method of analyzing how much to invest in additional documentation. This paper focuses on user’s guides, but the logic also applies to training guides and on-line help.
Littlewood, Ann P. STC Proceedings (1995). Articles>Documentation>Writing>Technical Writing
#23752
Strategies for Winning Recognition: Building a Visible, Viable, and Valuable Documentation Team
Technical writing teams can improve their standing within their organizations. The purpose of this presentation is to share our experiences at Mirant where we've achieved recognition and respect as a vital internal service to the IT department and, increasingly, to the rest of the company.
Harkness, Holly E. STC Proceedings (2003). Articles>Documentation>Collaboration>Technical Writing
#29445
Taking Advantage of Reflexive Responses
None of us likes to admit that we have conditioned reflexes that override our higher cognitive abilities, yet such denials notwithstanding, each of us does occasionally respond without thinking something through clearly. As technical communicators, it's important for us to accept this fact of human nature and plan for it in our documentation, and to work with the developers of the products that we document to both take advantage of the helpful reflexes and find ways to ward off the harmful ones.
Hart, Geoffrey J.S. Geoff-Hart.com (2001). Articles>Documentation>Writing>Technical Writing
#20580
Teaching Documentation Writing: What Else Students--and Instructors--Should Know 
Discusses knowledge, problem-solving strategies, and desktop publishing skills students need to learn about documentation writing. Describes a course that provides these skills. Also applies to in-house training programs.
Boiarsky, Carolyn and Michael Dobberstein. Technical Communication Online (2003). Articles>Education>Documentation>Technical Writing
#23154
The Team Approach to Writing Policies and Procedures
Although many companies claim to have working teams within their corporate structure, it may be difficult to use the same approach for writing documentation. With the demands for controlled documentation to meet quality standards, involvement in policy/procedure writing is an important factor in developing a sense of ownership and commitment to maintaining a document control system. A team approach to writing procedures may involve more time, but the results are operations consensus, improved writing skills, and a boost of professional confidence.
Whitmer, Diane L. STC Proceedings (1996). Articles>Documentation>Technical Writing>Collaboration
#24526
How to write effective technical documentation.
Streight, Steven. Blogger.com (2004). Articles>Documentation>Writing>Technical Writing
#32038
Technical Support According to Dilbert
Help desks often follow written scripts based on how an application should work, but what if the user is faced with something out of the ordinary, and it’s something not written in the script? Software might not always behave as it’s supposed to; did a technical writer somewhere have to form a logical conclusion that might not have been correct?
Rosberg, Joe. TechRepublic (2008). Articles>Documentation>Writing>Technical Writing
#29894
Technical Writing and Instructional Design Techniques
Technical communicators and instructional designers use similar techniques in producing written documents. This paper discusses how the Perot Systems Instructional Design team creates its documentation in a similar manner as technical communicators. We start by discussing the use of the ADDIE model for developing documentation; 2) explaining how we implement our Word and PowerPoint style guides with a brief mention about our client-driven Training Engagement Methodology; and 3) ensuring copyrights are respected. The subject matter experts that we support as technical communicators and instructional designers sometimes view us as the documentation police because we constantly question the data and quotations.
Damrau, Jackie. STC Proceedings (2004). Articles>Documentation>Writing>Technical Writing
#23698
Technical Writing in Everyday Life: One User's Experience
The experience of setting up a new home theater system also sharply reminded me of what it is like to look at something as a new user: staring at a bunch of knobs and holes for the first time, holding a tassel of wire in one hand and a manual in the other, and really just wanting the darn piece of ?%^%! to do what it's supposed to do.
Vedrody, Sarah. MetroVoice (2002). Articles>Documentation>User Centered Design>Technical Writing
#21409
The technical writing process consists of four phases: planning, writing, delivery and archiving. The phases of the technical writing process are not necessarily discrete. You might start the writing phase before you complete the planning stage, for example, or you might have to deliver the documentation before you feel it is finished. It is highly unlikely, however, that you will ever archive the documentation before you deliver it! Some products are released several times. In this situation, you might be in the delivery phase of the first iteration of the project while you are in the planning phase of the second iteration. Don't panic: overlap in the technical writing process is quite normal.
Docsymmetry (2003). Articles>Documentation>Workflow>Technical Writing
#21543
Technisch Schrijvers Schuwen Onderzoek: Toch Kunnen Onderzoeksresultaten Praktisch Toepasbaar Zijn
This article, which appeared in the Dutch journal Tekst[blad], describes four recent studies that are relevant to help developers, and suggests how help developers can use the knowledge gained from those studies to improve the performance support systems they build.
Hayhoe, George F. Tekst[blad] (2000). (Dutch) Articles>Documentation>Usability>Technical Writing
#31751
Thinking Outside the (Tech Docs) Box: Structured Authoring as Competitive Advantage
There was a time when technical writing was seen as a cost center—a necessary function, but hardly a key lever for competitive advantage. This is quickly changing as globalization and hyper-competition put customers in control and organizations scramble for new and different ways to strengthen relationships.
Sorofman, Jake. Content Wrangler, The (2008). Articles>Documentation>Writing>Technical Writing
