<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Interaction08: IxD&#8217;s in Savannah; Alan Cooper</title>
	<atom:link href="http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 09 Feb 2012 06:55:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2</generator>
	<item>
		<title>By: Ben Galbraith</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261276</link>
		<dc:creator>Ben Galbraith</dc:creator>
		<pubDate>Mon, 11 Feb 2008 15:46:43 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261276</guid>
		<description>
@starkraving, et al.: I think Alan&#039;s point wasn&#039;t that we shouldn&#039;t make changes to an application once the customer sees it; I think it was more that in his experience, a &quot;prototype&quot; often is the piece of code that is actually shipped, and if developers skimp on quality because it&#039;s a &quot;prototype&quot;, crap software will find its way out the door.


Having said that, I agree with you and others who defend the role of prototypes. A good HTML mock-up can go a long way.
</description>
		<content:encoded><![CDATA[<p>@starkraving, et al.: I think Alan&#8217;s point wasn&#8217;t that we shouldn&#8217;t make changes to an application once the customer sees it; I think it was more that in his experience, a &#8220;prototype&#8221; often is the piece of code that is actually shipped, and if developers skimp on quality because it&#8217;s a &#8220;prototype&#8221;, crap software will find its way out the door.</p>
<p>Having said that, I agree with you and others who defend the role of prototypes. A good HTML mock-up can go a long way.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Galbraith</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261267</link>
		<dc:creator>Ben Galbraith</dc:creator>
		<pubDate>Mon, 11 Feb 2008 05:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261267</guid>
		<description>@naterkane, Mike Wilcox: Yup, should have added the more tag. Updated the post.</description>
		<content:encoded><![CDATA[<p>@naterkane, Mike Wilcox: Yup, should have added the more tag. Updated the post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Wilcox</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261264</link>
		<dc:creator>Mike Wilcox</dc:creator>
		<pubDate>Sun, 10 Feb 2008 22:29:49 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261264</guid>
		<description>Can I get an AMEN!

@gcomnz: I think the point you are making is a call to developers. We can fantasize that our manager (my previous CEO) will read something such as this and suddenly &quot;get it&quot;, but they won&#039;t. My suggestion, as you apprently have done, is to seek out new employment with management that does get it. My current CEO is a former programmer, and we also use the suggested technique of the designer running the show. He does a tremendous job, and it works better than any &quot;Agile&quot; system that I&#039;ve previously been involved with.

@starkraving: While I agree that Alan Cooper used too absolute a term to negate prototypes, I agree with him. Another previous CEO would ask for a new prototype for every client that he planned to visit. And THEN he would ask for ANOTHER prototype that incorporated the suggestions of that potential client. Guess how many clients we landed that way? The current app I&#039;m working on utilizes about 200 design docs, and any interactivity that&#039;s not obvious is described in text. This gives the client pictures and colors to look at and pick apart, but doesn&#039;t give them the false sense that stuff moving and being clickable means that the project &quot;is almost done&quot;, or that it in a more advanced state than it actually is.

@naterkane: Can I get an AMEN! Common guys, some of us like to read your blogs on our iPhone. You know how much &quot;flicking&quot; was involved there?</description>
		<content:encoded><![CDATA[<p>Can I get an AMEN!</p>
<p>@gcomnz: I think the point you are making is a call to developers. We can fantasize that our manager (my previous CEO) will read something such as this and suddenly &#8220;get it&#8221;, but they won&#8217;t. My suggestion, as you apprently have done, is to seek out new employment with management that does get it. My current CEO is a former programmer, and we also use the suggested technique of the designer running the show. He does a tremendous job, and it works better than any &#8220;Agile&#8221; system that I&#8217;ve previously been involved with.</p>
<p>@starkraving: While I agree that Alan Cooper used too absolute a term to negate prototypes, I agree with him. Another previous CEO would ask for a new prototype for every client that he planned to visit. And THEN he would ask for ANOTHER prototype that incorporated the suggestions of that potential client. Guess how many clients we landed that way? The current app I&#8217;m working on utilizes about 200 design docs, and any interactivity that&#8217;s not obvious is described in text. This gives the client pictures and colors to look at and pick apart, but doesn&#8217;t give them the false sense that stuff moving and being clickable means that the project &#8220;is almost done&#8221;, or that it in a more advanced state than it actually is.</p>
<p>@naterkane: Can I get an AMEN! Common guys, some of us like to read your blogs on our iPhone. You know how much &#8220;flicking&#8221; was involved there?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: naterkane</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261262</link>
		<dc:creator>naterkane</dc:creator>
		<pubDate>Sun, 10 Feb 2008 18:53:53 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261262</guid>
		<description>can these long posts ever get split with a &lt;code&gt;more&lt;/code&gt; tag? not a big deal, but sometimes, it just makes sense.</description>
		<content:encoded><![CDATA[<p>can these long posts ever get split with a <code>more</code> tag? not a big deal, but sometimes, it just makes sense.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: polterguy</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261260</link>
		<dc:creator>polterguy</dc:creator>
		<pubDate>Sun, 10 Feb 2008 11:49:50 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261260</guid>
		<description>A breadth of fresh air, write more of these &quot;meta&quot; blogs :)
Funny though that he doesn&#039;t emphasize the fact that &quot;every&quot; single piece of innovation is built from a small startup with less than 10 employees who are outperforming every trillion dollar company in the world. Again and again...
I think he explains this pretty nicely though he doesn&#039;t use it as an argument to why it is like this. I think that fact is the number one most important reason or proof of that he&#039;s right...
Regarding the iPhone (and iPod etc) I would very much like to understand what the &quot;code&quot; of Apple really is...
(Since they&#039;re obviously NOT a startup)</description>
		<content:encoded><![CDATA[<p>A breadth of fresh air, write more of these &#8220;meta&#8221; blogs :)<br />
Funny though that he doesn&#8217;t emphasize the fact that &#8220;every&#8221; single piece of innovation is built from a small startup with less than 10 employees who are outperforming every trillion dollar company in the world. Again and again&#8230;<br />
I think he explains this pretty nicely though he doesn&#8217;t use it as an argument to why it is like this. I think that fact is the number one most important reason or proof of that he&#8217;s right&#8230;<br />
Regarding the iPhone (and iPod etc) I would very much like to understand what the &#8220;code&#8221; of Apple really is&#8230;<br />
(Since they&#8217;re obviously NOT a startup)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: starkraving</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261255</link>
		<dc:creator>starkraving</dc:creator>
		<pubDate>Sat, 09 Feb 2008 21:47:05 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261255</guid>
		<description>I own &quot;The Inmates are Running the Asylum&quot; and &quot;About Face 2.0&quot;. Both are extremely good books and I&#039;ve actually implemented the strategies and processes from About Face to make several extremely successful projects. The only disagreement I&#039;ve always had is his insistence that prototyping has a limited role in developing software. I see his point when it&#039;s dealing with physical products, but when you&#039;re dealing with web applications the use of prototypes is crucial. After a wireframe has been agreed upon where you work out with the customer the scope and flow of the application, the prototype is how you illustrate and really underscore the manner in which this new application will work. Not only that, but this is the phase where the most visual progress is made. The pure programming end is largely invisible to the client: it&#039;s where you design the database, write the business model, etc. If you give the client an HTML prototype before any of that they get the benefit of a more rapidly apparent picture and they also get to be involved in the implementation at a stage where changes are easy to implement.
A narrative would be &quot;this page shows a form where the user can sign up to be a member&quot;. That&#039;s great when you&#039;re working out the flow and scope of the project and is actually necessary to do because in my observation clients are obsessed with visuals -- to the point where if you offer visuals when they are supposed to be focusing on developing a picture of their entire application they completely forget what they were supposed to be doing and instead ask if the font can be Verdana instead of Arial. 
But, once the flow and scope of a project is developed then this narrative description of the form is no longer enough. You absolutely need to show the client an HTML prototype of the form, so that they can see what fields are there and provide their feedback. At this point it&#039;s easy to add or remove fields and what type, since there is no database or business model yet. 
The back-end should support the front-end, not the other way around.</description>
		<content:encoded><![CDATA[<p>I own &#8220;The Inmates are Running the Asylum&#8221; and &#8220;About Face 2.0&#8243;. Both are extremely good books and I&#8217;ve actually implemented the strategies and processes from About Face to make several extremely successful projects. The only disagreement I&#8217;ve always had is his insistence that prototyping has a limited role in developing software. I see his point when it&#8217;s dealing with physical products, but when you&#8217;re dealing with web applications the use of prototypes is crucial. After a wireframe has been agreed upon where you work out with the customer the scope and flow of the application, the prototype is how you illustrate and really underscore the manner in which this new application will work. Not only that, but this is the phase where the most visual progress is made. The pure programming end is largely invisible to the client: it&#8217;s where you design the database, write the business model, etc. If you give the client an HTML prototype before any of that they get the benefit of a more rapidly apparent picture and they also get to be involved in the implementation at a stage where changes are easy to implement.<br />
A narrative would be &#8220;this page shows a form where the user can sign up to be a member&#8221;. That&#8217;s great when you&#8217;re working out the flow and scope of the project and is actually necessary to do because in my observation clients are obsessed with visuals &#8212; to the point where if you offer visuals when they are supposed to be focusing on developing a picture of their entire application they completely forget what they were supposed to be doing and instead ask if the font can be Verdana instead of Arial.<br />
But, once the flow and scope of a project is developed then this narrative description of the form is no longer enough. You absolutely need to show the client an HTML prototype of the form, so that they can see what fields are there and provide their feedback. At this point it&#8217;s easy to add or remove fields and what type, since there is no database or business model yet.<br />
The back-end should support the front-end, not the other way around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gcomnz</title>
		<link>http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper/comment-page-1#comment-261253</link>
		<dc:creator>gcomnz</dc:creator>
		<pubDate>Sat, 09 Feb 2008 20:05:33 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/archives/interaction08-ixds-in-savannah-alan-cooper#comment-261253</guid>
		<description>His observations about business management&#039;s issues are great...right up until we are supposed to install designers as the new management. That&#039;s where it presumes that somehow the new king doesn&#039;t have their own batch of issues to deal with that create their own batch of problems. He may have nailed the problem, but he definitely didn&#039;t nail the solution.

The really telling moment is when he says, &quot;Then you enlist programmers: you tell them you will fight for quality if they implement your designs. You can say to them, â€œI will go to management and fight to get you the resources to determine how much its going to cost and how you are going to accomplish these problems, if when you build it, you will follow my specifications.â€ I believe programmers have been waiting for someone to make this deal, and Iâ€™m convinced management wonâ€™t make this deal. Youâ€™re giving them what they want: the ability to be great craftsmen.&quot; 

Heh, the biggest load of tripe every. I hear this statement WEEKLY from some new savior. Programmers are NOT waiting for this BS to be rolled out to them yet one more time. If they are polite they smile, pretend to believe it, and now deal with the new layer of saviors supposedly &quot;protecting&quot; them.

My biases: I am a graphic designer, developer, lead, software architect, and I&#039;ve suffered through my stints as middle management. Now I mostly design, architect, and develop software, with a great team of great programmers, and it works because of agile processes and executive teams who CAN deal with the time it takes to develop excellent software.</description>
		<content:encoded><![CDATA[<p>His observations about business management&#8217;s issues are great&#8230;right up until we are supposed to install designers as the new management. That&#8217;s where it presumes that somehow the new king doesn&#8217;t have their own batch of issues to deal with that create their own batch of problems. He may have nailed the problem, but he definitely didn&#8217;t nail the solution.</p>
<p>The really telling moment is when he says, &#8220;Then you enlist programmers: you tell them you will fight for quality if they implement your designs. You can say to them, â€œI will go to management and fight to get you the resources to determine how much its going to cost and how you are going to accomplish these problems, if when you build it, you will follow my specifications.â€ I believe programmers have been waiting for someone to make this deal, and Iâ€™m convinced management wonâ€™t make this deal. Youâ€™re giving them what they want: the ability to be great craftsmen.&#8221; </p>
<p>Heh, the biggest load of tripe every. I hear this statement WEEKLY from some new savior. Programmers are NOT waiting for this BS to be rolled out to them yet one more time. If they are polite they smile, pretend to believe it, and now deal with the new layer of saviors supposedly &#8220;protecting&#8221; them.</p>
<p>My biases: I am a graphic designer, developer, lead, software architect, and I&#8217;ve suffered through my stints as middle management. Now I mostly design, architect, and develop software, with a great team of great programmers, and it works because of agile processes and executive teams who CAN deal with the time it takes to develop excellent software.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

