Graceful Degradation and How It Tricks You
Graceful Degradation and How It Tricks You
Join the DZone community and get the full member experience.Join For Free
Learn how Crafter’s Git-based content management system is reinventing modern digital experiences.
When Firefox finally bloomed to challenge the reign of IE6, it provided the first spark for the current browser wars. To rise to the challenge of properly displaying our websites in the emerging range of browser, two new concepts were born: progressive enhancement and graceful degradation. The latter became one of the key concepts of modern-day web development, which means it's time to re-evaluate its validity.
what is graceful degradation
Like most standing front-end development best practices, there's a certain level of vagueness surrounding the definition of said best practice. In this case, it's the definition of graceful that is not quantifiable, being a judgment that greatly relies on the ideologies of the person passing it. After all, grace is a very subjective quality, quite impossible to capture in a definite measure. And even if you could come up with a scoring system, other people bearing different priorities and ideologies would dismiss it as invaluable right away.
If you look at the practical bottom line though, graceful degradation adapted the meaning of something that still functions and does not look broken in older or less capable browsers. And as we are developers by nature, it also means that less effort equals more grace. It's why automated degradation (think superficial visual effects like drop shadows or rounded corners) are quite popular these days. Without any extra effort they degrade quite well in browsers not supporting these styles. Whether this degradation is actually graceful is an entirely different question.
The concept of graceful degradation is something I happily support, but the current translation makes things a little too easy for us, developers, while safely ignoring the well-being of our visitors. It has become an excuse for rapid development and sub-par global support of our website in older and less available technologies, something the original concept of graceful degradation was actually supposed to counter.
the slippery slope
The hollowing of graceful degradation started when designers began countering the notion that a design should be rendered pixel-perfect across all browsers. Early discussions were mostly purist affairs, explaining why sub-pixel font rendering and such made it inherently impossible to achieve pixel-perfect designs. While I whole-heartedly agree with that, it's a big stretch going from that to some of the degraded designs we see today.
Another obvious factor is the rise of html5 and css3, which provided us with tools to speed up our development and made it less painful to implement some of the more complex designs in modern browsers. Graceful degradation became a common counter for extended IE development as designs would not look broken in IE, just bare-bones. It gave us a quick way out, bypassing the crap IE usually gives us when working on a site. To make it even better, we were adhering to industry standards by doing so.
providing the best possible experience
These days, graceful degradation is not about providing the best possible experience anymore. It's about delivering something that is passable in older browsers so clients won't bitch about bugs and errors reported by IE6 users. It's about designing the best possible solution for the most advanced browser, and breaking it apart from there. While I do believe some people go through the trouble of investigation the client's user base first, many others don't and simply assume that what they're doing is okay for most people. Would they be forced to look at their own designs and implementations all day, they would probably change their mind quite quickly.
The result is that you're developing an optimized version for not even 50% of the web's users, while not bothering to optimize the degraded version for the rest. Sure we are now spending our time on responsive designs, but in the end it's only about 5% of our audience that will ever experience the benefits of that. What about the 50+% IE users who're looking at a bare-bones design of your site every day, or are missing implementable features that just didn't make it because it was too much trouble for you?
In contrast, a concept like progressive enhancement seems to facilitate the optimized experience for all parties much better. It starts from coming up with a solution (be it interaction design, visual design or technical implementation) for all (major) parties, and improving further on that for those who have the capabilities. It might not reach the excellence of a design exclusively made for the most modern technologies available, but it has a much better chance of providing a more pleasurable experience for people all-round.
I'm definitely not against graceful degradation. The concept is sound and it provides us with an worthwhile technique to deliver a website that can match modern standards. But the current translation of the concept is a little too easy-going and conflicts with the initial ideas behind the best practice. As (web) developers we live in a sheltered IT world full of fast computers, Apple gear and the most recent updates of our browser, but in the end it's the site stats of a client that counts.
If your target audience consists of 90% smartphone users, go right ahead and ditch those rounded corners, drop shadows and gradients for IE. But if more than 60% is still using IE8 or lower, think why you bothered to introduce these elements into your design, consider the loss of these additions and try to figure out whether you're not just making a crap version of your design simply because you can't be bothered to provide a better experience for users that are not you.
Graceful degradation is no excuse to provide sub-optimal browsing experiences, and if by now the concept is too far gone, maybe it's time to devaluate its meaning to just degradation and start pushing progressive enhancement once again.
Opinions expressed by DZone contributors are their own.