<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Documentation&gt;Quality</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/Quality</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and Quality in the field of technical communication.</description>
	<language>en-us</language>
	<copyright>Copyright (c) 2005-08 by the EServer. All rights reserved.</copyright>
	<managingEditor>tclib-editorial@eserver.org (TC Library Editorial Board)</managingEditor>
	<webMaster>webmaster@eserver.org (Geoffrey Sauer)</webMaster>
	<image>
		<url>http://tc.eserver.org/images/newlogo.gif</url>
		<title>Articles&gt;Documentation&gt;Quality</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/Quality</link>
	</image>
	<item>
		<title>The McCulley/Cuppan Standards Development Process We Use with Our Clients</title>
		<link>http://tc.eserver.org/34899.html</link>
		<guid>http://tc.eserver.org/34899.html</guid>
		<description>People use different terms to describe quality and if they actually use the same term, then it is highly unlikely that they will use the same definition for the term. So the first problem faced in the review process is the vocabulary used to describe quality attributes in a document.</description>
	</item>
	<item>
		<title>Improving the Practice of Document Review</title>
		<link>http://tc.eserver.org/34909.html</link>
		<guid>http://tc.eserver.org/34909.html</guid>
		<description>Document reviews should be used as a tool to build quality into research and technical reports. In most handbooks for professional writers, review is recommended for clear and simple reasons: it is intended to identify problems and suggest improvements that enable an organization to produce documents that accomplish its goals and meet readers’ needs. </description>
	</item>
	<item>
		<title>Markers That Help Measure Communication Quality</title>
		<link>http://tc.eserver.org/34806.html</link>
		<guid>http://tc.eserver.org/34806.html</guid>
		<description>In our consultancy, we have developed a set of terms that represent what we consider to be an effective set of descriptive markers. Markers that help to measure how well a document is communicating. We characterize our set of markers as “Document Standards” for all forms of technical and scientific writing.</description>
	</item>
	<item>
		<title>How Do You Measure Communication Quality?</title>
		<link>http://tc.eserver.org/34807.html</link>
		<guid>http://tc.eserver.org/34807.html</guid>
		<description>Most people involved with authoring and reviewing process do not have good markers to inform them of the overall communication quality of a document.  So without good markers they are left to utilize really poor markers to help them measure document quality.</description>
	</item>
	<item>
		<title>“Good Enough” Really Isn’t</title>
		<link>http://tc.eserver.org/34340.html</link>
		<guid>http://tc.eserver.org/34340.html</guid>
		<description>I’m enough of a perfectionist that I mentally wince every time I find myself thinking, “It’s good enough.” It sounds like a cop-out. It sounds like avoidance of responsibility and ownership. It sounds like I’m indifferent.</description>
	</item>
	<item>
		<title>Quality Measurement for Documentation: Different Tools for Different Needs</title>
		<link>http://tc.eserver.org/30558.html</link>
		<guid>http://tc.eserver.org/30558.html</guid>
		<description>The world of technical communication continues to search for a reliable information metric that is easy to apply and widely accepted. Although that goal eludes us for the moment, we can make a choice among competing metrics based on an understanding of their strengths and weaknesses, and appropriateness for different audiences. Two kinds of metrics, ordinal scale metrics and surface feature metrics, seem to meet many of our needs. The differences between them lie in their choice of measurements and the methods of applying the measurements.</description>
	</item>
	<item>
		<title>Enhancing Customer Satisfaction by Assuring Documentation Quality</title>
		<link>http://tc.eserver.org/30491.html</link>
		<guid>http://tc.eserver.org/30491.html</guid>
		<description>From the customer&apos;s perspective, an important and visible part of a product or service is its documentation. Bellcore&apos;s Technical Publications (Tech Pubs) organization uses a Quality Assurance (QA) program that focuses on enhancing customer satisfaction through delivering high-quality documentation. This program emphasizes a &apos;network&apos; approach to documentation development, whereby technical writers can most efficiently use the support network of QA reviewers and management available to them. The Tech Pubs QA program draws on the needs of clients and the expertise of technical writers to strive to achieve the highest level of quality possible in producing documentation.</description>
	</item>
	<item>
		<title>Improving Document Quality Through Customer Visits</title>
		<link>http://tc.eserver.org/30505.html</link>
		<guid>http://tc.eserver.org/30505.html</guid>
		<description>In an effort to improve the quality of our documentation, our Information Development department personally visited over 80 of our customers in 10 different locations across the United States. Our goal was to find out what we needed to do to create documentation that would satisfy our customers&apos; needs. We came up with a process for planning our visits, gathering the information from our customers, implementing their requirements, and increasing communication with them. From the visits, we not only made changes that immediately satisfied our customers, but we created an environment for them to work with us as a team.</description>
	</item>
	<item>
		<title>Minimalist Strategies for Improving User Documentation</title>
		<link>http://tc.eserver.org/30523.html</link>
		<guid>http://tc.eserver.org/30523.html</guid>
		<description>Those who use our products often ignore our best efforts at good documentation because they prefer to explore and learn by trial and error. Several researchers have developed document strategies that might help our users explore, learn, and recover from their errors. In order to use these strategies, however, technical communicators must get to know their users better, prototype their documentation, and test it on their users. Researchers need to tell us more about active learners and strategies for meeting their needs.</description>
	</item>
	<item>
		<title>Hidden Factors of Documentation Quality -- Part 1</title>
		<link>http://tc.eserver.org/30344.html</link>
		<guid>http://tc.eserver.org/30344.html</guid>
		<description>The first impulse of many documenters is to turn our work over to editors and graphic designers, or to form committees and develop style guidelines. All of these measures are useful, but none can assure us of quality when there are basic problems with the way we go about producing documentation.</description>
	</item>
	<item>
		<title>Checkliste zur Qualitätssicherung Technischer Dokumentation</title>
		<link>http://tc.eserver.org/28282.html</link>
		<guid>http://tc.eserver.org/28282.html</guid>
		<description>Einfache Checkliste zur Beurteilung und Verbesserung der Qualität Technischer Dokumentation, insbes. Technischer Dokumentation für Software (Software-Dokumentation) wie Handbücher, Online-Hilfen sowie interaktiver Demos und Tutorials.</description>
	</item>
	<item>
		<title>Documentation Quality Checklist</title>
		<link>http://tc.eserver.org/28281.html</link>
		<guid>http://tc.eserver.org/28281.html</guid>
		<description>Basic checklist for assessing and improving the quality of technical documentation, especially software documentation such as user manuals, online help files, interactive demos and tutorials.</description>
	</item>
	<item>
		<title>Robert Pirsig’s Message for Documentation Quality</title>
		<link>http://tc.eserver.org/24314.html</link>
		<guid>http://tc.eserver.org/24314.html</guid>
		<description>Teachers of technical communication frequently recommend that their students read Robert Pirsig&apos;s Zen and the Art of Motorcycle Maintenance (1974) for his views on the complex relationships between technology and human values. As a former technical writer, Pirsig also offers some useful advice about Quality and its relation to the usability of technical documentation. Revisiting Pirsig’s works, including the more recently published Lila (1991), reveals concepts about Quality in documentation that are especially relevant to the usability testing of the documentation for today’s rapidly evolving technologies. This paper examines Pirsig’s views on the some of the characteristics of effective technical communication, and it offers advice to educators and trainers for incorporating Pirsig’s concepts about Quality into their teaching of techniques for the usability testing, and hence quality, of user documentation.</description>
	</item>
	<item>
		<title>Methods for Documentation Testing in Technical Publications Quality Assurance</title>
		<link>http://tc.eserver.org/23736.html</link>
		<guid>http://tc.eserver.org/23736.html</guid>
		<description>Traditionally, verification of documentation procedure accuracy follows a standard model: technical communicators prepare a draft, which is submitted to subject matter experts  for review.  This process hinges on a number of factors that can adversely affect the quality of the review. Higher quality reviews are conducted by staff tasked specifically to test and review the draft procedures, and supply specific feedback by means of an established procedure. A well-established method of documentation testing provides several benefits to an organization. These include customer satisfaction, reduced costs, improved overall product quality, and improved document draft correction.</description>
	</item>
	<item>
		<title>Documentation Quality Metrics Within Total Quality Management Systems</title>
		<link>http://tc.eserver.org/23587.html</link>
		<guid>http://tc.eserver.org/23587.html</guid>
		<description>Total Quality Management (TQM), is now very much a feature of many organizations. One of the kernels of TQM is the process, with its related topics such as process design, process management and process improvement. One of the key requirements for process design and management is process measurements, often called &apos;metrics&apos;. Within the document design and development process, process metrics, including quality metrics, must be based very strongly on customer values for documentation. Quality metrics can form one element within a composite customer satisfaction index for documentation projects.</description>
	</item>
	<item>
		<title>Building Quality to Your Documentation</title>
		<link>http://tc.eserver.org/20286.html</link>
		<guid>http://tc.eserver.org/20286.html</guid>
		<description>The only way to ensure quality is to build the quality awareness into every aspect of your life and work. This&#xD;paper tries to combine the two methods of ensuring&#xD;quality: with the right process and with the right&#xD;measurement.</description>
	</item>
	<item>
		<title>Analysis and Resolution of Problems Occurring During the Production of Manuals</title>
		<link>http://tc.eserver.org/19875.html</link>
		<guid>http://tc.eserver.org/19875.html</guid>
		<description>We produce numerous manuals pertaining to telecommunications and, although we routinely devote much energy to reducing the number of problems occurring during the production process, this time we took up the challenge of eliminating the occurrence of problems altogether.&#xD;Here, we overview the characterisitics of problems&#xD;occurring at the company, profile their occurrence by&#xD;process, and review a few corrective measures.</description>
	</item>
	<item>
		<title>Cheating the Quality Triangle</title>
		<link>http://tc.eserver.org/14695.html</link>
		<guid>http://tc.eserver.org/14695.html</guid>
		<description>Hart discusses ways that technical communicators can simultaneously improve the quality of their documentation, increase the speed with which it is produced, and lessen the costs of producing it.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/Quality.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>