<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Articles&gt;Usability&gt;Technical Writing</title>	<link>http://tc.eserver.org/dir/Articles/Usability/Technical-Writing</link>
	<description>A listing of the most recently indexed works about Articles and Usability and Technical Writing in the field of technical communication (and technical writing).</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;Usability&gt;Technical Writing</title>
		<link>http://tc.eserver.org/dir/Articles/Usability/Technical-Writing</link>
	</image>
	<item>
		<title>Change Your Writing Style to Make Documentation More Usable and User-Friendly</title>
		<link>http://tc.eserver.org/35285.html</link>
		<guid>http://tc.eserver.org/35285.html</guid>
		<description>When the subjects of usability and user friendliness in relation to documentation are broached, writing isn’t often the first thing that comes to mind. But it should be.</description>
	</item>
	<item>
		<title>Finding Information in Documentation</title>
		<link>http://tc.eserver.org/34586.html</link>
		<guid>http://tc.eserver.org/34586.html</guid>
		<description>Finding information in documentation is easy. Or is it? This blog post argues that there&apos;s no universal solution, and that each document and each delivery method offers challenges and requires a slightly different solution.&#xD;</description>
	</item>
	<item>
		<title>The User is King</title>
		<link>http://tc.eserver.org/33422.html</link>
		<guid>http://tc.eserver.org/33422.html</guid>
		<description>An average internet-banking user of this bank would be an Indian whose primary language, either at school or at home, was not and is not English. Such a person would not even notice the errors I’ve marked. Such a person would find the text totally comprehensible, unambiguous, and useful - though a tad incomplete because it answers only about four questions and doesn’t even address the how-to of the options provided by the internet-banking facility.</description>
	</item>
	<item>
		<title>Don&apos;t Let Your Product&apos;s Features Become Expensive Flaws</title>
		<link>http://tc.eserver.org/32823.html</link>
		<guid>http://tc.eserver.org/32823.html</guid>
		<description>Your product&apos;s unexplained features can turn into costly flaws.  This article describes three real-world products with just such &quot;features.&quot;  It presents ways you can prevent these feature-to-flaw conversions by improving the User Documentation for your products.</description>
	</item>
	<item>
		<title>Transitioning from Technical Writing into Usability</title>
		<link>http://tc.eserver.org/31090.html</link>
		<guid>http://tc.eserver.org/31090.html</guid>
		<description>In this podcast, I talk with Theresa Putkey, a usability consultant in Vancouver, about how she transitioned from technical writing into usability.</description>
	</item>
	<item>
		<title>A Structured Process for Transforming Usability Data into Usability Information</title>
		<link>http://tc.eserver.org/30434.html</link>
		<guid>http://tc.eserver.org/30434.html</guid>
		<description>Much research has been devoted to developing usability evaluation methods that are used in evaluating interaction designs. More recently, however, research has shifted away from evaluation methods and comparisons of evaluation methods to issues of how to use the raw usability data generated by these methods. Associated with this focus is the assumption that the transformation of the raw usability data into usability information is relatively straightforward. We would argue that this assumption is incorrect, especially for novice usability practitioners. In this article, we present a structured process for transforming raw usability data into usability information that is based on a new way of thinking about usability problem data. The results of a study of this structured process indicate that it helps improve the effectiveness of novice usability practitioners.</description>
	</item>
	<item>
		<title>Technical Communicators as Potential Usability Reviewers</title>
		<link>http://tc.eserver.org/29457.html</link>
		<guid>http://tc.eserver.org/29457.html</guid>
		<description>This article defines the niche for Technical Communicators / Writers in Usability Engineering. It makes an important observation &quot;Technical Communicator explains the product to users and Usability Engineer attempts to design self-explanatory products. If the design doesn&amp;apos;t speak up, Technical Communicators have to overwork.&quot; Technical communicators can serve as the &amp;apos;barometer&amp;apos; of user interface design.</description>
	</item>
	<item>
		<title>Designing and Writing to Reduce User Errors</title>
		<link>http://tc.eserver.org/27653.html</link>
		<guid>http://tc.eserver.org/27653.html</guid>
		<description>A vast majority of documents (I consider print and online as documentation) often works to define the optimized error-free method of performing a task and provides a user with a straightforward solution. However, the user expects documentation to help solve problems and address errors. Thus, attention must be paid to potential problems users can have and how to correct them. Errors have different causes; the information designer should understand the potential types of errors since properly addressing each type requires a different approach in the design and documentation.</description>
	</item>
	<item>
		<title>You Talking to Me?: Usability for Global Audiences on a Shoestring Budget</title>
		<link>http://tc.eserver.org/25162.html</link>
		<guid>http://tc.eserver.org/25162.html</guid>
		<description>For inexpensive usability, plan for content adaptation, presentation, access and feedback.</description>
	</item>
	<item>
		<title>Technisch Schrijvers Schuwen Onderzoek: Toch Kunnen Onderzoeksresultaten Praktisch Toepasbaar Zijn</title>
		<link>http://tc.eserver.org/21543.html</link>
		<guid>http://tc.eserver.org/21543.html</guid>
		<description>This article, which appeared in the Dutch journal Tekst[blad], describes four recent studies that are relevant to help developers, and suggests how help developers can use the knowledge gained from those studies to improve the performance support systems they build.</description>
	</item>
	<item>
		<title>How to Write a Report Without Getting Lynched</title>
		<link>http://tc.eserver.org/21429.html</link>
		<guid>http://tc.eserver.org/21429.html</guid>
		<description>You put forth your best effort to explain to the stupid sods exactly how and where they screwed up, then they have the temerity to not appreciate your fine efforts. Here&apos;s how to write a report that will cause change, instead of uproar.</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Usability/Technical-Writing.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>