The Reality of Progressive Enhancement

---

I’m voting to satisfy the 90%. I’ve always figured that user-experinces on the internet already suck for the 10% that don’t have JavaScript enabled. It’s not going to be a huge shock when my site doesn’t work. Levi

---

Ah, and age old dilemma. I fell the answer is ago old as well—“it depends.” I think for many cases you’re just fine accomodating the 90% and doing what you can for the rest.

Let’s face it, where still in an age when most of the Web is unsable by well over 10% anyway, so when you look at it like that, if you can get 90% your doing a good job. ;0) Keith

---

Just curious here: why does the 10% have Javascript turned off in the first place? Aside from PDA users and the like, what advantage will I gain by turning of Javascript in my browser? Geoffrey

---

It depends. If it’s a commercial web application, then it’s rational to say goodbye to 10% of your potential customers if you’ll get more actual customers that way. If it’s going to serve existing customers or general public, then all-around inclusiveness is probably a rather important goal.

Anyway, I wouldn’t trust JavaScript to be ubiquitious just yet. An overly paranoid system administrator, a security hole or a nasty, crashing browser bug may make JavaScript temporarily unavailable.

I would seek ways to minimize the cost of providing a non-JavaScript alternative. Making the business logic a separate layer and so on. Also, the non-JavaScript alternative may not need any polish, if it’s just for special circumstances. Aapo Laitinen

---

I vote for the 10% in general. For me Javascript is sugar, but not vital. This whole AJAX Buzz is dangerous in my eyes, because many web principles (Back button, Bookmarking) can easily be forgotten during the hype.

I think there is a deeper conflict with this. Are we satisfied with the web as it works? Are stateless GET requests the way, we want our web to behave? Or should we change this for the sake of unexperienced users? beza1e1

---

I’m interested in hearing more about “places where JavaScript can be used to make an interface amazingly easy to use”. Can you give some examples please? wendy

---

I think that the user experience being less than optimal and not working at all are very different beasts. Websites should work for everyone – period. We have the technology to do this.

And of course, that 10% may include blind/assistive-technology users. When things like “yellow fade” occur to notify you of a change to the page, assistive browsers don’t notify them (to the best of my knowledge) of the change to the screen. So even if they have JS turned on, they still lose.

Also, beza1e1 is on the money as far as bookmarking and site navigation go. I once heard a statistic that some large percentage (like.. 30%) of all “clicks” on the Internet are the Back button. So if you break that, you break convention.

BUT (bear with me), Keith is also right with “it depends”. Basecamp is a slightly bad example, because it’s largely aimed at professional web firms, who are very likely to have JS turned on so they can get all the bells ‘n whistles. So Basecamp has nailed its target audience. We need to make similar considerations with regards to our sites. Brad Wright

---

Also – sorry – I don’t think that we can make excuses based on the previous state of the web. I mean, we’re supposed to know better now, right? Brad Wright

---

For me, progressive enhancement hasn’t been so much about people with JavaScript disabled as making sure the weird bits in the corners work:

* Google indexability
* Back button
* Bookmarking / open-in-new-tab

I mean, disabling JavaScript is kind of like poking your eyes out – sure a well-designed site can still be surfed through a screen reader, but wouldn’t you rather keep your eyes?

These other things, in my mind the “real concerns”, are usability features for the 90%. As such, they are more important than one might at first suppose.

I generally solve these things by starting with “semantic tags:” all actions/state-changes start as tags that go to a page with that state. Some will be anchor links (ones with a #) and some will be seperate pages.

In my experience, it’s rare that you can’t provide a nice javascript-based UI feature and a non-javascript backup – it’s more a case of the amount of work it will take to support dual operation. Sam

---

I say definitely go for making things easier for 90% of visitors. You will be making more people happy if you do and those 10% will be pushed more and more to join the other 90% (in this case, by enabling Javascript).

Then again, in some cases the decision may be very tough, for example when you are building a shopping cart. If a significant portion of visitors do not have Javascript enabled, a company may sell less products on the website by a shopping cart that is dependant on Javascript. On the other hand, if the Javascript is applied well, the shopping process may become more comfortable for the 90% of the users, who will then buy more.

Basically I think it depends – in my example above, it matters what the quality of the enhancement is. If the enhancement is as such that it makes up for the loss of sales by disallowing access to the 10%, it may be a good choice. Peter Akkies

---

While I philosophically feel that the web should be accessible to everyone I’m also a realist and know that it never will be. So I guess its a judgement call for you as a developer there on economics and business as well as your userbase. Maybe in some cases having a simple alternative could be the right move while in others not. But then its late here and I’ve got severe burnout so it mightn’t make much sense even to me tomorrow. Valid question you posed. nortypig

---

i think the real question is not “sacrifice 10% for the 90%” but:
can we make the same in html standard based code ? if yes, i ban JS, coding in JS shows up to much compatibility problem, and enhancement problem if not well code.
actual technology can do very well interface with non JS, i mean with server-based program like php for exemple, so, of course javascript can easily programming and usability, but we can do something different, we just have to know it.
my answer is : it depends :)
but i will never make a sacrifice of 10% for the mostly commum website, the web growing bigger, and looks like a trash bin now, i hope standard will broke some old technologies like JS bill

---

As long as it degrades nicely, sure, use JavaScript. Otherwise, go for the 100% rather than the 90%. I personally have JavaScript off, simply because I encounter a lot of annoying effects and general eye candy that makes a site harder to use – for me at least.

JavaScript shouldn’t be used for anything vital if it doesn’t degrade in a usable way. Veracon

---

I’m with Kieth’s response: It Depends™.

As mentioned, target audience is a huge factor. Is it for an Intranet where you can pretty much guarantee a certain environment? Go for it. Is it for a web application? Go for it. Is it just for a really fancy web site? Hmmm, maybe think of another approach.

Possibly it’s a case of making it easy to use for the 90% but cumbersome for the 10%. Jonathan Snook

---

I’ve yet to see a comprehensive list of reasons why people turn off JS in the first place. Anyone know of one? I’d feel better about going the extra mile to accomodate these users if I understood exactly why they did not use JS. It would be nice to be able to explain to clients too… Stuart

---

I feel some need to clarify my position. What I’m advocating is thinking very hard about how a non-JavaScript alternative can be provided without too much effort and without it being a burden for the JavaScript version.

I’m currently involved in a web application project that has several screens taking heavy advantage of JS. One of the screens requires JS to edit stuff. The reason we accepted this is that the screen is needed by personnel only, though several times a day by them. Efficiency trumped compatibility.

Another screen we’re just about to start implementing is going to be used by a much larger percentage of users. It’s also going to need much more JS to function well, and the proposed interaction flow can’t really be emulated without it. In order to make the effort of producing both JS and non-JS versions manageable, the server code is going to be written so that the version-specific code will be rather highly abstracted calls to logic shared by them.

It has been a long-term project, so I’ve had quite a lot of time to think about the solution. Also, due to the nature of the product, the backend needs quite a lot of work, and so the effort of maintaining two versions of some parts of the interface doesn’t hurt that much. Your situation may be different and I have no idea what I’d do in such a case.

Anyway, when I first started thinking about the screen, it felt like a great burden to do a non-JS version. However, at some point things clicked in place and I found it wasn’t going to be that bad after all.

Why turn off JavaScript? So far, all versions of Safari crashed on me every couple of days if I didn’t disable JS. However, I wasn’t willing to adopt Firefox as my primary browser since I prefer the fluid and Mac-native interface of Safari. I’m now trying if Safari 2.0.1 finally solves the problem, who knows, especially since the release notes of version 2.0 already claimed improved stability. Aapo Laitinen

---

Personally, I don’t usually use JS because it tends to not work correctly/at all for some people because they use a different browser, or have shut it off. I think there is always a way around the use of JS, don’t say you need it for functionality, because there are plenty of other methods to probably give you the same effect. But then you have to remember it will probably never be possible to make a site work with EVERY user. Tekashi

---

Garrett – your implicit assumption seems to be that there are some user interfaces where the same “style” of interaction – the content and order of the screens – cannot be replicated, albeit at a slower pace, without JavaScript.

I challenge that assumption.

Build your interactive markup out of s and s, using JavaScript to mung this however you need.

Of course, one can’t give a detailed solution without a detailed problem, and you’re being awfully coy about what exactly you’re trying to do (presumably for confidentiality reasons), so we’re left at an impasse. Sam Minnée

---

Mmm, “s and s” had some tags next to it before.

It was meant to say A tags and INPUT TYPE=”SUBMIT” tags Sam

---

In response to “It Depends™”...

Here’s what I think it depends on:

For a regular ol’ website, there are few instances where requiring javascript makes sense. This is where you want to reach 100% of your audience.

On the other hand, in a web application, you can target your audience and set certain software requirements (minimum IE 6, for example). You can provide some wonderful usability enhancements with AJAX. For example, when a user selects a checkbox you can have AJAX submit the result of checking just that box, instead of having to submit the whole form and reload the whole page. AJAX is a great way to reorder lists, and it provides a snazzy way to submit comments to a blog entry, á la Typo. Also, using AJAX to process dangerous actions (like delete), can protect against accidents caused by Google Web Accelerator (See jlaine.net article) and can provide comment-spam protection because most spam spiders don’t do javascript (yet).

Much of AJAX is still a bit too rough for some things though. Drag and drop still has a way to go before it’s really usable. And anybody who uses AJAX for navigation should have their passwords taken away.

Thanks for the great article Garrett. Ryan Heneise

---

One more thing…

I also think that websites should degrade gracefully. For example, 37signals explicitly says that they don’t support IE Mac. But go to Basecamp with that browser, and you can still use most of Basecamp. They don’t block you, or give you any nasty warnings. But there are just a few things that you can’t do, like reorder lists. That’s graceful degradation, and it’s essential for any accessible web app. Ryan Heneise

---

Why do you assume javascript enabled and non-enabled interfaces have to be extactly the same?

Are users really going to change their javascript setting on a page by page basis?

Does it matter that your users experience is different than your design intention? (Which invariably it will be given the differences between devices and browsers, regardless of how much testing you do).

How does the semantic web fit into a javascript driven web UI?

I think you are missing the point of progressive enhancement with the same kind of thinking that tries to produce pixel perfect print designs for the web.

Plus, the 10% that you are not catering for are most likely those who benefit the most from a simple well thought out design that works with the browser and not against it. Terrence Wood

---

If one types “this site requires javascript” into Google at this writing, there are 17,500,000 hits returned. Many of the initial results are of those sites where the Google bots hit obligatory notification screens, telling users they need to have javascript on to use their website and providing instructions. I don’t think this answers the question one way or another. However, it does shed light on how many large web productions (of places like, for example, Blockbuster) are requiring it, and so therefore, how acceptable it is to nudge the non-conformist 10 percent or turn them away. That being said, yes one definetely needs to ask at the outset whether or not a specific site’s objectives can tolerate a 10 percent friction rate. Most sites I’ve done can but it may not be the same for what another poster here imagines could be specialized applications or audiences.

As to WHO is turning off javascript, it would only be my personal opinion beyond the obvious group of people with technical apparatus that either doesn’t come with it in the first place (say a PDA browser), or some other such limitation. As a purely demographic question my “impression” is that it’s people with overly simplistic yet exaggerated ideas about how to protect themselves from adware and other malicious content, yet little knowledge or understanding of the less obtrusive tools that might do the same thing for less obfuscation of their experience. There are people like that—the same people who won’t accept any cookies because of some article they read on an airplane in 1998 about how cookies were super evil. They never read anything else and aren’t techie enough to trust the middle ground options, so they wind up clicking to accept cookies selectively with every single website or avoiding websites that use them outright (which of course, is just about all of them nowadays). If you could peel back and expose those who opt to go on harrassing their own web experience that way, I bet a fair portion of them would be of this ilk. And as another poster here alluded, they’d be problem users for one reason or another anyway.

Dave

David Pinero

---

A very good question.

I’ve been reading a lot today on JavaScript vs. accessibility, and one thing I find interesting is that a lot of people who say that accessibility—and that last 10% of your audience—are important point to PDA users and the like.

I’ve always leaned towards providing universal accessibility in theory (and probably occasionally fall short in practice); I don’t think the recent popularity of AJAX changes that picture. As the web expands, the core becomes richer—I love using Basecamp, and my clients do, too. But at the same time, the fringe keeps expanding. The web will continue to be accessed via an ever-increasing range of devices, and their capabilities are going to range all over the map more and more in the future.

This argument trumps my decreasing concern for people who turn off JavaScript in their browsers. I agree that at some point that audience will be relatively small. But the expanding ubiquity of the web means, to me, that examining the needs of “the extra 10%” will likely provide the keys to providing robust content and applications which will satisfy all.

Jeremy Carlson

---

I develope web sites for a recruitment company, the regulations regarding accessibility are extremely strict in this market place due to diversity and disability issues, I have to ensure that my sites are viewable by people using text only browsers, so as you can imagine I have little in the way of any creative freedom. I find it a complete annoyance that I can’t use as much javascript as I would like, it’s an absolutely essential part of developing any good looking, funcational and user-friendly website.

If I had the choice I would favor the 90%, javascript posses a minumum security risk, and has a minimal impact on system performance, if disabled then I’m sorry but you belong with Oliver Cromwell, sitting in a dark room with black clothes reading from the good book, get with the times!

samuel dorne

---

I’m confused. The whole point of Progressive Enhancement is to take that gimp version you created to suit the 10%, apply JavaScript/CSS to it, and make it better for the 90% who can manage it — not to dumb the whole interface down for everyone.

And people keep saying “as long as it degrades…”. Again, we’re missing the boat, not just the point. You don’t build your site to be dependent on JavaScript. You build it to be used by your baseline audience, then use CSS and unobtrusive JavaScript to make it more useable for those whose browsers support it. Hence the Enhancement part of Progressive Enhancement…and the departure from the old school Graceful Degradation way of thinking.

Jim Miller