Progressive enhancement is the preferred method; users generally don't bother to change their browsers for one app. If they can't use the site at all you'll have to look at what % of potential users you're losing to consider other options.
–
Ben Brocka♦Dec 17 '11 at 21:16

5 Answers
5

Graceful degradation is the way to go, but you need to analyse your user base and determine how far you need to go based on the numbers.

If only 2% of your users are still on IE6 then it's probably not worth your while implementing the features needed to get the site working (after a fashion) for them and you could get away with just displaying a page which lists the supported browsers.

However, if 20% of your users still use IE6 then that's a different matter. You need to spend more time and effort getting the site to work for them as they are a significant proportion of your market. You should offer encouragement to them to upgrade (assuming they're not locked to IE6 of course) by providing links to the latest download pages for more "modern" browsers.

Unless you specify that you want to keep it, IE 6 will be old news in a matter of a couple weeks. See my answer below.
–
Matt RockwellDec 19 '11 at 16:32

@MattRockwell - You can bet that some corporations will opt out of this, especially if they have in house intranet applications running on IE that they haven't updated.
–
ChrisFDec 19 '11 at 17:16

If some corporations decide to opt out of this update, they will do so with an understanding that they will get a less than optimal, or ever potentially broken web experience outside of their "company bubble."
–
Matt RockwellDec 20 '11 at 18:02

Now, what you consider "older" is up to you of course. Personally, I consider IE7/IE8 "older" and IE6 "ancient" :). However, the final choice depends on your intended audience. From your question it's not clear what the audience will be.

As a more direct answer to the question, if the above (full support) is not an option, I'd think graceful degradation is the best way to handle things, having disabling options (or -eeek- even the entire site) for older browsers as a last resort.

Thanks. You're right in that you should strive to support as many browsers as possible. What I'm referring to is a situation where a feature cannot be replicated in older browsers for one reason or another. The quote was discussing websites, which mainly serve to display information. In that case, for older browsers a different way of displaying the information is the solution. For applications, I'm referring to actual functions not working in older browsers, or working extremely sluggishly (e.g. multi DOM element fades).
–
MirovDec 17 '11 at 19:37

Ah fair 'nuff. Added a short bit to my answer (on graceful degradation) to make it more into an "answer", although I unfortunately have no new references to add next to the already provided Yahoo GDS.
–
JeroenDec 17 '11 at 19:47

That's actually a really good page. I've never read it, but will be sure to. Thanks
–
MirovDec 17 '11 at 19:58

If some corporations decide to opt out of this update, they will do so with an understanding that they will get a less than optimal, or ever potentially broken web experience outside of their "company bubble."

There is no 'good' way, really. They all have drawbacks. There are more pragmatic options than others, of course. In general, methods to consider individually or in part:

graceful degradation (Site can still mostly function on older browsers, though some features may break and layout may not be as nice)

require certain browsers for entry (can't use the site unless you upgrade)

fork the presentation layer (create a separate, stripped down acceptable version for the legacy browsers)

The first is preferred by most users, as they have to do nothing on their end. This can obviously be a drawback though, if the intent of the application is to push forward with newer technologies.

The second is preferred by most development teams, as they can focus on the standards and newer technologies without the burden of endless bug testing and hacking of the older technologies. In general, it can make dev and maintenance a lot easier, quicker and cheaper for the organization.

The 3rd is sometimes a useful option when option 1 becomes too complex but option 2 isn't viable. This allows the dev teams to still maintain a more pristine code base for the modern users, with a separate altered code base for legacy. It does split dev efforts, of course, but can sometimes be less time and effort than combining the code base into one monolithic mess.

I always think that this is far too late to be asking this question. At the start of a project - or early on at least - you should ask the question "what browsers does this need to be supported on?". And associated with this is "what should we do if the browser is not supported?". The answers should - for a public site - take some time to get, because they involve ascertaining the likely user base, what browsers are in use by them, and in what proportions.

Once you have this, you can make your decisions about how you build your app, and how you provide graceful degradation. Or not. For example, if your app is an internal company app, then graceful degradation may not be an issue - the chances are that the browsers available will be defined. OTOH, if you are writing for a public site, with 1-2% on IE6 ( for example ) then graceful degradation for unsupported features is probably the right way to go, as long as you can do it easily.

In other words, there are no clear answers, but asking early makes more options available. Asking late - when the app is up and working - makes some of your options far more expensive, and so may make some options impractical.