Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.
#29126
Evaluating the Effect of Iconic Linkage on the Usability of Software User Guides 
This study investigates whether Iconic Linkage--the use of the identical wording to present the same information recurring in a text--can improve the usability of user guides. Iconic Linkage is a writing strategy that potentially allows users to work more quickly and effectively and which promotes better retention of information. The usefulness of Iconic Linkage was tested in a laboratory-based usability study that combined: 1) objective task-based evaluation; and 2) users' subjective evaluations of a software program used in recording parliamentary debates. A post-test survey designed to test subjects' retention of information contained in the user guides was also administered. The study shows that Iconic Linkage significantly improved usability of the user guide: in all tasks, subjects worked more effectively and made fewer mistakes; while in the three timed tasks, subjects completed the tasks much more quickly. Subjects also gave higher ratings for the software and their retention of information was noticeably improved.
Byrne, Jody. Journal of Technical Writing and Communication (2005). Articles>Documentation>Software>Usability
#27545
Evaluation Toolbox for Aviation Technical Publications
This article describes the Evaluation Toolbox (Chaparro et al., 2004) - an aid to understand the process of evaluating the usability of aviation maintenance documentation -- from the initial development stage through the final pre-publication stage. This toolbox provides techniques to help technical writers better understand their users and to evaluate their documentation more effectively and efficiently.
Rogers, Bonnie Lida, Chris Hamblin and Alex Chaparro. Usability News (2005). Articles>Documentation>Assessment>Usability
#24798
The Evolution of a Help System 
An industry-wide design standard for help systems does not exist. To develop a flexible and usable help system for our workstation-based product, we have evolved and changed our help system design. Over a five-year period our help system was influenced by several factors:
Caldanaro, Regina M. and Michelle Corbin Nichols. STC Proceedings (1995). Articles>Documentation>Online>Help
#13284
Evolution to Performance Support: From Help to EPSS to PCD
TimeCorp, a leading publisher of commercial labor management software, has been working to incorporate increased levels of user support within its software interface. In this case study we will present samples of the TimeCorp product support as it evolved over time, from the initial online help to the electronic performance support (EPSS) prototype to the performance-centered design (PCD) solution. The types of information provided in the support also evolved to match the mode of presentation. The documentation team led this evolution within the organization and their roles have changed as a result.
Battle, Lisa H. and Metta Johnson. STC Proceedings (2000). Presentations>Documentation
#23551
Evolving Concepts: Expanding Project Resources
It is generally true that as large technical training and documentation projects evolve they place new and greater demands on existing resources. Although the intensity of the demand varies, it can usually be attributed to changes in the software application, to the addition of new learner groups, to the compression of existing schedules, and to the need for new training and documentation solutions. As projects become more demanding, resource allocation challenges become more sophisticated. Managers who bring big projects in within budget and on time, do so became they are able to allocate resources in creative, efficient, and effective ways.
Johanningsmeier, Kathleen A. STC Proceedings (1994). Articles>Documentation>Planning
#24629
Writers in our Vancouver office use several procedures to simplify the writing process, improve the final product, and avoid unnecessary work. These procedures include: an online library thatcontainsthe tools, instructions, and documentation we can share; a style guide that gives rules for usage, spelling, formatting, and punctuation; macros, style sheets, and boilerplate text to speed repetitive tasks and improve consistency; and detailedchecklists of the steps in ourmajortasks.
Eastman, Michael, Rhonda Arnason, Stephen Burtch, Arthur Jennings, Heather M. Sommerville and Elaine Young. STC Proceedings (1996). Articles>Documentation>Word Processing
#19506
Example Elaboration as a Neglected Instructional Strategy
Summarizes psychological research on why some people learn better from examples than others do, and applies the results to improve software documentation and literacy outreach projects.
Girill, T.R. STC East Bay (2001). Articles>Documentation>Design
#31870
One of my earlier careers was in manufacturing management, and it grounded me in the principles of project planning and management. When I moved into technical communication, I brought my project management disciplines with me, and I embraced the prevailing tools of my new profession. I dutifully produced documentation plans in Microsoft Word and supported them with detailed project plans in Microsoft Project. However, the problem is that—like bad relationships—these artifacts never gave back results that were sufficient to reward the effort I put into creating them.
Hughes, Michael A. UXmatters (2008). Articles>Documentation>Technical Writing>Microsoft Excel
#23435
A discussion about INTECOM's project for researching and establishing English-language documentation guidelines.
Fuchs, Amo and Ronald S. Blicq. TC-FORUM (2000). Articles>Documentation>Style Guides
#29375
Exploring Information Design and Development
Known to write a script or two to automate repetitive tasks like help builds, she also likes to write posts about XML-based information models like Darwin Information Typing Architecture (DITA). She often experiments with online help technology, enjoys writing blog entries, and wants to find new ways to use communication to help people understand technical solutions to complex problems.
Gentle, Anne. BMC Software (2007). Resources>Information Design>Documentation>Blogs
#29081
This article describes the influence that Extensible Markup Language (XML) will have on the software documentation process and subsequently on the curricula of advanced undergraduate and master's programs in technical communication. XML, an evolving set of standards for storing and displaying information, uses nine components that make up the XML development process. Grouped into content, formatting, and language specifications, these components enhance organizations' ability to manage information more efficiently and accurately. As the XML development process is adopted, the software documentation process will evolve from a self-contained procedure into a more flexible, interactive process in which software documenters must work closely with a wide range of specialists. The changes that XML will have on the software documentation process will likewise have implications for programs in technical communication in the need to address new kinds of job descriptions, skill sets, and career paths of future technical communicators. The article recommends adaptations to existing courses, as well as new elective and required courses.
Battalio, John T. Journal of Technical Writing and Communication (2002). Articles>Documentation>Education>XML
#19666
A revolution is under way in software development, revolving around agile methodologies that allow more room for design changes based on input from customers during development. One popular agile methodology is eXtreme Programming (XP).
Nuckols, Carl E. Intercom (2003). Articles>Documentation>Agile>Extreme Documentation
#27572
eXtreme Documentation and Design
What quicker way can there be to find out if something is teachable than to write up task-oriented documentation? And as things are built or changed, the documentation is updated. I often update the documentation before the code!
Ferlazzo, Ellen Lawson. Sprezzatura Systems (2002). Articles>Documentation>Agile>Extreme Documentation
#27586
Extreme Programming (or XP) is a popular software development process that encourages a return to the days of little or no documentation, Design After First Testing, and Constant Refactoring After Programming. Despite its popularity, not everyone thinks XP is a good idea.
Software Reality (2005). Articles>Collaboration>Agile>Extreme Documentation
#23403
Despite the fantastic development of computers and software, the paperless society seems to be far from implementation. On the contrary, the consumption of paper for documents has increased over the recent years.
Rullgård, Åke. TC-FORUM (2000). Articles>Documentation>Usability
#22847
Faster Factfinding With Digital Libraries?
This paper covers the usability testing of a prototype digital library. The library holds technical manuals for scientific instruments. Findings show test subjects can locate desired documents faster with this digital library than a corresponding paper library. However, the same subjects can locate desired information faster in a paper document than a digital one. Finally, most subjects reported they would prefer to using the online library of technical documents over the library of paper ones.
Barnett, Mark R. STC Proceedings (1997). Articles>Usability>Documentation>Online
#21473
Fault Tolerance: A More Forgiving Doc-To-Help and Word for Windows
Doc-To-Help 2000 has a new 'fault tolerance' feature that forgives novice authors their Microsoft Word mistakes, including direct formatting and stretched bookmarks. These problems often cause corrupted cross-references as well as document-to-Help-system conversion problems. Doc-To-Help's automatic diagnostic and repair utilities now find these common errors and correct them automatically.
Wade, Jenny. ComponentOne (1999). Articles>Documentation>Online>Help
#14892
Fèdèration des Enseignants Documentalistes de l'Education Nationale
FADBEN est une association de spÈcialistes des enseignants documentalistes (loi 1901) des lycÈes et collËges.
#31112
A Few Thoughts on FOSS Help Authoring Tools
There's a lot of great free and Open Source (FOSS) software out there. But one area in which it's lacking is professional-level help authoring tools. In 2005, Linux.com published an article titled "FOSS help authoring tools falter". And not much seems to have changed in the intervening years.
DMN Communications (2008). Articles>Documentation>Help>Open Source
#24422
Figuring Out What Your Customers Really Need
Effective technical manuals and training meet the needs of the customer. No one will argue with that statement. But the trick is to identify the needs of the customer. This paper describes one method to focus product information development on the customer: the needs analysis survey. This methodology that is common in course development and training identifies the tasks customers perform. It also allows course developers and technical communicators to collaborate on an area that they both understand.
Brockett, Susan H. and Susan Katz. STC Proceedings (1996). Articles>Documentation>User Centered Design
#14375
Finding the Best Mix of Paper and Online Documentation: A Case Study
The concept of the “paperless oflce” has become popular with executives who want to reduce costs and users who, often with good reason, refuse to open a manual. Technical communicators, who often understand the practical flaws behind this concept, must be prepared to make smart decisions about what information to present in manuals and what to present online. They must also justljj to management their decisions either to resist moving everything online or tofkd creative ways to do so without forgetting about the needs of the user.
Jones, Chip. STC Proceedings (1997). Presentations>Documentation>Online
#20328
First Contact: Talking to Your Documentation Users
You've never met them before. To you, they may represent the unknown and the strange. They view things differently, and their ways may seem almost alien. Yet you are supposed to serve their needs. They are your customers. Isn't it time you made first contact? In this paper, we share lessons learned and invite you to being your own voyage of discovery.
Macdonald, Kyla and Judith Rachel. STC Proceedings (1998). Articles>Documentation>User Centered Design
#31727
Customer support costs account for as much as 60 percent of a high-tech company’s total costs. Documentation is the first line of support for most customers, and customers usually use documentation to find the answer to a problem they’re having. The inevitable result of poor or nonexistent documentation is that more people try calling the customer support lines for help.
Butow, Eric. Software Development Times (2006). Articles>Documentation>Software>Technical Writing
#31708
Five Questions to Ask Yourself While Creating a New Documentation Department
Being asked to take the reins of a brand new documentation department is a challenge that many professional technical writers relish, even though the training and development activities they participated in may never have prepared them for such a rewarding challenge. This article looks at forming a new documentation department and determining what's needed, when it's needed and what resources are available to help the new department carry out its mission.
Butow, Eric. Writing Assistance (2006). Careers>Management>Documentation>Technical Writing
#14256
For decades, journalists have used a proven approach called the 'Five W's' to answer the questions that the readers of newspaper articles most commonly want writers to answer. The questions are sufficiently useful that they can easily be applied outside newspaper writing, and I've already written about this in the context of audience analysis (Hart 1996). In this article, I'll show you how you can use these questions to develop more useful online help. Each of the five W's is a simple question that starts with the letter W: Why, Who, What, Where, and When. Some authorities add a sixth question, 'How,' to this list, but 'how to' information generally fits under what, where, or when, depending on the nature of the information. Users of online help can benefit greatly from the proven journalistic approach if we can answer these same five questions for each help topic that we create. In the remainder of this article, I'll provide an example of a failure to ask these questions, show how asking these five questions could have prevented this failure, and provide examples of typical questions we should be asking. Please note that, although I've presented these five questions in an order that seems logical to me, in practice the approach becomes iterative: It doesn't much matter where you begin, since answering one question often reveals important aspects of the other questions that you'd not yet considered.
Hart, Geoffrey J.S. TECHWR-L (2002). Articles>Documentation>Help
