<?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;Programming</title>	<link>http://tc.eserver.org/dir/Articles/Usability/Programming</link>
	<description>A listing of the most recently indexed works about Articles and Usability and Programming 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;Usability&gt;Programming</title>
		<link>http://tc.eserver.org/dir/Articles/Usability/Programming</link>
	</image>
	<item>
		<title>What It Really Takes to Handle Exceptional Conditions</title>
		<link>http://tc.eserver.org/30010.html</link>
		<guid>http://tc.eserver.org/30010.html</guid>
		<description>Handling exceptions, errors, and alternative flows are a critical part of defining good use cases and designing good software. Correct handling of esceptional conditions is not only necessary for correct realization of requirements and for system reliability, but is also an important factor in usability. This paper details a systematic approach to the design of exception handling in object-oriented software.</description>
	</item>
	<item>
		<title>Elevating Expressions</title>
		<link>http://tc.eserver.org/24708.html</link>
		<guid>http://tc.eserver.org/24708.html</guid>
		<description>There is a direct line between the abstraction embodied in our code and the reality of the people who will come into contact with that code. Methodologies and managers are beside the point—a distraction from the real issue.</description>
	</item>
	<item>
		<title>Product, Process, and Profit: The Politics of Usability in a Software Venture</title>
		<link>http://tc.eserver.org/20385.html</link>
		<guid>http://tc.eserver.org/20385.html</guid>
		<description>In research and in practice,usability specialists commonly target the technology user-interfaces and help as the main arena for bringing about usability improvements. However, usability improvements depend on more than innovative and user-centered technical designs and implementations. Equally important for creating useful and usable software are the social and political forces that shape the development context. These forces give rise to leadership conflicts, factional disputes, renegade efforts, alliances and betrayals, all of which profoundly influence whether usability improvements will be supported and sustained within and across projects. This essay presents and analyzes a case history of a software start-up company in which usability achieved a Pyrrhic victory, triumphing only in the short run because of social and political forces.&#xD;</description>
	</item>
	<item>
		<title>Time to Make Tech Work</title>
		<link>http://tc.eserver.org/20180.html</link>
		<guid>http://tc.eserver.org/20180.html</guid>
		<description>The IT industry is maturing. Hopefully, this maturity will result in a slower introduction of new features, which in turn will let companies focus their attention and resources on making existing technology work better for users.</description>
	</item>
	<item>
		<title>Why GNOME Hackers Should Care about Usability&#xD;</title>
		<link>http://tc.eserver.org/18292.html</link>
		<guid>http://tc.eserver.org/18292.html</guid>
		<description>Usable Us&apos;a*ble, a.&#xD;   Capable of being used.&#xD;&#xD;For such a simplistic definition, this encapsulates the fundamental goal of usability very well. Usable software is software that people can use; whether to write Email, play games or develop the next killer application. GNOME is many different things, but certainely one of its significant aspects is to provide an environment for users - for people. What a disappointment it should be when a user&apos;s ability to access one of the features we have coded is impaired or altogether halted because they don&apos;t understand how to manipulate the interface.</description>
	</item>
	<item>
		<title>Programmers and Usability</title>
		<link>http://tc.eserver.org/14133.html</link>
		<guid>http://tc.eserver.org/14133.html</guid>
		<description>In tandem with the theme of usability is the one of how to get (or help) programmers to communicate (to&#xD;the user, to us...) – and the general tone is that, in effect, programmers really don&apos;t care about the end&#xD;user&apos;s &apos;experience&apos; of the software.&#xD;If this is true, it occurs to me to wonder, WHY are programmers disinterested in usability?</description>
	</item>
	<item>
		<title>If We Build It, Will They Come? A Usability Test of Two Browser-based Embedded Help Systems</title>
		<link>http://tc.eserver.org/13531.html</link>
		<guid>http://tc.eserver.org/13531.html</guid>
		<description>The big problem with database-searching applications is that the user receives little feedback. Consider, for example, novice users starting to use Microsoft Word. The users want to right-justify a paragraph of text. Their efforts, either successful or unsuccessful, will be immediately apparent on the screen: The paragraph is either correctly justified or it isn&apos;t. However, a good-quality or a poor-quality search query used over a large database may retrieve 5,000 records, whether good or poor. How is the chemist to know whether the search query was effective and efficient? That is, how does the chemist know that the search query retrieved all and only the relevant records?</description>
	</item>
	<atom:link href="http://tc.eserver.org/dir/Articles/Usability/Programming.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>