<?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: The issue with progressive enhancement</title>
	<atom:link href="http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/feed/" rel="self" type="application/rss+xml" />
	<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/</link>
	<description>Capturing the thoughts of Paul Bakaus</description>
	<lastBuildDate>Mon, 24 Oct 2011 22:49:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Paul</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-234</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Thu, 15 Apr 2010 16:33:43 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-234</guid>
		<description>@Sander Aarts: Re lock-in: I agree when it comes to intranet applications (I know the pain!). I disagree when it comes to highly specialized platforms, like TV&#039;s, smartphones, etc. most web software on consumer hardware should be targetted.</description>
		<content:encoded><![CDATA[<p>@Sander Aarts: Re lock-in: I agree when it comes to intranet applications (I know the pain!). I disagree when it comes to highly specialized platforms, like TV&#8217;s, smartphones, etc. most web software on consumer hardware should be targetted.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-233</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Thu, 15 Apr 2010 16:15:59 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-233</guid>
		<description>@Scott: Thanks for your insightful comment. I actually agree with your point – if you&#039;re separating the planning/design process from the implementation (which, unfortunately, not all people do..), this definitely might work out. So I think what you&#039;re saying is to basically use GD on the planning/design phase, and then use PE in the implementation phase. I didn&#039;t think of that yet, but I&#039;ll definitely give it a try! And I guess I should finally read your book :)</description>
		<content:encoded><![CDATA[<p>@Scott: Thanks for your insightful comment. I actually agree with your point – if you&#8217;re separating the planning/design process from the implementation (which, unfortunately, not all people do..), this definitely might work out. So I think what you&#8217;re saying is to basically use GD on the planning/design phase, and then use PE in the implementation phase. I didn&#8217;t think of that yet, but I&#8217;ll definitely give it a try! And I guess I should finally read your book <img src='http://paulbakaus.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sander Aarts</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-232</link>
		<dc:creator>Sander Aarts</dc:creator>
		<pubDate>Mon, 12 Apr 2010 21:43:32 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-232</guid>
		<description>PE is basicly the best method to achieve GD.
In most cases you know at the start of the building proces what the the final result will have to be like. Therefor any PE immediately starts as a GD from that target.

Btw. targeting a single platform is never cool, not even (or especially) for intranets. By doing so you almost certainly establish some level of vendor/version lockin, which is essentially why we&#039;re still stuck with IE6. Let us not repeat that mistake.</description>
		<content:encoded><![CDATA[<p>PE is basicly the best method to achieve GD.<br />
In most cases you know at the start of the building proces what the the final result will have to be like. Therefor any PE immediately starts as a GD from that target.</p>
<p>Btw. targeting a single platform is never cool, not even (or especially) for intranets. By doing so you almost certainly establish some level of vendor/version lockin, which is essentially why we&#8217;re still stuck with IE6. Let us not repeat that mistake.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-231</link>
		<dc:creator>Scott</dc:creator>
		<pubDate>Mon, 12 Apr 2010 20:43:27 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-231</guid>
		<description>Paul, I assume you&#039;d expect me to disagree with this article, but I do think you&#039;ve got the PE process a little mixed up. If you approach an interface design based solely on what&#039;s available in the HTML4 form toolbox, you&#039;re probably right that it&#039;s going to influence and limit the creativity of the design. However, I don&#039;t think that is how most designers approach a problem these days, and PE itself certainly doesn&#039;t require that approach. 
Progressive Enhancement isn&#039;t there to get in your way during the design process. On the contrary, it&#039;s purpose is to let you design freely while acting responsible to your users when it comes time to make it functional. It&#039;s a methodology for *implementing* a design, and given the tools at our disposal, it&#039;s pretty rare to see a design that can&#039;t be implemented using these best practices. 
You should design on your blank canvas if it helps you think more freely, then after that, consider how to map your enhanced components back to simple HTML so the important parts are usable without JavaScript (slider manipulates an input or select element, ). Then to really follow-through, you&#039;ll need to also consider the usability and accessibility of the components for those who receive the ideal experience as well (with reasonable affordance, ARIA, keyboard control, focus management, etc), since simply making it work without JS does not mean it&#039;s accessible or usable. In our book on PE, we call this part of the design process the &quot;X-Ray approach.&quot; It&#039;s a planning phase between static design and implementation where you figure out how to make it all work, regardless of what it is.</description>
		<content:encoded><![CDATA[<p>Paul, I assume you&#8217;d expect me to disagree with this article, but I do think you&#8217;ve got the PE process a little mixed up. If you approach an interface design based solely on what&#8217;s available in the HTML4 form toolbox, you&#8217;re probably right that it&#8217;s going to influence and limit the creativity of the design. However, I don&#8217;t think that is how most designers approach a problem these days, and PE itself certainly doesn&#8217;t require that approach.<br />
Progressive Enhancement isn&#8217;t there to get in your way during the design process. On the contrary, it&#8217;s purpose is to let you design freely while acting responsible to your users when it comes time to make it functional. It&#8217;s a methodology for *implementing* a design, and given the tools at our disposal, it&#8217;s pretty rare to see a design that can&#8217;t be implemented using these best practices.<br />
You should design on your blank canvas if it helps you think more freely, then after that, consider how to map your enhanced components back to simple HTML so the important parts are usable without JavaScript (slider manipulates an input or select element, ). Then to really follow-through, you&#8217;ll need to also consider the usability and accessibility of the components for those who receive the ideal experience as well (with reasonable affordance, ARIA, keyboard control, focus management, etc), since simply making it work without JS does not mean it&#8217;s accessible or usable. In our book on PE, we call this part of the design process the &#8220;X-Ray approach.&#8221; It&#8217;s a planning phase between static design and implementation where you figure out how to make it all work, regardless of what it is.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: HB</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-230</link>
		<dc:creator>HB</dc:creator>
		<pubDate>Mon, 12 Apr 2010 16:42:55 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-230</guid>
		<description>PE and GD are both fine given unlimited resources. GD may even encourage more creativity because you&#039;re not &quot;restricted&quot; by an underlying no-behavior, no-style structure.

But these days PE is more widely preached than GD because of its practicality. On a project where sudden time or budget constraints may arise, or clients may change their minds halfway through a project, you lose less with PE than you do with GD.

Say you&#039;re working on a large web application for a client, and 2/3 of the way through the project ends prematurely (for whatever reason). With GD, many visitors may be completely unable to use the application because you never made it to the accessibility phase. With PE, your app works 100% of the time, for 100% of the visitors. It may not have reached its full creative potential, but it works. And without unlimited resources, that is the more important factor.</description>
		<content:encoded><![CDATA[<p>PE and GD are both fine given unlimited resources. GD may even encourage more creativity because you&#8217;re not &#8220;restricted&#8221; by an underlying no-behavior, no-style structure.</p>
<p>But these days PE is more widely preached than GD because of its practicality. On a project where sudden time or budget constraints may arise, or clients may change their minds halfway through a project, you lose less with PE than you do with GD.</p>
<p>Say you&#8217;re working on a large web application for a client, and 2/3 of the way through the project ends prematurely (for whatever reason). With GD, many visitors may be completely unable to use the application because you never made it to the accessibility phase. With PE, your app works 100% of the time, for 100% of the visitors. It may not have reached its full creative potential, but it works. And without unlimited resources, that is the more important factor.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-229</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Mon, 12 Apr 2010 12:35:07 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-229</guid>
		<description>@T: What I actually meant is that the great painter is not forced to start with a basic shape, and instead can focus on abstract and non-existant shapes (for instance). You&#039;re right that a drawing process usually requires layering, but it is a different kind of layering. In the web world, you could best compare it with unstyled vs. styled content.

Thanks for your good comment!</description>
		<content:encoded><![CDATA[<p>@T: What I actually meant is that the great painter is not forced to start with a basic shape, and instead can focus on abstract and non-existant shapes (for instance). You&#8217;re right that a drawing process usually requires layering, but it is a different kind of layering. In the web world, you could best compare it with unstyled vs. styled content.</p>
<p>Thanks for your good comment!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: T</title>
		<link>http://paulbakaus.com/2010/04/12/the-issue-with-progressive-enhancement/#comment-228</link>
		<dc:creator>T</dc:creator>
		<pubDate>Mon, 12 Apr 2010 11:39:29 +0000</pubDate>
		<guid isPermaLink="false">http://paulbakaus.com/?p=334#comment-228</guid>
		<description>On the whole I agree with you regarding blindly following best practice (though I do tend to always lean towards PE, mostly out of habit I guess), but your PE analogy seems flawed - it assumes whoever is doing the final layer of enhancement had no input in the original. 

In fact, if the master painter started from a blank canvas he would still be using progressive enhancement - painting a base first and adding more layers until he reach his final piece.

I think you have made a good point, you just didn&#039;t notice it. From what I read into your master painter example is that PE doesn&#039;t have to limit creativity as long as later stages of enhancement had input in the preceding ones. You are limited only by the canvas you choose, not the technique.</description>
		<content:encoded><![CDATA[<p>On the whole I agree with you regarding blindly following best practice (though I do tend to always lean towards PE, mostly out of habit I guess), but your PE analogy seems flawed &#8211; it assumes whoever is doing the final layer of enhancement had no input in the original. </p>
<p>In fact, if the master painter started from a blank canvas he would still be using progressive enhancement &#8211; painting a base first and adding more layers until he reach his final piece.</p>
<p>I think you have made a good point, you just didn&#8217;t notice it. From what I read into your master painter example is that PE doesn&#8217;t have to limit creativity as long as later stages of enhancement had input in the preceding ones. You are limited only by the canvas you choose, not the technique.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

