Importance of graceful degradation to non-javascript ui

Question

How important is it to gracefully degrade or inversely Progressively Enhance the UI experiance? I mean am I going to lose a LOT of business if I don't? Do you practice this concept? Are there any web 1.0 users still left out there?

Please could you also include if you practice this personally and how much time you've spent relative to the entire project. I realize every project is different, I want to get a sense of how much time as a general rule I should be allocating toward this goal.

EDIT

Firstly, i'm looking for guidance around how much time I should be devoting to making my applications run without javascript.

Secondly, the BS term "web 1.0" (...lol... I don't really like it either) works because we all understand that as the iteration before ajax and all its goodness.

Thirdly, the kind of applications I'm describing are the ones we are all building, not Facebook, not Twitter (unless you're from Facebook or Twitter) but service or utitlity programs like a web calendar, or an online todo list or [INSERT YOUR APP HERE].

Answer 1

This greatly depends on the nature of your aplication and its data. If it's something that you know will be mostly used via computers, than degrading to non-script version UI wouldn't make any obvious benefit (even loss of money because it will take considerable time to develop). You can always tell people to enable javascript in their browsers (similar to what's done here on Stackoverflow - try disabling script and reload the page). Your app/site should display at least something when there's no Javascript posibility.

But if your application has simple data to display and users should access it frequently wherever they are, than degrading to lesser browsers (without script engines like Opera Mini) is a must. Creating a separate UI will less functionality, but keeping everything in that users need to access is probably your best option. UIs like separate iPhone applications for example...

Answer 2

First of all, lets not start using bullshit terms like "web 1.0" and "web 2.0" etc, the fact is the web is forever progressing and new websites are starting to use JavaScript to enhance the user experience.

I don't know anyone that doesn't allow their site to gracefully degrade when JavaScript isn't available, this is for the same reason we use semantic markup so screen readers can correctly interpret our websites for users with visual impairment, and whilst the vast majority of your visitors / users won't fall into these categories it's still important to think about the minority.

Will you lose a LOT of business, well that depends on how successful you are now and how badly your site degrades, chances are you probably won't lose any business... but that should not be the measure yo use to decide whether to gracefully degrade a website.

So unless you can come up with a pretty good reason, you should probably use JavaScript for the purposes of progressive enhancement, don't depend too much on it.

:-)

Answer 3

Progressive enhancement is more a mindset than a particular task that you need to allocate time to. If you're doing it right (and if it's important to you), you should be enhancing the user experience with JavaScript, but not relying on it.

For example, a link will point to a new page, but with JavaScript you'll disable the link and load new content into the current page with Ajax. Start off without JavaScript and progressive enhancement will follow naturally.

Answer 4

JavaScript is disabled by a small proportion of web users, but when you start to talk big volumes this can make a difference. For example for 1 million visitors, you can expect more than 10,000 not to be able to user your site.

You should decide how much lost business is worth the additional cost of having a non-JavaScript version of your site.

You can have an approach where the entire site may not work without JavaScript but that some of the core features are there.

Answer 5

Progressive enhancement is not only smart but it is faster and easier to develop. And at each stage, you almost always have a working fall-back.

Here's what it looks like in a nutshell:

1. Boss/client approves mock ups.

2. We code to valid HTML output. At this point, the boss/client can start using the site. Baring any boss/client changes, the HTML is mostly done. The site is usable at this point.

3. We start tweaking the CSS to make it match the boss/client's graphic expectations. Changes to the HTML are minor, if any.

4. In parallel, JavaScript is added to do non-critical, but nice, things. (Sort tables, Fancy CSS helping, replace some links with AJAX calls, warn the user -- client-side -- of input problems.)
   If any one of these things breaks, the site still works.
   Also, little, or usually no, html changes are needed.