<?xml version="1.0" encoding="utf-8" ?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<title>Hale, Kevin</title>	<link>http://tc.eserver.org/authors/Hale,_Kevin</link>
	<description>A bibliography of works by Hale, Kevin 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>Hale, Kevin</title>
		<link>http://tc.eserver.org/dir/Hale,_Kevin</link>
	</image>
	<item>
		<title>A Designer&apos;s Guide to Prototyping Ajax</title>
		<link>http://tc.eserver.org/27693.html</link>
		<guid>http://tc.eserver.org/27693.html</guid>
		<description>Jeffery Zeldman wrote earlier this year in his essay about Web 3.0 that &apos;Wireframing AJAX is a bitch.&apos; And while I can&apos;t deny the statement, I do think there are steps we can take to alleviate the pain. The problem is static XHTML/CSS wireframes are woefully inefficient at the task of communicating and documenting the features available to the new crop of Ajax web sites. Because we&apos;ve been working on a rather intense Ajax project for the last few months, we&apos;ve been developing and refining a number of techniques and guidelines to help our team design for Ajax by moving beyond the traditional forms of functional specs and wireframes to something a bit more appropriate for the dynamic medium&apos;rapid prototyping.</description>
	</item>
	<item>
		<title>JavaScript Basics for Prototyping</title>
		<link>http://tc.eserver.org/27688.html</link>
		<guid>http://tc.eserver.org/27688.html</guid>
		<description>I know there are a good number of designers out there afraid of anything that smells of programming (basically, if it&apos;s not plug and play, it&apos;s not being used). I completely understand. Dealing with CSS rending across browsers is bad enough already. Because prototypes are all about making an interface &apos;look&apos; like it works, the dabbling we&apos;re going to go over here is actually a process that&apos;s amenable to designers (especially those with programming skills that started off as just rudimentary hacking skills). CSS is the domain that most of the new crop of web designers are most comfortable with and so the functions we&apos;re going to go over are ones that manipulate, for the most part, the styles of our elements.</description>
	</item>
	<item>
		<title>Ajax Wireframing Approaches</title>
		<link>http://tc.eserver.org/27684.html</link>
		<guid>http://tc.eserver.org/27684.html</guid>
		<description>Goes over a few techniques and approaches we use to create the foundation of every prototype--wireframes. In addition to serving as documentation for those working with the markup, wireframes are a great way to create screenshots and debug rendering problems that are happening during DOM manipulation. Whenever we find something looking funny during the development process, we always refer back to our wireframes to see if it’s a markup / presentation problem. If it renders right in the browser statically, then we know to look for the problem in the JavaScript or server side programming.</description>
	</item>
	<atom:link href="http://tc.eserver.org/authors/Hale,_Kevin.xml" rel="self" type="application/rss+xml"/>
</channel>
</rss>