While attending FOWD last week in New York an overarching theme of Progressive Enhancement started to develop as more and more presentations preached it’s benefits. So what exactly is Progressive Enhancement? and how can we realistically use it and ensure our users and clients are happy with the end result?
Progressive Enhancement is all about delivering structured content to browsers and devices regardless of their capabilities, then adding layers of style and behavior that are progressively more complex. If you’re using a modern browser it will be able to render those complex styles and behaviors and deliver a beautiful rich experience. However, if you’re using a legacy browser or device, the content will be rendered to the best of browser’s ability with less complex styles and interactivity. The key here is that nothing breaks, it simply doesn’t look or behave the same in older browsers.
This probably sounds very similar to something web designers and developers have been preaching for years, Graceful Degradation. While they are similar, they have completely different objectives. Graceful Degradation has you building what the most modern browser can handle, and then ensuring that it degrades (or breaks) gracefully in older browsers. Progressive Enhancement on the other hand has you building for the lowest common denominator and then adding extra polish and functionality for browsers that can render it. Graceful Degradation has you looking backward, and Progressive Enhancement has you looking forward.
Why would you want to Progressively Enhance your website? Quite simply, you want to ensure that anybody who wants to consume the content you’re delivering can do so without getting slapped in the face with a broken unusable site. It will also lead to cleaner, semantic code which is easier to maintain and easier to upgrade (or enhance) at a later date.
Lets a take a look at a quick example. Here we have a pretty really basic nav with rounded corners, shadows, and a custom font. Normally we would build this using something like:
You can see we have code in there just to support the design, a div for the bottom corners, a class on the last list item to get rid of the last underline, and a container div to keep it all together. We would also have about 8 different image files for the corners, background, shadow and custom fonts. Don’t forget the PNG hacks to get everything looking properly in legacy browsers. All of that just to support a pretty basic design.
Ideally we would use something more like this:
Here we have clean semantic code with nothing but a class name (maybe) for the styling of this basic nav. No images are required for this navigation, we’ll let CSS take care of all the styling. Rounded corners, shadow, gradient background, custom fonts, and removing the underline on the last list item can all be taken care of with the latest CSS styles. I won’t dig into the CSS code for this today, but we’ll take a look at how this would look in different browsers.
As you can see, nothing would break and everything is still usable no matter which browser you’re using. If you’re using a newer browser you’ll see a little more polish than users with an older browser, and your experience will be a little bit better. Dan Cederholm used television as an excellent analogy for Progressive Enhancement. You can watch the latest episode of 30 Rock in glorious HD and surround sound if your home theater has an HD TV and a surround sound system. However, you can watch the exact same show on a 15″ black and white TV with mono sound. You’ll get the same content, and be able to talk about the same jokes around the water cooler regardless of what your home theater looks like. If you’ve invested in the latest and greatest TV and Audio gear you’ll be rewarded with a better experience. If you have a 15″ black and white TV, chances are you don’t care about that better experience, or at least understand why you’re not getting the best experience.
We need to use this type of analogy to explain Progressive Enhancement to our clients. Websites absolutely do not need to look the same in every browser. You can deliver an enhanced experience to users with the latest technology and not alienate users with legacy technology. The tricky part comes when you present a design with all the sparkle and polish to a client, and they can only see the basic lacklustre version of the final product because they’re using a browser that’s 10 years old. Finding a way to present the lo-fi and hi-fi versions in tandem will be key in selling Progressive Enhancement to clients, and moving web design forward.
written by Chris Erwin
I really love this idea. I think it’s a great next step for all of us who currently think in terms of graceful degradation.
You hit on part of the key to selling this through to clients: finding the right metaphor. The TV one is pretty apt.
I think the other part to pitching this concept is putting the costs of the alternative into perspective. For one, it costs us time and money (we estimate an additional 15-20%) to add hack-based workarounds. For two, it costs us scaleability and flexibility, due to less semantically-pure code. And finally, it costs the majority of users who would and could appreciate a best-in-class experience, because certain features and effects are simply not possible or worth the time and effort to deploy in a backwards-compatible way.
Nice article, Chris:
Most of the information I’ve read about progressive enhancement focuses on presentation solutions based on the capability of the renderer. Do you think that progressive enhancement should also apply to richness/amount of content delivered from the server to the client?
Even though handheld web browsing gets better and better, and network speeds for mobile are increasing, I think that in many cases, the content could be progressively enhanced as well to optimize it for the end-user’s bandwidth and rendering capability.
Does progressive enhancement apply here, or is it a different beast?
I think the analogy between the web and TV was great too. It really makes the point clear.
I also think this subject needs to be addressed to other designers as well, not only clients. There are still a lot of designers not using any CSS3 techniques because they feel that it is a waste of time if every browser cannot see them. I think if time permits, then put them in.
It’s a great concept, but is it worth the effort? How many end-users are actually running a browser version that is completely incapable of running/rendering an acceptable experience?
I think if we didn’t have speakers talking about these topics, what would the conference speakers talk about (gasp)?
I do think it is a very intelligent manner of approach—just don’t think, on the cusp of 2010, that it’s really worth it.
Just my 3 cents.
Great examples, but how is Progressive Enhancement really different from Graceful Degradation? No doubt it will be easier to sell to clients. Wouldn’t we all have our sites ‘enhanced’ and not ‘degraded’? But I don’t see them as two diametrically opposed concepts, rather that Progressive Enhancement is just the next step in the Evolution of Graceful Degradation.
The TV analogy is perfect, but even that is an example of Graceful Degradation. TV studios surely don’t shoot in black & white and add in color and such, Wizard of Oz style. They shoot in the highest possible resolution and image quality, then distribute their product using technology that allows for even the lowest common denominator to get some benefit. Just like someone using IE6 viewing your navigation example.
@craig: The spectrum of support for CSS between IE6, and modern browsers is vast. Old approaches meant playing to the lowest common denominator. With progressive enhancement users are rewarded for using modern browsers with an improved experience, while IE6 users still see a usable website. Best of both worlds.
@Adam: I see your point, I really do, and I agree that it makes sense, in every respect. But I do still believe that we also need to really understand and grasp our target market as best we can, and then do our very best to cater to them, and what we feel would best support the specs they would most likely have. We can only make due w/ the specs and stats we have access to, but I do think many of us should pay closer attention to them—you really will begin to get a finger on the pulse of what is going on out there.
Again, I do not disagree w/ your comments. Maybe I am simply frustrated w/ older browsers, deprecation, and a pace of change that is not as quick as I would like. I am impatient. I will admit that. I bitch when my tea at Starbucks takes too long. I think we all (and I am just as guilty), from time-to-time, begin to think everyone has a Macbook Pro, w/ 4GB of RAM, 20″ Cinema Display, etc. Reality is that do not. But I digress…
Great blog, by-the-way. You now have a new reader.
Another thing I think is really important: the simple fact that we can all have this conversation on a blog like this, in an intelligent, respectful, and productive manner. I really do like the type of reader this blog seems to attract, at least w/ the comments (for the most part).
Kudos to T+L, again, for doing what they do, which I have nothing but respect for them (even though they are most likely Toronto Maple Leafs fans).
I hate typos. Can someone please read my post directly above, and fix ‘em?
My eyes are fucking bleeding right now.
Again, much respect.
Peace from Ottawa.
Great post Chris.
It’s easy at first to confuse progressive enhancement and graceful degradation but it really is more than semantics. This small change in philosophy and practice can have a huge impact on what’s output.
Thanks for this!
@Iain – I personally think you should be delivering the same content no matter what the device or it’s capabilities. This doesn’t mean every device has to have the same experience though. I think if you want to create a ‘lite’ version of your content it should live in a different area so I can choose whether or not I see the lite content.
@Nate – I totally agree that Progressive Enhancement and Gracefully Degradation seem very similar, and at first I didn’t quite get the difference. They are basically opposite sides of the same coin. GD makes sure that if something doesn’t work we have a back-up plan, or message the user and tell them why it’s broken. IE: “you have javascript disabled so this widget won’t work”. PE on the other hand has you build for the lowest common denominator and then layer complexity on that newer browsers and devices will be able to render. GD has you start with the best and work backwards. PE has you start with the worst and work forwards.
@Craig and Adam – Great discussion. Using Progressive Enhancement would take time and care, but I honestly think it would take more time trying to make a design look pixel perfect in every browser. We’ve all been there, we all know it’s painful to get IE6 to play nice. When we do try to make everything look exactly the same in every browser we end up with frivolous code and ugly hacks that really don’t help anything but the design. With PE your code will be cleaner and you’ll pushing the envelope with your designs because IE6 isn’t holding you back anymore. I think that’s worth it alone. Thanks for your kudos and respect, it means a lot to us all, and FYI, not many die-hard Leafs fans here at T+L, just sayin ;)
I love the TV analogy and the philosophy behind this approach but many users don’t really differentiate between browser versions, at least not to the extent that they would a TV – a lot of people don’t even know which version they use.
I’d worried showing off an awesome design to a client and then when previewed on their company computers the design has degraded to an extent where the nice touches which bring life to it have been lost.
I do agree with Chris though using progressive enhancement will take time, I would much rather spend time initially designing something that we can show to users how website x may look on a couple of browser versions than spend hours creating hacks and workarounds.
Progressive Enhancement presents somewhat of a problem for web developers, and is likely why graceful degradation seems like a more widely adopted approach. We’re a breed that likes to stay on the brink of technology and more often than not will be using the latest, greatest, unreleased browsers/technologies. So, we end up developing for and catering to these platforms first since that’s what we’re working with and then build downwards to older browsers. Maybe it’d be better if we all started our development on IE6, and then built upwards? ;)
But then again, I suppose this could just be solved with a deeper understanding of browser capabilities…
Great article!
A (minor) pedantic observation: the class on the UL really shouldn’t be “rounded_nav”. Clean separation of content and presentation people! Especially when it won’t display as a rounded_nav on platforms that don’t support it.
“nav” would have been a good choice. I would lean toward id=”main_nav” rather than a class, unless the same presentation is going to apply to more than one nav on the page. Possibly even a id=”main_nav” class=”menu”.
When you build this way the thing just works. It works for microbrowsers (in phones and pertable game machines), inarchaic browsers, and in text and special browsers to help those who have disabilities. I frequently test what I’m building in a browser called “off by one” which is a simple-stupid HTML 3 capable browser with no CSS or JS support. I want my web apps to simply work reasonably well in that, but work really great in the latest browsers with all of the extra bells and whistles. I don’t care if we call it PE or GD. I just need to assure my client that for all of the visitor, the thing will just work.
And that’s what the client expects of us, for the thing to just work for their customers. The customers with the newest browsers get all of the extra bells and whistles; for those with the older browsers, the thing just works.
Happy clients and happy users are the upside.
So, where’s the downside?
PE DOES NOT MEAN YOUR SITE WILL WORK.
I agree with Craig, it’s not really worth the time to make sure your content is readable for every legacy browser. Even if you did, that does NOT mean the user is going to have a meaningful experience. Take IE6 for instance – I can design a site using PE that looks acceptable on IE6, but if my javaScript doesn’t work, what good does it do the user if they can’t click on “next page” or a menu link? I used to have to code “hacks” for IE6 all the time just so the functionality works, let alone have the site look good.
I think instead of worrying about legacy browsers, we should be focused on educating our users about version upgrades. As a matter of fact, many people don’t even realize there are version upgrades available! And many more don’t realize there are other browsers besides IE.
Take a look at this and you will notice just how quickly IE6, and IE7 for that matter, is dying. Notice January 2009 to January 2010. Huge drop!
http://www.w3schools.com/browsers/browsers_stats.asp.
In conclusion, for me, it’s not worth doing PE just so legacy browser can see things correctly, especially when I usually develop javaScript/jQuery/AJAX intense websites. Nonetheless, excellent blog. I highly respect the proactive approach of PE vs GD and if nothing else, this is a good idea moving forward for future browser/CSS versions ;)
You don’t have to mess about so much use cssPIE and you will see all this goodnes in IE6+ – There is no need to sacrifice the looks.