#29622
A Process Model For Creating Accessible End-User Documents 
Electronic information products can be made accessible to blind and low-vision individuals. This is easier to accomplish with thorough planning and execution. This paper describes a five-step model for creating accessible documentation. The steps are (1) Preparing a source file (2) Producing accessible output, (3) Testing output for accessibility, (4) Modifying a source file if needed, and (5) Modifying a production process if absolutely necessary.
Herring, Richard D. STC Proceedings (2005). Articles>Documentation>Writing>Technical Writing
#20548
Adding Life to Your Documentation
Suggests several techniques technical writers can use to enliven their writing and improve their documentation.
Potsus, Whitney Beth. Intercom (2003). Articles>Documentation>Writing>Technical Writing
#24220
Anything That Can Go Wrong: Lessons Learned from A Decade of Toolkit Documentation
Writing software toolkit documentation for programmers is a special challenge and opportunity for technical writers. Compared with writing software documentation for lay users, toolkit documentation is more demanding and exacting. Checking facts and finding tiny errors is like riding a motorcycle through a swarm of gnats. However, for me at least, toolkit writing has opened doors to a larger role and greater input into product design. Engineers treat me like a peer and I get to see into their culture. I know my readers and salespeople need me.
van Oss, Joseph E. STC Proceedings (1999). Articles>Documentation>SDK>Technical Writing
#28228
Applying Web 2.0 Technologies to Technical Documentation
This article is based on my presentation at the Institute of Scientific and Technical Communicators' annual conference in October, 2006. Every now and then, there is a change in the value of what technical authors deliver. These are moments when organisations pay attention to technical documentation. This is because they recognise that these changes mean they can create something that will be of real value to the business and to their customers. In recent years, there have been three "waves of interestingness". The first wave was the introduction of Windows Help (WinHelp). The second major wave was the introduction of the Internet and intranets. This was a time when organisations looked at how they could transfer large amounts of information from paper to online. They were faced with issues such as how users could access and understand all this information easily - issues that technical communicators deal with on a day-to-day basis. I believe we're just about to approach the new wave, which we have called "Tech Writing 2.0".
Pratt, Ellis. Cherryleaf (2006). Articles>Web Design>Documentation>Technical Writing
#31780
Are We Giving Readers What They Want, in the Way They Want and Need It?
With all the talk about Web 2.0 and the attendant technologies, are readers actually being better served by documentation now than they were in the past?
DMN Communications (2008). Articles>Documentation>Technical Writing>User Centered Design
#31702
Avoid the SOX (Sarbanes-Oxley) Documentation Nightmare With These Five Tips
The Sarbanes-Oxley Act has been called the most comprehensive reform of corporate law since the Securities Exchange Act was passed in 1934. The effects of SOX are far reaching. Its provisions govern actions by management, audit committees, and boards of directors of public companies. Like it or not, Sarbanes-Oxley is here to stay. Its impact on IT departments is major and growing. The reaction of many IT groups is to document everything in sight in an attempt to cover themselves. In the end, this can be counter-productive, expensive and wasteful.
D'Amico, Vin. IT World Canada (2006). Articles>Documentation>Regulatory Writing
#31107
Baselining Documentation on a Wiki
The dynamic nature of wikis can cause a few headaches when you need to baseline documentation that's on a wiki to correspond with the release of your product. This blog post looks at some ways in which you can try baselining wiki content.
DMN Communications (2008). Articles>Documentation>Technical Writing>Wikis
#18749
Benefits of Using a Professional to Write User Documentation
Studies have shown organisations value the following benefits: overall organisation, the sales team, and documentation meets the customer's requirements.
Cherryleaf (2003). Articles>Writing>Professionalism>Documentation
#31148
Betriebsanleitungen für Anlagen 
Der Normenunterausschuss NATG-F des Deutschen Instituts für Normung e.V. ist derzeit damit befasst, Regeln zur Erstellung von Betriebsanleitungen für Anlagen zu erarbeiten.
Doculine (2002). (German) Articles>Documentation>Writing>Technical Writing
#13567
Brokedown Palace Part 2: Workflows for Fun and Profit
If you're going to toss out your user guides, you'd better have a good user interface and concise supporting materials. Workflows can help you both in the design of the user interface and in the creation of job aids for the people who use your product. A workflow is a compact and effective way to describe the flow of any procedure. How many times have you grumbled about the design of a piece of software or Web site that you've been trying to use? Chances are that no one ever sat down to model it using the workflow technique.
Knowles, Michael. Write Thinking (2002). Articles>Writing>Documentation
#13566
Brokedown Palace, Part 1: Why User Guides Don't Work 
Software user guides use up an awful lot of space with screen shots. But I know what the screen looks like -- it's right in front of me. Any decent GUI design is self-documenting to some extent, at least. No matter how much we complain about them, GUIs have gotten pretty good. Children have them figured out in minutes. And then they start asking questions like, 'How do I make my stick man move around?' Computers are toasters or drawing pads to them. That's another reason user guides don't work: the average user doesn't need one anymore.
Knowles, Michael. Write Thinking (2002). Articles>Writing>Documentation>Screen Captures
#14710
MacDonald analyzes the success of irreverent software manuals such as the 'For Dummies' and 'Complete Idiot's' series and suggests ways writers of traditional technical manuals can make their own work more enjoyable to read.
MacDonald, Matthew P. Intercom (2001). Articles>Documentation>Writing>Technical Writing
#20553
Converting to Information Mapping: A Case Study
Cisco Systems, Inc., uses electronic media as the primary delivery means for customer documentation and training. Information Mapping® techniques are being developed as a methodology for creating and linking modules of customer information. After selecting the Information Mapping methodology, we found it necessary to customize it for our needs. To implement Information Mapping methodology, we defined a system architecture consisting of three main subsystems: a document management subsystem, an authoring environment, and a publishing or delivery subsystem, In parallel with the customization and development of a system architecture, several writers began to implement the Information Mapping techniques to provide content to be put into the system being developed.
Garrett, Aviva, Haggai Mark and Jan Johnston-Tyler. STC Proceedings (1996). Articles>Documentation>Writing>Technical Writing
#27457
Creating Professional Documentation with Linux Tools
While Linux lacks standard Windows tools such as FrameMaker, RoboHelp, and WebWorks Publisher, it's still a viable environment for technical writers. Linux users can take advantage of a number of documentation tools, including both free or open source software (FOSS) and proprietary software. All of them give technical writers the ability to author and publish professional documentation.
Nesbitt, Scott. Linux.com (2006). Articles>Documentation>Technical Writing>Linux
#19743
Creating User-Friendly Documentation
We often hear that users do not read documents. To lure readers into reading our documents, we must make documents user-friendly.
Bhatia, Neeraj. Indus (2002). Articles>Documentation>User Centered Design>Technical Writing
#24090
A Critical Assessment of the Minimalist Approach to Documentation 
Carroll's (1991) minimal manual has been considered an important advance in teaching first-time users the basics of computer programs. Unfortunately, it is not very clear what minimalism really means. Practitioners, for example, will find it difficult to create their own minimal manual because the principles of minimalism have not been described in enough detail (see Horn, 1992; Tripp, 1990). It is also not yet settled that a minimalist approach is the most effective one because critical experiments have hardly been conducted. This study therefore closely examines the minimalist principles and claims. This paper describes the basic ideas of minimalism, its design principles and how they can be operationalized. A parallel is drawn between a minimalist and constructivist perspective on learning and instruction. Like minimalism, constructivism places a high value on experience-based learning in context-rich environments. Like minimalism, it stresses the need to capitalize on the learner's prior knowledge as much as possible. And like minimalism, constructivists urge learners to follow their own plans and goals, to make inferences, and to abstract principles from what they experience (see Duffy & Jonassen, 1991, 1992). An experiment is reported that examines the claims of minimalism. Strong and significant gains on several factors were found, all favoring the minimal manual over a control (conventional) manual. The discussion points to several issues that minimalism has yet to address.
van der Meij, Hans. ACM SIGDOC (1998). Articles>Documentation>Technical Writing>Minimalism
#23642
Designing and Writing to Reduce User Errors
A vast majority of documents (I consider print and online as documentation) often works to define the optimized error-free method of performing a task and provides a user with a straightforward solution. However, the user expects documentation to help solve problems and address errors. Thus, attention must be paid to potential problems users can have and how to correct them. Errors have different causes; the information designer should understand the potential types of errors since properly addressing each type requires a different approach in the design and documentation.
Albers, Michael J. STC Proceedings (2003). Articles>Documentation>Writing>Technical Writing
#27500
Developing a Web-Based Tutorial in RoboHelp
The very first thing you should do in developing a tutorial is to be familiar enough with the subject matter that you can write the content.
School for Champions (2005). Articles>Documentation>Writing>Technical Writing
#31799
Developing Knowledge Base Articles
A short article that offers some tips on writing articles for a knowledge base, whether internal or client facing.
DMN Communications (2008). Articles>Documentation>Writing>Technical Writing
#23221
Funny thing, documentation. Ought to be easy enough, surely? So why the disappointing results? What IS the elusive spark which distinguishes the professional author from others who put their hand to the pen (keyboard)?
Mobbs, John. ISTC (2002). Articles>Documentation>Writing>Technical Writing
#29771
Documentation Solutions for Complex Tools: Task-Based Design at the Cross Roads
For most of the technical writing community, task-based documentation has become the panacea for presentation of end-product document (in any of its myriad forms including traditional linear manuals and online help). We believe, however, that applying this method to a complex tool, (for example, a software tool without a Graphical User Interface), challenges the task-based approach.
Swallow, Lisa and Matt Laney. STC Proceedings (2004). Articles>Documentation>Writing>Technical Writing
#24890
Downsizing Documentation: Meeting the Challenge
The redesign of the Microsoft Windows operating system along with a shrinking page count and Help file-size allocation, presented Windows User Education with a unique opportunity. We not only redesigned our entire documentation model, we also changed and improved our authoring tools. And, along the way, we changed how we did our work.
Bloch, Peggy, Phyllis Levy, Kimberly A. Parris and Gayle Picken. STC Proceedings (1995). Articles>Documentation>Technical Writing>Minimalism
#24865
Never assume that describing something in basic, simple, fundamental terms will annoy your audience. Dumbing down is a form of distortion and possibly deception. Simplifying and clarifying are forms of altruistic communication. Find out more about the differences between "dumbing down" and simplifying and clarifying...and how to decide how simple an explanation should be.
Streight, Steven. Blogger.com (2004). Articles>Documentation>Writing>Business Communication
#30484
Early Involvement: Writing at Product Design Time
Lead writing is a process that moves the information development cycle into the product development cycle. Writers and programmers work together from the beginning to produce both code design and supporting information. This process ensures that information developers can actively participate in design, and programmers can contribute to supporting documentation. Both groups gain an appreciation for each other's perspective, expertise, and skills, producing a more customer-oriented product.
Coppola, Carolyn M. STC Proceedings (1993). Articles>Documentation>Writing>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
