Extreme documentation is an agile methodology for developing documentation in small to medium-sized teams in the face of vague or rapidly changing requirements.
#30781
While the jobs of Mary Clouse and the rest of the Security and Documentation Unit of the New York State Senate Technology Services department aren't as glamorous as those of the senators themselves, they ensure that the Senate can use its automated systems to conduct its daily business smoothly, efficiently, and securely.
Clouse, Mary. Intercom (2008). Articles>Documentation>Workflow
#27501
There are four tiers of documentation recommended for satisfying ISO 9000 requirements. These documents are: the Quality Policy Manual, Procedures, Work Instructions, and Records.
Kurtus, Ron. School for Champions (2005). Articles>Documentation>Workplace>ISO 9000
#31035
Documents That No Project Cannot Be Without
Short deadlines force project teams to quickly design, test, and release the product with little or no design documentation. If these documents are written, they generally are not well-written and are not comprehensive. The fact of the matter is that most project teams do not have enough staff to design the product, let alone write and manage documentation. This situation creates an ideal opportunity for technical writers to assist the project team in more ways than writing a user guide.
Dick, David J. Carolina Communique (2008). Articles>Documentation>Project Management>Collaboration
#27574
Does a Good User Interface Obviate the Need for Documentation?
This question was raised on a programmer's group recently and I was intrigued. The programmer's point was that with many web applications these days there is no print documentation distributed to end users, and even if it existed, many users won't read it although this makes me wonder who's buying all those how-to books I see in the bookstore. The programmer suggested that applications should be designed without documentation and wondered about the impact that would have on design.
Sprezzatura Systems (2002). Articles>Documentation>User Interface>Software
#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
#31988
A Dozen Techniques to Improve Your Software Online Help
There are several main reasons why putting your software manual on-line is necessary. It makes your web-site attractive for search engine crawlers and therefore brings you targeted traffic from Google, Yahoo!, MSN, and other search engines. A good online manual presents your product as serious and credible. Moreover, if a user faces difficulty using your software and asks for technical support, you may easily resolve the issue by referring that user to a certain page of your online help. Simply give the page's URL. With just one click the user will see screenshots and explanations which will help them to resolve the issue.
Crane, Dennis. Dr. Explain (2005). Articles>Documentation>Online>Help
#30268
A Dual Path Approach to Developing Documentation
The document development process is traditionally viewed as a series of steps along a single linear path. Instead, it is useful to view document development as consisting of activities along dual paths: one product-centered and one document-centered. Isolating a product-centered path reveals how much of your time is spent on activities other than writing--for example, learning about the product. It also highlights the ways in which the documentation is dependent on or shaped by the product.
Igel, Victoria E. STC Proceedings (1994). Articles>Documentation>Methods
#25807
Some people ask me about the frustrations and difficulties involved in the business of technical documentation. As a reply, I tell them this joke.
Documentia (2003). Humor>Documentation>Writing>Technical Writing
#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
#14591
The Duty of Candor in Future Software Documentation
The STC Code for Communicators requires us 'to communicate technical information truthfully...'. Such truthfulness has two related but distinct aspects, honesty and candor. I have never been asked to falsify technical claims in documentation (honesty), but I have occasionally been asked to withhold true claims about software that, if known to users, would surely affect how they interpret or apply that software (candor). The century ahead will increasingly demand user documentation that is candid as well as honest.
#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
#24241
Easy Tools for Documentation Management
The use of three simple tools can assist the documentation manager, from start to finish, on any new project. A revamped pubs plan, a new concept with engineering worksheets, and a matrix of modularized information are all utilized with a slightly new twist. The Pubs Plan is redefined to help you launch your project with a team approach, identifying issues, and proposing solutions. The Engineering Worksheets list all the critical pieces of information your writers/illustrators need for each component of the product. These pieces of information are then tracked by completion date on an Information Matrix. These documents work together as complimentary management tools that can be easily developed and scaled to the complexity of any project.
Shumate, Chona E. STC Proceedings (1999). Articles>Documentation>Project Management
#13961
Editing Computer Hardware Procedures for Multimedia Presentation 
Traditionally, technical editors have ensured consistency in the voice, grammar, and terminology of print documentation. As publications departments have moved to delivering online documentation, the role of the editor has varied and expanded. Editing multimedia documentation requires an even wider scope of skills than editing online documentation.
Jackson, Sue. ACM SIGDOC (2001). Presentations>Documentation>Editing>Multimedia
#30814
Editing Guidelines for Software Documentation
Software documentation can be difficult to review, so it helps to have some editing guidelines to keep you focused. Let's face it; software documentation isn't exactly exciting reading material. But you should be able to complete the job in a productive manner if you keep your coffee cup full and follow the editing guidelines below.
HelpScribe (2008). Articles>Documentation>Editing>Software
#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
#21411
Editing Your Own Documentation 
Technical writers sometimes fall into the trap of thinking that the user is stupid. I have often heard technical writers say things like 'well, if the user can't figure that out, maybe he’s in the wrong job!'
Docsymmetry (2003). Articles>Documentation>Editing>Technical Writing
#21523
Effects of Documentation Errors On User Perception of Interactive Programs: Background For a Study
Typographical errors and grammatical blunders affect the aesthetic appeal of documentation, and common belief is that they affect usability too. Many readers, however, seem not to notice such errors unless they are very frequent or flagrant. We thought it would be interesting, and perhaps useful, to test experimentally the effect of such errors on users’ perception of the information and on their performance with the product that the information supports the product.
Grice, Roger A. STC Proceedings (1994). Articles>Documentation>Interactive>Multimedia
#14522
Effects Of Documentation Errors On User Perception Of Interactive Programs: Conclusions And Results
Defining the quality of information has long been a controversial item. Many different theories and methodologies have been brought forward; almost all share at least one common basis— Typographical errors lower the perceived quality of information. In this experiment, the first of a planned, series, we examined the effects of typographical on the user’s perception of the quality of the product and documentation. The conclusions of this first study, and the implications we can make draw them, are presented in this paper.
See, Edward J.P. STC Proceedings (1994). Presentations>Documentation>Assessment
#14520
Effects Of Documentation Errors On User Perception Of Interactive Programs: Results
It would be useful to determine how much effect errors in product documentation have on users, if errors do not seriously interfere with product use. In an effort to start collecting information on this issue, we designed an experiment to explore the reactions of users to a simple interactive program with flawed documentation. We hypothesized that the product quality would be judged in part by the quality of the documentation, if the errors in the documentation interfered with task performance. We also hypothesized that some but not all users would be sensitive to documentation errors and would downgrade their rating of the program and the documentation based on these errors. The results of our experiment are presented in this paper.
Ridgway, Richard K. STC Proceedings (1994). Presentations>Documentation>Assessment
#23764
Effects of Documentation Errors on User Perception of Interactive Programs: The Experimental Design
It would be useful to determine how much effect errors in product documentation have on users, if the errors do not seriously interfere with product use. In an effort to start collecting information on this issue, we designed an experiment to explore the reactions of users to a simple interactive program with flawed documentation. We hypothesized that product quality would be judged in part by the quality of the documentation, if the errors in the documentation interfered with task performance. We also hypothesized that some but not all users would be sensitive to documentation errors and would downgrade their rating of the program and the documentation based on these errors. Our experimental design is described in this paper.
Ridgway, Lenore S. STC Proceedings (1994). Articles>Documentation>Usability
#27704
The Effects of Motivational Elements in User Instructions 
Should instructional texts be purely technical, with a focus on effectiveness and efficiency, or should they also focus on satisfying and motivating users? Good arguments have been made for paying attention to motivational aspects. But only analyses of existing instructions have been published so far, and guidelines for making user instructions motivational have not yet been studied carefully. This article presents motivational strategies and an experiment to test their effects. The results show that motivational elements have little effect on users’ effectiveness and efficiency in performing tasks, their product appreciation, and their self-efficacy, but they do increase users’ appreciation for the instructions.
Loorbach, N., Steehouder, M., Taal, E. Journal of Business and Technical Communication (2006). Articles>Documentation>Rhetoric>User Centered Design
#18257
The Effects of Online Systems on Documentation Management
Online tools can improve documentation management in several ways, depending on management goals of cost, schedule, or quality. Cost management tools need integration with automated status and quality assessment tools. Workflow simulation tools show great promise for avoiding bottlenecks in the document development process. Automated tools can enforce quality checkpoints and provide model document templates. The continual evolution of online documents will require new management approaches and goals.
Reilly, Annette D. STC Proceedings (1996). Presentations>Documentation>Online
#15086
Egoless Writing: Improving Quality by Replacing Artistic Impulse With Engineering Discipline
When technical communicators have a strong personal attachment to the publication they are preparing, this attachment may interfere with the design and testing of the publication itself. Documents developed by solo authors tend to be late, buggy, and exceedingly difficult for others to maintain. 'Ego-less' methods---collaborative and structured---break the proprietary connection between the writer and the book; in so doing they permit the most powerful tools of engineering and testing to be used. But they also reduce the satisfactions of the communicator's job.
Weiss, Edmond H. Journal of Computer Documentation (2002). Articles>Content Management>Documentation
#21494
A compilation of the most frequently asked questions about graphics in electronic catalogs. You will find answers to general as well as to technical questions.
ITEDO Software (2003). Design>Documentation>Graphic Design>Online
#26894
Electronic Common Technical Document
The specifications for creating the eCTD Backbone Files and Study Tagging Files (techncal documents that follow the eCTD Specifications).
U.S. Federal Drug Administration (2006). Resources>Documentation>Standards
