This week’s A List Apart included Understanding Progressive Enhancement by Aaron Gustafson. I was pretty jazzed to read the article, because I’ve been hoping for a simple explanation of progressive enhancement to show my supervisor for some time.

Unfortunately, after reading Understanding Progressive Enhancement I realized that the article didn’t actually define progressive enhancement. It had a great description of the concept of graceful degradation, but when it got to progressive enhancement it became abstract to the point that I don’t think someone who isn’t already passingly familiar with the idea would understand it.

I am not a mover and thinker when it comes to web design and development, but at the least I can offer a complementary explanation for Gustafson’s workflow-oriented description.

As Gustafson says, graceful degradation focuses on building out a great site, and then testing on older browsers and tweaking things to make sure the users have at least a half-assed experience.

Progressive enhancement has very similar results (cutting-edge users get the best experience, users with older or otherwise limited technology get a less ideal experience), but comes from a different angle. Gustafson says that progressive enhancement is all about the content, and then goes into a long, slightly flawed metaphor about Peanut M&Ms. Mildly wonky metaphor aside, he’s right about content being the important thing; he just needs a succinct definition and concrete examples.

Progressive enhancement is the idea that you should design your content in a way that is accessible no matter how your users access your site, and then add Javascript interactions and advanced CSS afterwards to make the lives of people who have capable browsers easier and more beautiful.

For me, I find this best illustrated with a pair of examples.

I have two sites I have been working on recently. For both of them I am the interface coder; I receive Photoshop designs, and am responsible for building them in HTML, CSS, and enough PHP to tie into the developer’s backend. The first project is a Web 2.0 startup that I inherited from a previous developer. The second was designed by a professional print and web design house and handed off to me for conversion to HTML.

For the first site, the code I inherited uses a lot of Javascript to make the interactions work. The user enters the site, types some information, and things swoop across the screen to quickly lead them through what the site has to offer before depositing them on a signup form. If the user has Javascript disabled links don’t work, the form fields remain populated with filler text (apparently a background image), and the user never sees the signup form. This site was designed for (eventual) graceful degradation. The designers and coder took their perfect world vision and implemented it, and were planning to go back over everything once it was done to make sure that some semblance of a workflow would exist in older browsers or browsers that don’t support Javascript.

For the second site, the designers provided me not only with the Photoshop files, but with a complete user experience description. The user experience description included a semi-interactive Flash file on the homepage, an automatically scrolling list of article titles that reacted to mouse movements, and other bells and whistles. First, I built out the in HTML and CSS and once I had tested everything I added the Flash and Javascript interactions (making sure that should those technologies not be present the site would fallback to my original vanilla designs).

This second approach is a limited example of coding using the idea of progressive enhancement. I knew that what was important was that no matter what technology the user had available, they should be able to reach the content, so in my first iteration of code all links lead somewhere, all navigation elements were present, and even a user with a stripped-down mobile browser would be able to navigate and read the site (even if it looked terrible). The Javascript and Flash thus enhance the user’s experience, but are not necessary for the user to experience the basic content and interactions the site has to offer.

The problems with graceful degradation in the first site should be self-evident. By focusing solely on making their interactions slick and perfect immediately, the first coder crippled the site for any number of users. Content delivery in all situations isn’t the focus; instead “fixing” old browsers will eventually be the focus.

The reason progressive enhancement is an important idea for web designers to get their heads around is that if you use progressive enhancement to guide your design you don’t have to patch obvious failings but instead build an ever-improving user experience on a solid foundation. Not all browsers may look and feel the same, but regardless of the tools at their disposal users will be able to access and interact with your site’s content in ways that were part of your overall design. Even if they can’t articulate it, users can tell when their experience is an afterthought rather than a priority, and as a result you only stand to gain.