Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.
#24451
Improving Publication Quality Through Project Management 
A methodology for developing high-quality software developed by the Software Engineering Institute at Carnegie-Mellon University can also be applied to developing technical publications. This workshop addresses several aspects of this methodology using various project management techniques. By bringing your development process under better control, these techniques will ensure a more uniform quality in your publications.
Firman, Anthony H. STC Proceedings (1995). Articles>Project Management>Documentation
#23320
Improving the Quality of User Manuals in Japan
We will share the results and analysis of a survey on customer needs for user documents as a means to raise the overall quality of such materials. Fuji Xerox will provide how to improve the quality of user documents with some examples of user manuals for copier and facsimile etc. Hitachi will report various methods to improve the quality in software-manual development process and provide some examples.
Nomizo, Fumitoshi, Teruaki Shioda and Akihiko Suzuki. STC Proceedings (1994). Articles>Documentation>Regional>Japan
#29394
Improving the Usability of Programming Publications
This paper summarizes the work of a study group on ways to improve the usability of publications that support programming products. Task orientation, an approach to providing, organizing, and packaging information, is covered, together with innovations to improve the usability of programming publications: ease-of-use education, measurement of user opinion, and incorporating usability into the publications development process.
Bethke, W.M., P.H. Dean, E. Ort Kaiser and F.H. Pessin. IBM Systems Journal (1981). Articles>Documentation>Writing>Technical Writing
#31178
Improving Your Technical Document Writing Skills
Discusses the general technical writing process.
Doddihal, Vinayak. EditSphere (2008). Articles>Documentation>Writing>Technical Writing
#20851
The reduced reading speed on computers can be compensated by good hypertext design that allows the user to read less information and to find it faster. A typical example is online help and documentation: because the information is right there on the computer, there is no need to spend time finding the hardcopy manual, and because of good search tools and hypertext links between related information, users can go directly to the one or two sections that contain the answer to their problem. After all, Nielsen's first law of computer documentation is that users don't read it. The second law is that if they read it anyway, it's because they are in deep trouble and need the answer to a specific problem. Thus, somebody reading a manual won't really read it cover-to-cover, so online presentation makes perfect sense.
Nielsen, Jakob. Alertbox (1996). Articles>Documentation>Online>Usability
#15143
Including Purpose in Software Documentation
Argues that technical writers should include a discussion of the purpose behind every procedure described in software documentation.
Block, Barbara M. Intercom (2001). Articles>Documentation>Writing
#30118
Incorporating Animation into Help Files
Information clarity, ease of use, and modern computing speeds are reasons to consider animation in Help files. Sharp's article presents three common types of animation and how to make them work for you.
Sharp, Roger A. Intercom (2007). Articles>Documentation>Video>Flash
#22169
Incorporating Usability Testing into the Documentation Process 
Describes how one company approaches usability testing of documentation and incorporates usability testing into its writing process through a Documentation Usability Team.
Postava-Davignon, Christi-Anne, Candice Kamachi, Cory Clarke, Gregory Kushmerek, Mary Beth Rettger, Pete Monchamp and Rich Ellis. Technical Communication Online (2004). Articles>Usability>Methods>Documentation
#29116
Increasing User Acceptance Of Technical Information in Cross-Cultural Communication
A significant problem in technical communication is persuading the user that the information is accurate, valid, and useful. All too often, technical communicators treat users as members of their own culture. When authors do consider cultural issues, they often focus on matters such as vocabulary, visuals, and organization. Other strategies, however, can be useful in gaining acceptance of technical information in cross-cultural situations. For example, the communication theory of compliance-gaining offers suggestions for how the technical communicators can adapt the text to enhance user acceptance when communicating to members of their own culture as well as when communicating across cultures. Communicators can use promises, threats, demonstrate positive and negative outcomes, extend friendliness, etc., to develop the text. In this article, I will explain several compliance-gaining strategies authors can use, identify rhetorical strategies they can combine with compliance-gaining strategies, show how these strategies can be effective in a cross-cultural environment by comparing the strategies in two sample cultures, and analyze a brief sample.
Warren, Thomas L. Journal of Technical Writing and Communication (2004). Articles>Documentation>User Centered Design>International
#30507
Indexing a software manual is not very different from indexing any other manual. As a simple rule, make sure you index all of the software features: screens, windows, fields, options and commands. Index system errors and warnings if applicable. Use cross-references to direct the reader to the term used in the manual if it differs from the generally-used jargon.
Tetreault, Edouard. STC Proceedings (1993). Articles>Documentation>Indexing
#19977
Indexing in the Documentation Process: Which Methods Do You Choose?
Giving your readers a quality index takes a careful consideration of the tools, time frame, workgroup process, and results you plan for the piece. Planning for the index must start at the beginning of the project, in order to have the essential processes clear to all involved As the documentation process itself becomes more complex, trying to meet different needs in different environments, so does indexing. As print-based documentation moves to online, the index or keywords becomes critical to your users. In this session, participants will learn what kinds of tools are available for indexing, the benefits of each, what the stages of indexing are, and the amount of time to allow for each.
Wright, Jan C. STC Proceedings (1996). Articles>Documentation>Indexing
#25870
In order to make a help system really helpful, you need to provide an effective index. But many online help writers face two dilemmas when it's time to index their help systems: How to prepare a useful index that meets the users' needs and how to code the keywords to make the index compile correctly. This article provides tips to help writers solve both problems.
Hamilton, Beth. STC Indexing SIG (1999). Articles>Documentation>Online>Help
#30509
Creating an index for a technical manual requires an understanding of what constitutes a high-quality index and the indexing methodology. This workshop presents the methodologies and steps necessary to create such an index.
Bonura, Larry S. STC Proceedings (1993). Articles>Documentation>Indexing
#22408
Since most manuals aren't meant to be read from cover-to-cover like a novel, a method of rapidly accessing a subject is required; in other words, an index. A good index is a vital component in any manual of more than 20 to 30 pages long. An otherwise excellent document can be made next to useless without an index: don't feel tempted to skimp on this valuable but admittedly tedious task. If you have the budget, consider sub-contracting professional indexers to create your index for you: both for your convenience and the excellence of the results.
GaryConroy.com (1992). Articles>Indexing>Documentation
#29988
Indicating Changed Text in Help Files
There are still many circumstances when drawing a user's attention to changed text is important. How do we do that with Help systems? By borrowing techniques from paper manuals, we don't have to reinvent the wheel. So here's a good approach that will work for Microsoft Word-based HATs.
Self, Tony. HyperWrite (2004). Articles>Documentation>Online>Help
#25163
Information Engineering: Taking Technical Communication to the Next Level
The technical communication community can no longer be satisfied to produce documentation that scores high in quality but low in effectiveness. We must use whatever means necessary to ensure our users reach their goals with as few obstacles and distractions as possible. This will require us to change the very nature of our work, from simply documenting complexity to designing collaborative systems. Our ultimate goal is not to write a better manual or online help system or web page, but to ensure that human beings and products can work together effectively to achieve common objectives.
Bowie, John S. STC Region 7 Proceedings (2003). Articles>Documentation>Usability
#23792
Information Gathering for Policies and Procedures
Information gathering can be one of the most timeconsuming and potentially frustrating experiences when writing policies and procedures. Policy and procedure writers sometimes start from scratch and must investigate and research policies and procedures before the first word is ever written. Although there are many obstacles to obtaining accurate and timely information, there are also many avenues the policy and procedure writer can take to gather, utilize, and maintain information.
Dodwell, Christine. STC Proceedings (1996). Articles>Interviewing>Documentation>Policies and Procedures
#26466
Information Layering: Providing Need-Based Information 
Information Layering is not new, but it has acquired a new dimension through modern technical and interactive possibilities. Even as of now, this technique can be used to make HTML-help considerably more user friendly.
Achtelig, Marc. indoition engineering (2005). Articles>Documentation>User Centered Design>Online
#13271
An Information Make-Over for Performance Centered Design
Technical communicators have long harbored a secret that we are reluctant to admit to outsiders: Users don’t like reading manuals. They do it only as a last resort. Even online help systems, which we originally hoped would be easier to use, have not met with great enthusiasm among users. It’s an all-too-common dilemma – there is a lot of information that could be explained, but users struggle along as best they can without it. Part of the problem has always been that users are reluctant to leave their work to seek information -- and rightly so. They have work to do and deadlines to meet. Even if your manual or online help contains a wealth of useful information, it takes them away from their work and interrupts their train of thought. If they do try to use it, the help window typically overlays the interface and adds its own set of navigation, resizing, and searching issues.
Battle, Lisa H. STC Proceedings (2000). Presentations>Documentation>Information Design
#30510
Information Metrics: Keeping Your Writing Projects On Track
Keeping information metrics for documentation projects gives managers the ability to more accurately estimate future projects. Publications departments can develop their own tools or they can use existing tools to track such things as page size, hours-per-page spent writing, illustrating, editing, and producing manuals; and the dependencies of each manual. This kind of information can help to determine development schedules, show how late changes affect the documentation process, and accurately determine what it will take to complete quality documentation on time and within budget.
Gordon, Judy L. STC Proceedings (1993). Articles>Documentation>Project Management>Methods
#19781
Information Planning for Successful Online Documentation
Creating an information plan should be the first phase of any publication development life cycle, whether hard copy or online. The plan is a tool for reporting the results of your research about your audience, their tasks, the market, and the product. The plan presents the basic organization and content of the publications you intend to build, effectively directing the documentation team to produce a publication with very specific goals in mind.
Stevens, Dawn M. STC Proceedings (1996). Articles>Information Design>Management>Documentation
#28230
Writing, compiling, and maintaining documentation is a necessary evil. While moving to DITA might not improve the quality of your documentation, it can streamline the process of creating and managing those documents.
Nesbitt, Scott. InformIT (2006). Articles>Documentation>XML>DITA
#19791
Our technical writers and course developers share several objectives. We must provide task oriented information to our customers, we create information for a variety of products, and we follow a similar information development cycle. We also spend a great deal of time re-creating the same information over and over. To make our efforts more efficient, and to creole better information for our customers, we’ve changed the way we think of information, how we initially create the information, and how we store and retrieve the information. This paper describes the methods we chose to accomplish these goals, the tools we use, and our successes, failures and frustrations.
Brockett, Susan H., James Cox, Lelanie S. Hellmer and Susan Katz. STC Proceedings (1995). Articles>Documentation>Education
#27247
Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how.
Wiegers, Karl E. StickyMinds (2004). Articles>Documentation>Engineering>Specifications
#13311
Instruction-Writing Exercises (for High School)
These guidelines and 14 scaffolded exercises respond to the unmet need for a psychologically solid, work-relevant way to learn technical writing by students who are NOT facile writers already.
Girill, T.R. STC East Bay (2001). Articles>Education>Instructional Design>Documentation
