Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.
#27603
Beyond Story Cards: Agile Requirements Collaboration
Discusses the life cycle of Story Cards, what they should be, how to use them and what to watch out for.
Shore, James. JamesShore.com (2006). Articles>Documentation>Agile>Card Sorting
#21575
A company decides to release its software and documentation simultaneously in markets with different languages. For the documentation team, the traditional model of 'write and translate' does not work any longer. A bilingual writing team collaborates to produce a handbook in two languages at the same time.
Duffy, Gerald J. STC Proceedings (1994). Articles>Documentation>Localization>Collaboration
#30778
Technical communicators must adapt to the changing dynamics presented by the addition of rich media in the technical documentation space. Discover some suggestions for how to do so.
Ortega, Dan. Intercom (2008). Articles>Documentation>Multimedia>Flash
#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
#21505
Browse Sequence in Online Help 
A browse sequence enables users to navigate through a series of help topics in the sequence established by the help author. Although often omitted from help systems, the browse sequence is useful and will become essential as print documentation diminishes. Effective design options for a browse sequence include multiple segments, rings, branching, and the use of a browse button to take the user to the first topic in the current segment of the browse sequence.
Farkas, David K. and Bruce R. Gibbs. STC Proceedings (1994). Articles>Documentation>Online>Help
#30230
Build-to-Order Documents with DITA
It is entirely possible to deliver custom, on-demand documentation that is precisely suited to a user's needs. It can be done today, using web-interface strategies and the right document format. This post shows how such a system could be implemented with the DITA format, and shows why it would be an ideal document-delivery system for programmers.
Armstrong, Eric. Sun Microsystems (2007). Articles>Documentation>XML>DITA
#10316
Surveys and focus groups show that most software buyers use ReadMe files. Users primarily look to ReadMe files for information on software bugs. They identify the following ways that software manufacturers can improve their ReadMe files: 1) keep them short, 2) include a table of contents, 3) use hypertext, and 4) eliminate the need for ReadMe files. Along with these four improvements, this article discusses other ways to create quality ReadMe files that meet concrete user needs.
Johnson, Mark A. Technical Communication Online (1997). Design>Documentation
#27925
Building a Case for Global E-learning
As globalization of business continues at a rapid pace, employees are increasingly being asked to absorb and learn from materials that are not written in their first language. These materials range from key corporate policies and procedures that all employees must follow to specific training on products, health, safety or compliance. Very often this is training content created in English at the American parent company and distributed to regional and global offices, where in many cases employees are expected to have a “working knowledgeâ€Ω of English as a second or third language. But there are serious problems with this approach that stem directly from poor reading comprehension and also from learners’ misperceptions of the level of language facility they have actually achieved.
McBrien, Kieran. tekom (2005). Articles>Documentation>Localization
#19382
Building a More Effective Documentation Group
Suggests ten ways that managers of technical communicators can make their departments more efficient, effective, and valuable to their companies.
Smith, Susan E. Intercom (2003). Careers>Management>Documentation
#14388
Building a SGML-based Documentation Environment
SGML (Standard Generalized Markup Language) became an ISO-approved standard and was adopted as a Japanese Industrial Standards. Recently, SGML has begun to be used more widely in Japan. We, the Corporate Design Center of Ricoh Company, Ltd., have completed development of the a single SGML module DTD (Document Type Definition), customization of a SGML editor, and the implementation of review system using the world wide web. In addition, we have developed an automatic DTP system based on SGML.
Mimura, Kaori. STC Proceedings (1998). Presentations>Documentation>SGML
#19817
Building a Successful Translation Process
As a company expands into global markets, the need for localized documentation arises. Much like building or enlarging a house, a successful translation project requires a carefully planned process. When a company decides to produce localized documentation, it needs to establish a translation process. Although the process details may vary from company to company, there are basic steps that apply almost universally.
Lavallee, Nancy C. STC Proceedings (2000). Articles>Documentation>Localization
#26225
Building Documentation into the Interface
As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done?
Quesenbery, Whitney. STC Orange County (1998). Presentations>Documentation>Usability
#20285
Building Documentation into the Interface
As documentation is more and more built directly into the interface, and as technical communicators move into interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information will be conveyed at any moment. We can build on basic principles of cognitive psychology to help us make these decisions. We start from a question: Why should users be aware of the difference between interface and documentation when all they want is to get something done?
Quesenbery, Whitney. STC Proceedings (1998). Articles>Documentation>User Interface>Help
#22849
Building Documentation Into the Interface: A Cognitive Theory
As documentation is more and more built directly into the interface, and as technical communicators move into areas of interface design and usability, it is important to have a theoretical framework within which to make decisions about what kind of information should be conveyed at any moment.
Quesenbery, Whitney. STC Proceedings (1997). Articles>Documentation>User Interface>Cognitive Psychology
#20286
Building Quality to Your Documentation
The only way to ensure quality is to build the quality awareness into every aspect of your life and work. This paper tries to combine the two methods of ensuring quality: with the right process and with the right measurement.
Vatovec, Bogo. STC Proceedings (1998). Articles>Documentation>Quality
#26226
Building the Treasure House: Creating Knowledge Bases for the World Wide Web
What is a knowledge base? What are the components necessary to build one?
Massa, Jack A. STC Orange County (1998). Presentations>Documentation>Information Design>Databases
#20287
Building the Treasure House: Creating Knowledge Bases on the World-Wide Web
Web knowledge bases offer an excellent platform for delivering technical documentation and customer support information. They also represent an area of great opportunity for technical communicators to expand their skills, satisfy their customers, and create value for their employers or clients. This session explores the components of a web knowledge base and the tasks involved in planning and building one.
Massa, Jack A. STC Proceedings (1998). Articles>Documentation>Online>Web Design
#24972
"By the Way, We Also Want Online Help"
This presentation describes a strategy to meet a last-minute enterprise demand for online help for a software application program. We established design standards for writing online help, developed a process for gaining consensus from the project team on the content of the online help, and wrote the online help. We accomplished this in less than four months-a task that originally seemed impossible.
Davis, Herbert S. and Meryl Natchez. STC Proceedings (1994). Articles>Documentation>Online>Help
#29359
Calculating Documentation Cruft
It's easy to describe documentation cruft, and often easy to identify it once you see it, but it's hard to estimate how 'crufty' a document actually is. Furthermore, it's often hard to convince the creators of a document that 'their baby' isn't as beatiful as they believe it to be.
Ambler, Scott W. Dr. Dobb's (2007). Articles>Documentation>Assessment>Minimalism
#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
#31114
Can Lightweight Markup Languages Be Used for Documentation?
A lightweight markup language uses syntax that is similar to wiki syntax -- keyboard characters are used to define formatting. This blog post argues that if your documentation needs are simple, and you have a low or non-existent budget, then a lightweight markup language might be worth investigating.
DMN Communications (2008). Articles>Documentation>Programming>Wikis
#26991
Information about how to use the Canon Elura 50 camcorders for technical communication multimedia.
Arnold, Jenni and Christina Kitson. Studio for New Media (2004). Presentations>Multimedia>Documentation>Video
#26364
Captions and Audio Descriptions for PC Multimedia
This article discusses the various types of captions, when to use captions, as well as the various types of audio descriptions.
Microsoft (2002). Articles>Multimedia>Documentation
#23564
Capturing the Usability Chimera: Practical Applications of Usability Testing
How do I effectively include usability as a part of developing online and printed documentation?
Holmes, Fredrick and Melissa Wallentine. STC Proceedings (1994). Articles>Usability>Testing>Documentation
