<?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;Assessment</title>	<link>http://tc.eserver.org/dir/Articles/Documentation/Assessment</link>
	<description>A listing of the most recently indexed works about Articles and Documentation and Assessment 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;Assessment</title>
		<link>http://tc.eserver.org/dir/Articles/Documentation/Assessment</link>
	</image>
	<item>
		<title>Comprehensibility as an Economic Factor</title>
		<link>http://tc.eserver.org/35679.html</link>
		<guid>http://tc.eserver.org/35679.html</guid>
		<description>How can you guarantee a clearly understandable user manual? Is it even possible to measure the quality of technical documents or does comprehensibility merely depend on the reader? To answer these questions for the Porsche AG, content analysis provider semiotis³ developed a model to help measure the quality of documents.</description>
	</item>
	<item>
		<title>Why Is It That Teams Do A Poor Job of Post-Writing-Project Analysis?</title>
		<link>http://tc.eserver.org/35080.html</link>
		<guid>http://tc.eserver.org/35080.html</guid>
		<description>Project teams may recognize that reviews are not working well, though the may not understand why.  A valuable solution is to conduct ”lessons learned” analysis following the end of the project.  Too often, though, post-writing-project analysis receives little commitment or meaningful effort, but why? </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>Proving Worth: What Technical Communication Managers Must Do to Prove the Value of Their Deliverables</title>
		<link>http://tc.eserver.org/32192.html</link>
		<guid>http://tc.eserver.org/32192.html</guid>
		<description>If the documentation is not being used and used effectively, it will never help the bottom line. The trick to increasing value with internal and external users is to identify areas where documentation can save time and money, to create agreement that the documentation can save time and money, and to ensure that the documentation does save time and money.</description>
	</item>
	<item>
		<title>It&apos;s In the Numbers: Using Metrics to Plan Documentation Projects</title>
		<link>http://tc.eserver.org/32219.html</link>
		<guid>http://tc.eserver.org/32219.html</guid>
		<description>It&apos;s in the numbers. Creating documentation is not an exact science, yet as communication leaders, we are expected to provide real estimates for how much time we need to document a project, or what we can produce given a predetermined timeline.</description>
	</item>
	<item>
		<title>Testing Documentation</title>
		<link>http://tc.eserver.org/32089.html</link>
		<guid>http://tc.eserver.org/32089.html</guid>
		<description>As part of the product, testing documentation seems like an obvious thing to do, but what does it really mean? I’ve fielded the question in a few different places now and it’s always interesting to delve deeper and understand the rationale behind the request.</description>
	</item>
	<item>
		<title>Evaluating Online Help</title>
		<link>http://tc.eserver.org/31833.html</link>
		<guid>http://tc.eserver.org/31833.html</guid>
		<description>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.&#xD;&#xD;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.</description>
	</item>
	<item>
		<title>It&apos;s In the Numbers: Using Metrics to Plan Documentation Projects</title>
		<link>http://tc.eserver.org/31715.html</link>
		<guid>http://tc.eserver.org/31715.html</guid>
		<description>It&apos;s in the numbers. Creating documentation is not an exact science, yet as communication leaders, we are expected to provide real estimates for how much time we need to document a project, or what we can produce given a predetermined timeline.</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>Performing Publications Needs Assessments</title>
		<link>http://tc.eserver.org/30533.html</link>
		<guid>http://tc.eserver.org/30533.html</guid>
		<description>A publications needs assessment is a way to identify and analyze documentation and publishing needs for a project, group or company. The technical communicator can use these assessments to ensure that the proper documentation and publishing services are provided. This paper describes a four step approach to performing publications needs assessments.</description>
	</item>
	<item>
		<title>A Standardized Analysis Method for Customer Inquiries</title>
		<link>http://tc.eserver.org/30376.html</link>
		<guid>http://tc.eserver.org/30376.html</guid>
		<description>The Documentation Development Department (DDD) of Hitachi has been improving its software manuals by analyzing inquiries from its customers to the Hitachi Computers Customer Answer (HCA) center. In order to improve inquiry application procedure the DDD isolated and studied inquiries about Hitachi’s workstation, OA software products, from October, 1991 until March 1992.</description>
	</item>
	<item>
		<title>Calculating Documentation Cruft</title>
		<link>http://tc.eserver.org/29359.html</link>
		<guid>http://tc.eserver.org/29359.html</guid>
		<description>It&apos;s easy to describe documentation cruft, and often easy to identify it once you see it, but it&apos;s hard to estimate how &apos;crufty&apos; a document actually is. Furthermore, it&apos;s often hard to convince the creators of a document that &apos;their baby&apos; isn&apos;t as beatiful as they believe it to be.</description>
	</item>
	<item>
		<title>Comparative User-Focused Evaluation of User Guides: A Case Study</title>
		<link>http://tc.eserver.org/29166.html</link>
		<guid>http://tc.eserver.org/29166.html</guid>
		<description>A comparative evaluation of two user guides,--the document traditionally used by a company and a model document designed on the basis of research results and recommendations,--was carried out using a number of complementary approaches focusing on the user. The quality and suitability of these documents for the target audience were assessed in terms of content, structure, presence of certain organizational devices (such as headings) and pictures included. The results revealed that the model document was more attractive, more efficient, and better adapted to users&apos; needs, thanks to its modular organization (being structured according to &quot;functions&quot;), a large number of pictures, the presence of headings, and rationalization of the vocabulary used.</description>
	</item>
	<item>
		<title>Documentation Quality Metrics</title>
		<link>http://tc.eserver.org/28172.html</link>
		<guid>http://tc.eserver.org/28172.html</guid>
		<description>To implement any continuous improvement process, you have to measure your progress. This is where metrics come in. Have you been struggling to create a process for measuring your technical documentation? If so, this article provides the information you need to get started.</description>
	</item>
	<item>
		<title>Obtaining User Feedback: How Useful Are Your Online Help Systems?</title>
		<link>http://tc.eserver.org/27984.html</link>
		<guid>http://tc.eserver.org/27984.html</guid>
		<description>Surveys or questions posed to users may not be entirely useful when determining whether a user&apos;s experience with the help feature was successful or not. The author provides instructions on implementing a tool that will provide this kind of feedback.</description>
	</item>
	<item>
		<title>A Comparison of Two Evaluation Techniques for Technical Documentation</title>
		<link>http://tc.eserver.org/27544.html</link>
		<guid>http://tc.eserver.org/27544.html</guid>
		<description>This study compared two evaluation techniques, Usability Testing and Cognitive Walkthrough, in their ability to identify errors in aviation maintenance documentation. The techniques were evaluated to see how much unique information they each produced as well as the type of errors identified. Results showed that the techniques were complementary in their findings and both are recommended in the development of technical documentation. </description>
	</item>
	<item>
		<title>Evaluation Toolbox for Aviation Technical Publications</title>
		<link>http://tc.eserver.org/27545.html</link>
		<guid>http://tc.eserver.org/27545.html</guid>
		<description>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.</description>
	</item>
	<item>
		<title>Key Issues in Conducting and Writing Integrated Assessments</title>
		<link>http://tc.eserver.org/24906.html</link>
		<guid>http://tc.eserver.org/24906.html</guid>
		<description>Integrated assessments of environmental concerns consider the economic and social effects of a change as well as the environmental effects. Topics that should be addressed in such an assessment and the weight given 10 each are thorny problems for the assesment team and writer to deal with. The results of a workshop of experts in public policy, utility management, regulation, political science, government, technical communication and environmental science identified and characterized the key issues in shping and defining this new genre of environmental writing.</description>
	</item>
	<item>
		<title>Manual Evaluation Workshop</title>
		<link>http://tc.eserver.org/24902.html</link>
		<guid>http://tc.eserver.org/24902.html</guid>
		<description>Experts in document design will analyze your document for organization, page layout, writing style, and use of graphics. Each document analysis lasts approximately 30 minutes. You must have a ticket for this session and bring a document to be evaluated.</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>Evaluating and Choosing a Service Provider</title>
		<link>http://tc.eserver.org/23653.html</link>
		<guid>http://tc.eserver.org/23653.html</guid>
		<description>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&#xD;prices.&#xD;Evaluations must be carefully planned and implemented&#xD;in order to produce reliable results. The planning phase&#xD;lets the documentation managers “set the stage” for an&#xD;evaluation by defining and communicating the main&#xD;objectives. The subsequent implementation phase lets&#xD;participants gather the key information required to select&#xD;the best service provider.</description>
	</item>
	<item>
		<title>Readable Computer Documentation</title>
		<link>http://tc.eserver.org/22829.html</link>
		<guid>http://tc.eserver.org/22829.html</guid>
		<description>A retrospective look shows earlier advice still relevant to both predicting and producing readable writing. For prediction, refined readability formulas with stronger criterion passages and updated familiar -word lists have appeared, although the computerization of readability tests sometimes encourages misapplying or misinterpreting them when screening text. For production, attention to sentence construction, word characteristics, and information density remains relevant to both drafting and revising computer documentation for readability, especially since reading speed and reader preference often interact with comprehension in practical settings.</description>
	</item>
	<item>
		<title>Resources</title>
		<link>http://tc.eserver.org/21741.html</link>
		<guid>http://tc.eserver.org/21741.html</guid>
		<description>Requesting a quote for outsourced documentation services can be confusing and frustrating. Often it means that managers in IT, engineering or HR must negotiate with professionals whose skills they cannot effectively assess. This can easily lead to inappropriate expectations and disappointment.</description>
	</item>
	<item>
		<title>What is Good Documentation?</title>
		<link>http://tc.eserver.org/21386.html</link>
		<guid>http://tc.eserver.org/21386.html</guid>
		<description>This article lists some basic metrics for determining whether documentation is useful or not. Users&apos; needs and issues of accessibility are highlighted.</description>
	</item>
	<item>
		<title>Method to Evaluate Manuals and Online Help</title>
		<link>http://tc.eserver.org/20722.html</link>
		<guid>http://tc.eserver.org/20722.html</guid>
		<description>In these testing times when time to market for software is constantly diminishing, the demand to make manuals and online help targeted, faster, cheaper and better is a tall order. While methods and tools are being constantly&#xD;developed to help us do our work faster, and better,&#xD;measuring the quality of the written word remains a&#xD;deficient arena. Technical Communications gurus&#xD;advocate methods like surveys and usability to make&#xD;better end products. However, this requires good&#xD;infrastructure and management support to carry out.&#xD;This paper provides a method to evaluate technical&#xD;manuals and online help for software products. It&#xD;discusses how you can gauge a manual’s quality and&#xD;suggests a method to quantify its effectiveness. It is cheap&#xD;to implement and is customizable for your organization.&#xD;All you need is good knowledge of your audience, and&#xD;some faith and persistence!</description>
	</item>
	<item>
		<title>Documentation and Training Productivity Benchmarks</title>
		<link>http://tc.eserver.org/20574.html</link>
		<guid>http://tc.eserver.org/20574.html</guid>
		<description>Investigates how computer-industry companies create end-user documentation and training materials, and how they measure productivity. Describes results of interviews of eleven managers of publications or training departments.</description>
	</item>
	<item>
		<title>Maintaining Quality Control in Documentation</title>
		<link>http://tc.eserver.org/18912.html</link>
		<guid>http://tc.eserver.org/18912.html</guid>
		<description>If all of us were more focused towards quality in our lives, we would have it in abundance. We would have higher satisfaction levels and therefore, have lesser complaints. This paper presents cases and reasons why user manuals and guides are not up to the expected standards. Do we need to go beyond checklists before shipping a&#xD;document? Are reviews and checklists sufficient? This&#xD;paper briefly talks about the measures that we could take to ensure that a good document is delivered.</description>
	</item>
	<item>
		<title>Documentation Metrics: What Do You Really Want to Measure?</title>
		<link>http://tc.eserver.org/15117.html</link>
		<guid>http://tc.eserver.org/15117.html</guid>
		<description>Examines several metrics--systems for measuring production and production standards--to determine their value to technical communicators.  He argues that qualitative metrics are more meaningful than quantitative ones.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Documentation/Assessment.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>