User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
Say your app works well on modern browsers, but has features that don't work so well on older browsers (e.g. IE). How do you handle this?
I see three possibilities:
What is a good way to handle this?
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.
You should add at least one extra possibility to your list of three:
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.
You may also want to take a look at Yahoo's Graded Browser Support, which I believe is updated regularly. Definitely have a look at the conclusion, with a great quote related to your own options.
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.
Good news: IE 6 and 7 are going to a thing of the past! They are rolling out automatic updates to kill off these versions, unless a you specifically decide to opt out.
This should solve a majority of compatibility issues.
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.
