<?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"
	>
<channel>
	<title>Comments on: Adaptive Path&#8217;s Take on the Web 2.0 Spec</title>
	<atom:link href="http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/</link>
	<description>Making Web 2.0 More Than a Catchprhase</description>
	<pubDate>Thu, 28 Aug 2008 17:32:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: ajm</title>
		<link>http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/#comment-156</link>
		<dc:creator>ajm</dc:creator>
		<pubDate>Tue, 07 Nov 2006 17:51:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/#comment-156</guid>
		<description>Dan: I totally agree. Re-reading my post, I realized it comes off sounding very "anti-consultant," "anti-Adaptive Path" and I'd like to apologize for that: I worked previously in a "big consulting company with a funky accent in their logo" and the jaded ex-consultant came through a bit too heavily in certain sections. :-)

I've actually been trying to get our product and development teams on board with doing "rich" specs like these. I've found a couple sticking points: people tend to believe the extra detail isn't necessary (against which I argue, how can we design and develop that extra detail if it's left out of the documentation process entirely), the process is too time consuming (against which I argue that the time is worthwhile and probably not much more than we spend on "flat" specs now), and, finally, that people may not have the background to pull these specs off. It's this last point that I can't counterargue.

Working in a very mixed environment where the spec-writers may not have design or development backgrounds, I find that the biggest sticking point to introducing rich specifications is that people are afraid to believe that their design - PPT - HTML - Photoshop - (heck, even Paint) skills are good enough to do prototypes or specs like these. People are reluctant to enter the imagined world of the "designer" or "developer" - "the only people with the skills to do these things" - which makes them reluctant to produce the high-quality documents that you and I believe should be produced throughout a project process.</description>
		<content:encoded><![CDATA[<p>Dan: I totally agree. Re-reading my post, I realized it comes off sounding very &#8220;anti-consultant,&#8221; &#8220;anti-Adaptive Path&#8221; and I&#8217;d like to apologize for that: I worked previously in a &#8220;big consulting company with a funky accent in their logo&#8221; and the jaded ex-consultant came through a bit too heavily in certain sections. <img src='http://blog.amodernfable.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>I&#8217;ve actually been trying to get our product and development teams on board with doing &#8220;rich&#8221; specs like these. I&#8217;ve found a couple sticking points: people tend to believe the extra detail isn&#8217;t necessary (against which I argue, how can we design and develop that extra detail if it&#8217;s left out of the documentation process entirely), the process is too time consuming (against which I argue that the time is worthwhile and probably not much more than we spend on &#8220;flat&#8221; specs now), and, finally, that people may not have the background to pull these specs off. It&#8217;s this last point that I can&#8217;t counterargue.</p>
<p>Working in a very mixed environment where the spec-writers may not have design or development backgrounds, I find that the biggest sticking point to introducing rich specifications is that people are afraid to believe that their design - PPT - HTML - Photoshop - (heck, even Paint) skills are good enough to do prototypes or specs like these. People are reluctant to enter the imagined world of the &#8220;designer&#8221; or &#8220;developer&#8221; - &#8220;the only people with the skills to do these things&#8221; - which makes them reluctant to produce the high-quality documents that you and I believe should be produced throughout a project process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Saffer</title>
		<link>http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/#comment-155</link>
		<dc:creator>Dan Saffer</dc:creator>
		<pubDate>Tue, 07 Nov 2006 15:50:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.amodernfable.com/2006/11/02/adaptive-paths-take-on-the-web-20-spec/#comment-155</guid>
		<description>Specs like these are for when you aren't building the app yourself, which is a situation that we find ourselves in often, working with client development teams. 

The low fi animations shouldn't take long to make, btw. I've made them in 20 minutes with animated gifs.</description>
		<content:encoded><![CDATA[<p>Specs like these are for when you aren&#8217;t building the app yourself, which is a situation that we find ourselves in often, working with client development teams. </p>
<p>The low fi animations shouldn&#8217;t take long to make, btw. I&#8217;ve made them in 20 minutes with animated gifs.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
