If you know about the timeless importance of graceful degradation then you need not read this, but for those of you who think it’s an old-fashioned methodology or even an optional technicality then let me be the first to tell you that you’re wrong! I know this may put me, a mere 18-year-old web developer in the awkward position of having to tell some ignorant 50-year-old that they’re wrong but I’m perfectly comfortable with that if it ensures a better internet!
I’ve never surfed the web in a browser less capable than IE5, this should say quite a lot about my lack of understanding of less capable pieces of software and devices, yet, I still appreciate and understand that graceful degradation is of upmost important when creating any website.
Let’s look at your average out-of-college web designer’s perspective on graceful degradation, assuming they know what it means:
Note: When reading the below passage out in your head do it with an "Artful Dodger" (from Oliver Twist) accent; it’ll come across as more believable!
Some idiot:
"Look, mate, I’m NOT gonna build an entire website which validates, is table-less and has degrading JavaScript for any amount of money – that’s just stupid! Even if that 5% stat were true (I doubt it) I wouldn’t feel any different. Graceful degradation is an added feature; something which clients should have to pay more for! I make clients pay more for validation, table-less layouts, optimized images, IE6 support, IE7 support, Opera support, actually anything which isn’t Firefox (FF FTW!) I charge extra for! My approach is way more forward-thinking and innovative than those "standardistas"!! Who the hell gives a damn about some paranoid geek running Lynx to browse the web, and nobody even uses NoScript! If a user disables JavaScript then that user shouldn’t expect functionality, period! And as far as I’m concerned, if a user doesn’t have the very latest nightly build of FF3 then I’m not gonna cater to them!"
Why the idiot is wrong:
The above passage represents the complete and utter idiocy of some people, real people! You might think it’s a little over the top, what with the "if a user doesn’t have the very latest nightly build" comment but overall it is a pretty accurate depiction of what I fear a few web designers around the world actually think.
"Graceful degradation is an added feature"
This is an all-too-common misconception; if you think this is true then you’ve got it all backwards. In all this mess the only thing which is really an "added feature" is the JavaScript itself. The methodology which ensures degradability may be part and parcel with the JavaScript (as it should be!) but it certainly is not an added feature itself.
"If a user disables JavaScript then that user shouldn’t expect functionality, period!"
What you have to understand is that JavaScript and the extent to which it is supported is not always controlled by the user, there may be other reasons why your JavaScript enhancements cannot be experienced by them (look below), so don’t assume that your user’s have knowingly disabled JavaScript or that they even know what JavaScript is.
"Who the hell gives a damn about some paranoid geek running Lynx"
It’s not only the "paranoid geeks" who will have JavaScript disabled, there are many other valid reasons for JavaScript not working. Ignoring these users is selfish, against standards and is definitely a bad business decision!
Reasons for JavaScript being disabled:
- Security reasons. (to protect from XSS attacks and Internet Explorer’s multiple security flaws etc.)
- JavaScript slows down a user’s already slow dialup connection.
- Browser sometimes crashes because of excessive JS, user disables it.
- Popups, onBeforeUnload alerts, disabled right-click etc. – User get’s pissed off and disables JavaScript!
- User is disabled in some way and uses a screen reader such as JAWS, Windows-eyes, SpeakThis etc. (Each having no or limited JavaScript support)
- User is surfing from behind a corporate firewall – the firewall blocks client-side-scripting. .
- Very old browsers don’t support JavaScript.
- Mobile web browsers only have limited support of JavaScript. (‘Opera 4 mobile’ uses a proxy which strips out most JavaScript)
As you can see, it’s not just some people who disable JavaScript from within their browsers, there are a
Ensuring a degradable experience
In order to ensure a degradable experience for your users it’s important to have the right mindset from day one. Graceful degradation itself is really just an end to which the means is usually something called ‘progressive enhancement’, a well-known methodology used in building fualt-tolerant systems.
Progressive enhancement, when applied to the internet, is essentially the process of a website or web application functioning perfectly on modern software while still being able to work correctly on older software. When applying this concept to websites it’s easy to see it’s relation to the three layers of the web; content, presentation and behaviour.
Content is the fundamental backbone of any website; all your content should be visible whatever device or software platform a user is running. The content of your website will typically be found within the HTML, neither of the other two layers should be found within your HTML! Equally, your content should not come from either of the other layers. With the rise of multimedia (video/audio websites) this is becoming an ever unrealistic expectation but it’s good to have principles, right!?
Presentation (usually CSS) is the second layer and, for those browsers that support it, offers a lot of control over the layout and decoration of your content.
Behaviour (usually JavaScript) is the third layer of the web and should be the last thing to build within a project cycle. Only use JavaScript to enhance the user’s experience. By making a site’s functionality dependent on JavaScript you’re immediately cutting out a percentage of users.
Once you have your content in place you can work on the presentation of that content, and then after that you can start adding JavaScript enhancements.
Please note: I am talking about websites in this post, not web applications. Web Applications (many of which require JavaScript to operate) and the principles by which they’re built really have more in common with desktop applications than real websites. That said, it would be great if web application developers took a couple of the above points seriously!
Not only JavaScript…
The topic of this post does not only apply to JavaScript. Your content (HTML) and presentation (CSS) layers must also degrade in the same way. Nowadays most of the focus is on JavaScript because that happens to be the layer which most people screw up so frequently!
Thanks for reading! Please share your thoughts with me on Twitter. Have a great day!
Hi James,
The line between web sites and web applications has blurred significantly over the past few years. In 2004 I would have agreed strongly with you. But the power of Javascript is undeniable, and not only web applications but Web servers and the communication of content nowadays is relying on functioning Javascript.
Regarding your reasons for users consciously disabling Javascript, or corporations or firewalls doing so, I’d be curious if there are any mainstream mass-market Web sites (Amazon, CNN, etc) nowadays that don’t rely on the use of Javascript. Every year the additional cost of making the functional Web site backwards-compatible is going to be less tolerable. Someday these mainstream Web sites shouldn’t have to worry about users that use very old browsers.
Your points about screen readers and mobile devices are valid, but often the easier path is to build an alternative site that caters to those device capabilities. As good as the iPhone is in rendering regular Web sites, companies are CHOOSING to spend money to build iPhone-specific sites that better suit the usability principles that device encourages.
I strongly agree with you, for a few more years. Even if I don’t think we should feel so bad for people disabling JavaScript, the fact that we are in a transition toward a mobile internet is not negligible. Until all browsers (including mobile ones) have standardized the way they render JavaScript (or support it!), I don’t think we should rely on it.
That’s frustrating when I want to check something with my phone (Windows Mobile) and the site expects JavaScript for basic functionality. It’s already a lot better with the latest Opera, but it’s still not like we are browsing with a desktop…
@Carlos, although the line of distinction between web applications and websites may be faded the principles on which each is built has remained largely separated. Web applications were not born from websites but of the ‘dream’ that desktop applications could be run online. I don’t know of any massive sites which don’t have some decent fallbacks in place. Obviously in certain situations there is simply no degradable option – e.g. on CNN, in the video section…
As long as software is advancing, backwards compatibility will be an issue! What is new now will be old in a year and users who are still using what is currently considered new will have to be catered for.
I purposely didn’t mention the iPhone in my post because it really is a whole other argument. Every time some big-shot company brings out a new product we have to (with no warning) jump on the bandwagon and develop for it…
@Antione, the problem is that these technologies won’t be standardized across platforms/software for quite a while, well, this is what I fear anyway…
Mobile phones are absolute hell to develop for. Constant testing is required which really makes it take ages, plus what renders correctly on one device will render differently on another, even if they’re both using the same browser! Opera mobile is great but it’s still a compromise – Opera proxys most of the data to strip out unnecessary stuff (they say it saves their customers bandwidth and money). Like I said to Carlos, unfortunately, as long as software and technology advances there will always be a need to be backwards compatible.
One of the most common reasons (that I’ve encountered A lot) for JavaScript being disabled:
University, Library, Company / Corporate, School computers and networks were system administrators have disabled JavaScript, or where it has limited functionality (ajax and cookies disabled), and keep running IE6, because it works for them, they haven’t had any problems with it, and they’re lazy, and there’s no budget for upgrading, so why would they care.
It’s not about the 0.1% that intentionally turns off JavaScript. Ensuring backwards compatibility (i.e graceful degradation) for a web application isn’t hard or even time consuming if you design it the right way, and have the proper knowledge on how to do so.
Conclusion: As long as all basic content and functionality is accessible, that is OK to me, oh and don’t get me wrong. I love JavaScript 🙂
Daniel, exactly! Graceful degradation is incredibly easy if you’re doing it from day one. The problem is that many people see it as a last-minute optimization when it only really works if it’s part of the design.
I will point out that in large web projects (500k and more), when the client expects a highly interactive site that impresses their consumer audience, and designers present ideas that satisfy those wishes, the cost of building to that expectation AND having it gracefully degrade is quite large. Large enough for a client to make the decision that they won’t pay for users who aren’t browsing with javascript.
And while that’s true. I certainly wish the reality was otherwise because I agree that it’s a web developers responsibility to build intelligently. Given a rich enough UI, the cost is just too prohibitive.
I tend to agree somewhat with Carlos. If we’re talking “websites”, then yes, by all means, degrading gracefully is easy enough (eg. Regular href that is overriden in JS to pull AJAX content). However, some functionality simply doesn’t degrade well.
However, I will agree with “Some Idiot” here and say, whatever you do, the client needs to pay for it. There is also some burden on the web developer to educate their clients.
The whole iPhone topic raises an interesting point: When do we degrade and when do we build a separate version? Sometimes the latter is far simpler.
@Paul,
“The cost of building to that expectation AND having it gracefully degrade is quite large. Large enough for a client to make the decision that they won’t pay for users who aren’t browsing with javascript.”
What does the client know? You’re the expert and so you know what’s important and what isn’t. I know it’s different with large firms and agencies but I would never lower my standards because of one ignorant client. What I’m saying is, there are some things the client shouldn’t be told about, because if they are told then they’re likely to make the wrong decision.
@Kevin,
“However, some functionality simply doesn’t degrade well.”
Please specify…
“whatever you do, the client needs to pay for it”
This is true in principle but it doesn’t negate the importance of graceful degradation.
I’m just saying, your requirements may cause you to depend heavily on Javascript (Complex navigational trees, menus etc.). Sometimes your requirements may simply be graphical in nature.
All I’m saying is that everything isn’t always cut and dry. It’s not always as easy as replacing onClick() with a $(a).click().
Please don’t misunderstand me, but degrading isn’t always the answer. A totally new version is sometimes needed. Degrading just may not fit the layout that is required.
@James
“What does the client know? You’re the expert and so you know what’s important and what isn’t.”
I hear you James and what you’re saying probably holds true for small to possibly medium sized projects but when you’re working on projects in excess of 500k the client has no choice but to get involved. If the investment is large, the client will need to know where and how each dollar is being spent as well as the rationale behind your recommendations.
“What I’m saying is, there are some things the client shouldn’t be told about, because if they are told then they’re likely to make the wrong decision.”
It’s not uncommon practice for projects with large investments to bring in expert consultants for the duration of the project, so not giving full disclosure usually isn’t an option.
I guess what I’m saying is that what you’re saying is true… just not for every project.