The Web marches inexorably forward, and we love to see the innovations that come from that progress. But usually, a proportion of your users won’t see the new hotness. They’re stuck on an old ‘n busted browser that they either can’t update (because IE8 is the highest version of IE available for Windows XP, and corporate IT isn’t upgrading yet, and IT policy dictates IE only on the desktop) or won’t update (through sheer bloody-mindedness? I dunno…). So what do we as designers do?
There are two schools of thought here. One is right and good and just. The other is just wrong. Dirty, wrong and bad. Let’s deal with the bad first:
Graceful Degradation
Graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in more modern browsers, but it will also degrade gracefully to a lower level of user experience in older browsers. This lower level is not as nice to use for your site visitors, but it does still provide them with the basic functionality that they came to your site to use; things do not break for them.
Dev.Opera
Once the darling of the web community, graceful degradation fell from…ahem…”grace”…(thanks, I’m here all week…try the veal…) a few years ago when all of a sudden, everyone realized that building something and then making it partially work in other browsers (or, heaven forbid in this day and age of mobile devices, on other platforms) wasn’t the best way to go about development. Or, at the very least, it’s not ideal. So what’s the alternative?
Progressive Enhancement
This is the exact opposite approach:
[Progressive Enhancement] start[s] by establishing a basic level of user experience that all browsers will be able to provide when rendering your web site, but you also build in more advanced functionality that will automatically be available to browsers that can use it.
Dev.Opera
So while graceful degradation assumes complexity and tries to fix for older browsers, progressive enhancement assumes simple and builds complexity in as browsers become more capable.
How this applies in practice
By building your site and then removing functionality/design for older browsers (the graceful degradation approach) we’re providing a sub-par experience for what could amount to a significant proportion of your audience. On the other hand, by starting with a solid foundation, and building up we provide a consistent user experience that works everywhere, on every device, in all environments, and then adding features progressively as current (and future) browsers support them. This approach is future-proof.
So that user stuck on IE8 in their cubicle? A site built with the principles of progressive enhancement will work no matter what. It doesn’t matter that they’re on IE8. Sure, they may not see a few enhancements, but the core functionality and look of the site will be there, and it’ll look great to them.
Why choose progressive enhancement over graceful degradation? It’s the right thing to do for your users. But I’ll refer you back to the dev.opera.com site yet again for their final word on the subject:
Progressive enhancement will make both the end users and you happier:
- Regardless of environment and ability you deliver a product that works.
- When a new browser comes out or a browser extension becomes widely adopted you can enhance to yet another level without having to touch the original solution — graceful degradation would require you to alter the original solution.
- You allow technology to be what it is supposed to be — an aid to reach a goal faster than without it, not a “must” to be able to reach a goal in the first place.
- If you need to add new features, you can do so after checking if they are supported at a certain stage, or you can add it to the most basic level of functionality and make it better in more sophisticated environments. In any case, the maintenance happens at the same spot and not in two different places. Keeping a progressively enhanced product up-to-date is much less work than maintaining two versions.
Martin, great post! It makes absolute sense to start simple and layer on enhancements, rather than “dumb down” the experience. it’s the same logic behind the “mobile-first” movement of design/development. Now if we could only figure out a way to force all those poor schmoes stuck with IE8 to upgrade or switch browser #wishfulthinking.
Great post! I think I get the essence of this argument, and it would have been great to see an example of a situation or design problem.
BTW what will happen if I substitute “IE8” in your post with “IE6”. Would you still feel the same way? 🙂
Do you think that starting with the minimal common denominator always is the best way to go? Are there situations where that approach may not be best?
In the mobile app world, when building cross-platform apps, this task gets more challenging. In one of our efforts, HTML5/CSS3 was not fully functional on certain Android version+device combination. We ended up turning off the transitions between app screens completely for Android. Bit drastic, but what could we do differently? Perhaps in the interest of commonality, not have had the transitions at all everywhere, then added them selectively onto the iOS apps? Then would it matter which one we did first?
Amit, I’d definitely feel the same way. IE6 users shouldn’t feel excluded from accomplishing what they need to on a website. If we’re doing our job properly, then our baseline should probably be “unstyled HTML with no JavaScript”, and add CSS and JS progressively as browsers become more capable.
There are very few instances in which I think progressive enhancement is the wrong approach, but one would be where scripting is inherent within the product itself – think of maps, etc. In that example, we have to assume a certain level of functionality and capability for anything to work at all. A second example would be the retrofitting of an existing site where the project lacks time/budget for a more complete approach. But those are edge-cases. The vast majority of projects would benefit enormously from a progressive enhancement approach.
Your example of the mobile app is interesting, and it’s something that on first glance I’d have assumed to be fine – HTML5 and CSS3 works on all devices these days, right? Apparently not. In that case – had I been aware of the issue – I would have recommended feature testing (not browser sniffing, or any other nastiness) using something like Modernizr, and – where applicable – adding transitions based on the capability of the browser accessing the content. It may not have been possible in your specific example, but that would be a general approach I’d recommend. Defensive design! 🙂
Natalie, if you can think of a way to get everyone off IE8, I’m all ears! 🙂
First, let me preface my comments by stating that I am primarily a back-end web developer, so most of my front-end code focuses on ease of use and functionality over eye-candy whether it’s jQuery or CSS gradients, transitions, etc.
I completely agree with your suggestion of feature detection over browser detection, relying on the user-agent string is unreliable at best. I also agree with progressive enhancement in principle, but web standards exist so that we don’t have to write specific code for specific environments.
We’re no longer in the age of design for Netscape first and it will look OK on every other browser. In fact it’s just the opposite now where IE is the one you have to make hacks for. For me, this just feels like I’m encouraging bad behavior.
If Microsoft doesn’t support IE6 anymore, I’m certainly not going to. And if the user is going to insist on using a browser from a publisher who wants to make their own web standards (IE 8 is broken because of this) then I’m going to encourage the user to download a modern browser or at least install Chrome frame.
Corporate IT departments need to get out of the dark ages and start supporting Google Chrome. It’s far more secure that Internet Exploiter.