#24904
Environmental Impact Statements in The Netherlands 
Composing an Environmental Impact Statement is a complex task, not only in the USA but also in The Netherlands. Responsible for this difficulty are the comprehensive technical nature of the EIS, the diversity of the audience, and the political character of the outcome: the final text is a compromise between all those involved in the environmental debate. These factors may easily lead to voluminous statements. Communication specialists can help in this process: by writing the obliged summary, by editing the final copy, and (for those with management skills) by coordinating the environmental debate.
Bulter, Willem J. STC Proceedings (1995). Articles>Documentation>Environmental>Netherlands
#31992
Error Accessing and Displaying CHM Files: Reasons and Solutions
So, you've got in trouble. Some or even all of your CHM files seem to have gotten corrupted. They show a "The page cannot be displayed" error in the left-hand pane of the CHM viewer. There are several possible reasons why your CHM e-books and documentation files are unreadable.
Crane, Dennis. Dr. Explain (2006). Articles>Documentation>Help>Microsoft Windows
#21351
Estimating Scope and Schedule for a Help Project
During this session, we will learn how to create a topic list to determine project scope, and then we will begin to calculate how long it will take produce all of these topics. When we’re done, you will have a methodology for doing this for your own project.
Deaton, Mary M. STC Proceedings (1997). Articles>Project Management>Documentation>Help
#19785
Estimating Scope and Schedule for Help Projects
Three steps to a more accurate Help schedule.
Deaton, Mary M. STC Proceedings (1996). Articles>Project Management>Documentation
#19128
Estimating the Cost of High-Quality Documentation 
The cost of developing a typical end user document at Cadence Design Systems is about $40,000. The cost of not providing complete and completely accurate documentation can be in the hundreds of thousands of dollars.
Cover, Martha, David Cooke and Matt Hunt. Technical Communication Online (1995). Articles>Documentation>Pricing
#23652
Estimating Time and Cost for Policies and Procedures Projects
Estimating time and cost for a policies and procedures project can be an adventure in guessing and a ticket to grief. However, planning with a detailed checklist and list of assumptions can you help create a more realistic estimate, please your client, and protect your sanity and pocketbook.
Escoe, Adrienne. STC Proceedings (2003). Articles>Documentation>Project Management
#23653
Evaluating and Choosing a Service Provider
Small- to middle-sized companies are often dependent on third-party service providers to complete tasks related to documentation production. Formally evaluating service providers is one way for documentation managers to ensure that their company and documentation team are getting maximum service, top quality, and competitive prices. Evaluations must be carefully planned and implemented in order to produce reliable results. The planning phase lets the documentation managers “set the stage” for an evaluation by defining and communicating the main objectives. The subsequent implementation phase lets participants gather the key information required to select the best service provider.
Weirich, Margaret. STC Proceedings (2003). Articles>Documentation>Outsourcing>Assessment
#31833
Online help excels in providing quick access to concise information - but only when the users choose to access it. Delivering high-quality online help that satisfies all users is a hard task. Several good help authoring tools make help generation and maintenance easier, but to create good content that is highly effective is still a huge challenge. Experience shows that even after following quality guidelines or best practices, the final output may still not be good enough to satisfy the needs of your users. Heuristic evaluation of an online help system provides an initial assessment of both quality and usability. This article presents a summary of key points for evaluating online help, though you will likely want to expand the heuristics with company or product-centric metrics suitable to your application.
Dalvi, Meghashri. Usability Interface (2008). Articles>Documentation>Help>Assessment
#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
#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
#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
#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
