When do you kill off support for IE6? As designers and coders, most of us probably wish we could have done it two or three years ago (or more). On your own personal sites, or corporate type sites, you may have already cut the cord (many already have). In reality, for many campuses ending support for IE6 on our web sites is an endlessly challenging, mine laden road. Whether it’s legacy software that doesn’t work right in IE7+, or old hardware/software that simply hasn’t been updated, or the failure of IT or other offices that you may be tied to in taking an official stance, there can be many factors holding you back.
This is also quite timely, since Microsoft just announced pushing out IE8 as a critical update for Windows which will undoubtedly eat away further at the IE6 audience (don’t forget to set the x-ua-compatible meta tag if you need it). The topic has also been picked up as a discussion at the UWebD Ning social network. The general opinion seems to be that people want to move on, but feel they can’t.
The problem is a very basic, simple one. IE6 sucks. Period. And there’s nothing you can (or would) do to convince me otherwise. Listen, IE6 came out EIGHT years ago. What other single piece of software (the whole of XP excluded) do you currently use that is that old? Unless it’s a very specific, specialized application, I suspect the examples are few and far between. According to security research firm Secunia, the ActiveX system alone in IE6 at one point had more than 350 vulnerabilities. From there you get into its craptastical (that’s the technical term) support for CSS, useless PNG capabilities, and you just keep going downhill from there.
It takes time and resources to account for all of IE6′s quirks, two things we consistently have less and less of. Whether you code around them, or hack for them, dealing with IE6 is simply too much trouble for an ever decreasing payout. So why bother? We’ll have to say no at some point, and even if it means cutting off 20% of your visitors, I would argue that it might just be time to drag them kicking and screaming into the future. But that’s mean, and I’ve never been one to shy away from rattling the cages once in a while. So, what’s the right market share at which to cut off support, and how do you address it?
More Than Analytics
Deciding to move on and tell people you’re not supporting IE6 is a very complicated issue, and can’t solely be based on analytics. Not that they don’t help make a case though. Using Google Analytics, or any one of many other solutions out there, you can get a feel for how many users are hitting you with IE6. Currently at PSU, we have about 11% of users still on IE6. I would safely say any total amount under 5% translates to a safe cutoff under nearly any circumstance (that is my opinion on the matter). More than that, and you’ll probably find you need additional justification.
The thing is that maybe a lot of those 11% are on campus users who have very specific web app needs related to the site. Before going whole hog, make sure you do some evaluation on the impact not supporting IE6 will have among visitors. If you’re confident that visitors aren’t married to some critical need, then remember that you can always frame your numbers with a different point of reference to justify ending support. It’s not about lying, and you don’t have to fake numbers, it’s just about showing how your numbers translate to justify ending support. Some ideas might be to show how far usage has dropped over six months, or change in comparison to newer versions or other browsers. Or, if you’ve identified a need for some users with IE6, perhaps you grandfather in support for that feature, while no longer advancing anything else. And be sure to look into IE6 usage on popular landing pages one level below your home page. You want to weed out some of the people who might just be bouncing off your home page on a machine where it’s just default. You might actually find your “real” level of IE6 usage on your site is much lower than it appears at first glance.
Solving Through Progressing Enhancement
One solution may be that you can’t end support for IE6, but that doesn’t mean you have to give them everything, either. This is sort of the passive aggressive approach to “we don’t not support IE6, but we can’t officially drop it, either.” We use this technique in several places on pittstate.edu. Using our CMS, we detect the user agent for the browser, and serve up different code based on that, eliminating things like fancy popups, tools, and resources. We don’t restrict access to data at all, and we try to ensure the base layout stays consistent. It’s just that there’s no whiz-bang in IE6, and some of the coolest stuff is, in effect, crippled.
You can also use similar techniques, or conditional comments to include custom CSS or bug fixes that handle just IE6, but are ignored by other browsers (common for things like the ubiquitous ). This requires more work, as you have to take the time to cater custom stuff to IE6, which in my opinion is the opposite of what we should be doing. IE6 deserves less attention, not more, so I prefer true progressive enhancement, where IE6 just doesn’t get the best new stuff.
It’s Not About Cutting Off
Sometimes, when you tell people you’re ending IE6 support, it gives this impression that the site will simply not work in the browser anymore. It’s very important that you educate people so they know the site on the whole won’t break (assuming you properly progressively enhance), since that’s simply not true. But, if they’re still using IE6, it’s possible that they don’t realize what it means to not support their browser. The real case is that they’ll just miss out on features, and you won’t plan on fixing display and layout bugs. No, they won’t be cut off, it just won’t be perfect or super-duper-fancy.
On the chance that your web site does break completely in IE6, I would say that you have bigger problems on hand. Using proper design and coding techniques, at least the basic elements of your site should never have issues working.
How We Did It
I work in a one man web office that supports our 26,000 page site, and it made it very easy for me to simply say that I cannot take the time to deal with IE6. I’ve gotten dirty looks, yes. I’ve gotten an angryish e-mail or two, sure. But we just deal with it and move ahead. It’s a resource issue, and I simply don’t have the time to stop and test every little thing in it and deal with its quirks and flaws for 11% of our audience (A number that’s fallen by 50% the past year. See, aren’t analytics fun!). Usually, these are elements of progressive enhancement, and I do some of the browser detection I mentioned earlier and have the page modify itself accordingly (easy with our CMS) to not serve enhanced code to IE6. I can’t care, there are just too many bigger fish to fry.
When users complain, I tell them to get Firefox. If that doesn’t work, I politely explain that it’s not a reasonable demand to support such an old piece of software now given our resources, and if they want it to change, feel free to write our VP asking that more manpower be added to the office. And then go get Firefox. Ultimately, people generally understand the situation.
The main key, as is frequently the case, is education. If you take the time to explain why IE6 shouldn’t be supported, and do it in simple, straightforward terms, more often than not you’ll find the buy in you need. People can be surprisingly receptive when you tell them about the security risks in IE6, and how it holds back innovation. Successful web sites don’t come from catering to the lowest common denominator. If you can back your position up with low usage numbers, that obviously helps as well. Don’t be afraid to compromise, too. Progressive enhancement is a great way to make everyone happy that won’t cause too much undo burden on your workload.
Hopefully, this can help you in making your move to drop support, or at least limit it so that you’re free to work on truly developing your site. If you’ve had particular success using a strategy I didn’t mention, or would like to expand on a tactic you used, share below in the comments.