Ecommerce Developer
 
 

APIs & Plug-ins

Where Progressive Enhancement Meets Graceful Degradation

 

Two important web development philosophies are often at odds when it comes to using new or advanced technologies and supporting older browsers or low bandwidth connections. But as is the case with many polemic arguments, the best practice may reside on the middle ground between these two positions.

The Intersection of Progressive Enhancement and Graceful Degradation

Progressive Enhancement

Progressive enhancement is a web development strategy that encourages creating web pages for the lowest common denominator of browser and bandwidth and then adding successive, external layers of style and behavior to enhance the site for users with more advanced browsers. The philosophy argues for basic content availability on all browsers, basic functionality on all possible browsers, and sparse, semantic markup that includes all content.

While this strategy is inclusive—which is important for ecommerce sites that want customers regardless of connection speed or browser, and excellent for mobile commerce (mcommerce)—it may have a tendency to stifle application development and discourage the use of new techniques that may, in fact, make the user experience better for the vast majority.

Graceful Degradation

Graceful degradation, which is an older web development (and application development) philosophy, encourages the use of the most recent and best available techniques and technologies in a way that content is still available to older browsers. The concept is often referred to as fault tolerant, meaning that when a client—usually a web browser—fails to execute some code or style the web application does not fail, but rather continues to function and provide basic content albeit in a somewhat diminished capacity.

Both Philosophies Seek to Include More Users

Both progressive enhancement and graceful degradation seek to create usable web pages and web applications for the largest possible number of potential users. Progressive enhancement does this by focusing first on the least advanced users, building for them, and then adding to this foundation. Graceful degradation seeks to provide the best possible user experience and then ensures that users constrained with older technology can still interact in some way.

Where Progressive Enhancement is Strong

Progressive enhancement is at its best when it focuses on separating content, presentation, and behavior onto different layers so that each can be addressed, updated, and accessed separately. This is clearly a best practice that can and does dramatically reduce file size and make it easier to maintain a site. In terms of context, this aspect of progressive enhancement was a response to the blotted table-based HTML layouts popular in the late 1990's and early 2000's. Consider what Steve Champeon, who along with Nick Finck proposed progressive enhancement in March 2003, wrote about the state of web design in a 2003 Webmonkey article.

"Most web designers simply build sites quickly, using all the tricks they learned during the terrible browser wars. Tables for layout, font tags, hundreds of embedded images, single pixel GIFs, and so on - all get used, or abused, and whoever maintains the site usually makes it worse, unless they are highly disciplined.

"All of this extra presentational cruft just adds to the weight of a web document, without adding to the message for anyone but users of modern graphical desktop browsers. Most cell phone, PDA, and other mobile devices simply can't display such pages, because the markup itself is too big. Such devices don't have the memory, or the bandwidth, to show such huge pages."

Champeon's assertions were well founded. Table-based layouts and "spacer" GIFs seemed wrong even when they were the vogue style of web development, and we should be very grateful to progressive enhancement and similar ideas for making non-data tables, inline style, inline JavaScript, and other "cruft" far less common in modern web design and development.

Progressive enhancement is also effective at including mobile web clients. At the time that Champeon and Finck presented progressive enhancement many, if not most, mobile browsers had significant limitations, required that sites be written in wireless markup language (WML), and suffered from extraordinary bandwidth constraints. So if you wanted to engage users on these platforms, you needed to aim low.

Where Progressive Enhancement is Weak

Progressive enhancement, as useful as it is, makes an incorrect or outdated assumption about the nature of the web. It seems to assume that the web is primarily a means to convey static content in a single direction. It fails to recognize that sometimes the presentation is what is being communicated or that at other times a website or application may not wish to communicate at all.

Rather than being all about pushing content, the Internet is (or is becoming) an application platform analogous to an operating system like Windows 7 or Mac OS X Snow Leopard—the browser is the runtime for applications. The Internet is not just a place to access information, but a place to create, manage, distribute, interact, purchase, and more. By insisting, for example, that basic functionality be accessible to all browsers (a tenant of the philosophy), progressive enhancement artificially limits Internet applications.

Specifically, consider The Webcam Social Shopper by Zugara. A strict progressive enhancement adherent would never develop an augmented reality application like this one, since it is in no way usable on older browsers or even systems that do not have web cameras. It is beyond the scope of what the progressive enhancement concept imagines the Internet can or should do, and, yet, The Webcam Social Shopper is an example of how more advanced technologies, practices, and effects can provide a user experience not possible in markup alone. And let's face it, this application is not exactly bleeding edge. It makes use of plugins and equipment available to a significant number of users—possibly even the majority of Internet users. So that progressive enhancement can seem to be more concerned about including some technology stragglers than it is about providing a good user experience.

A Google project manager, Ian Fette, said the following during a Google I/O presentation last year when he and co-presenter, Matthew Papakipos, were asked about developing with HTML 5 given less than complete browser support:

"There is always some chicken and egg scenario," Fette said, "but certainly a lot [HTML 5 APIs] do have good implementation across multiple browsers, and I think that if you are doing something that is so new, so innovative and just looks so cool—I think if you say, you know you need to upgrade [your browser] and you need to get something new—it's not going to work for a hundred percent of people—but that's how we move forward."

Where Graceful Degradation is Strong

As a concept, graceful degradation properly recognizes that in order for the Internet to move forward and continue to provide better and more powerful user experiences, a certain segment of the total available market will be forced to upgrade or will not be able to enjoy all services and all functions.

Thus, graceful degradation encourages fast innovation. Effectively, it says that nothing is impossible. It allows site and application creators to imagine a thing and then set about creating that thing with the most efficient and effective tools available. It is the philosophy that would encourage using video product descriptions on a ecommerce site in spite of the fact that any user without a plugin, not running an HTML 5 capable browser, or using a mobile device that does not support rich Internet applications would not be able to see.

At the same time that graceful degradation looks forward to what is possible, it seeks to engage as many users as is feasible, avoiding single points of failure, so that users with older browsers or constrained mobile devices can still access most content in a convenient way. In fact, in most cases the user will not even know that they are missing out on some functionality.

A specific example of graceful degradation at work may be seen in an AJAX product-comparison table. Imagine a table that in a browser with JavaScript support allows the user to resort columns based on product attributes. If I am most interested in price, I can sort the items that way. If I want the items sorted by color, that is an option, too. The function requires JavaScript, but when displayed in a browser that does not support JavaScript, the basic data is still there. A user can still learn how much a product costs or what color it is, but that user does not have the same experience or functionality as a user with a more capable browser.

Where Graceful Degradation is Weak

Graceful degradation is much easier to accomplish in theory than it is in practice, and it can lead to no support for older or less capable web clients or, perhaps worse, sloppy workarounds.

The problem is that when I develop my applications or websites with only this philosophy in mind, I do almost all of my work in a target browser using less than inclusive technique or technology. When I am just about finished with the project, I test it in other browsers only to find that I really have a lot of work left to do, if I am serious about avoiding single points of failure and offering content to all. What is more likely to happen is that I will not actually support older browsers or I will quickly slap in heavy and wasteful code to avoid making fundamental changes in my site or application.

In practice, graceful degradation is rarely graceful, and often leads to ugly or failure-prone web pages, making it clear why Champeon and Finck proposed progressive enhancement in the first place.

Finding the Middle Ground

By themselves, neither progressive enhancement nor graceful degradation provides the proper ethos for a successful web development community that is both aimed at advancing the Internet as an application platform and concerned about compatibility and accessibility.

Rather, the best development philosophy may reside between these two poles. A pragmatic Internet development approach should seek to solve real user problems and not be afraid of using leading edge technology.

Consider the example of web workers in HTML 5. Web workers, which allow you to execute some JavaScript in a thread separate from the browser function thread, are not currently supported in Internet Explorer, but these workers mean that web browsers will be far less likely to crash or freeze, improving user experiences.

The middle ground allows for developers to use something like web workers, which some progressive enhancement adherents would shun, but only when it actually improves user experience rather than simply because it can be done.

Resources

0 Comments

Rss-sm