Dropping IE support: a followup.
We recently wrote about dropping IE support, and how in some cases it can be the right choice for customer support as a whole. The article garnered a lot more attention than we had expected. As a result, we've had some great conversations over the last couple of days, and it made sense to publish our responses to some of the most common points that were made.
People have strong feelings about the issue on both sides of the debate. Some because they know how much work and hair-pulling can be involved wrangling IE to behave where Safari, Chrome or Firefox ‘just work'. Others questioned whether developers have the right to lock out a browser, or whether access and support is some kind of online right. Some people called us lazy, anti-open-web, and Mac-hipsters. We don't think we're any of those things.
We've got strong feelings on these issues too, but we're not intransigent. As such, what follows are some clarifications, responses and concessions.
Something we should have made clearer in the original post is that while there are a handful of notable benefits to dropping support for IE, the single driving reason for us was the numbers. IE9+ usage on the site this year (uniques to the front page, to which IE users are not locked out and equally likely to visit) is around 0.61%. The total number of IE9+ users who were actually redirected to the lockout page this year: four. Something like one person a month. IE10 usage was 0%: zero hits from IE10, anywhere. It was clear to us - our users aren't using IE.
As a bootstrapped startup, time is by far our most valuable asset, and everything competes for it: development, testing, marketing, sales, support, breadwinning to pay the bills. The amount of time it takes to consistently verify that we're supporting IE, let alone managing fixes, shims and fallbacks for IE to ensure it, couldn't be justified pragmatically.
A lot of people argued that it would be better to issue a warning to users of IE (and other unsupported browsers), rather than a lockout. A warning page allows these users to check out the app, but doesn't require us to fire up virtual machines with every bit of functionality (both present and future) that we implement. A warning page is a less obtrusive solution. That's a fair point, and we've taken it on board. That's what we intend to do, so thanks for the feedback.
Whether this is an appropriate solution for much older browsers is a good question. What are your thoughts?
Rey Bango, a front end developer for Microsoft, took the time to test Paydirt in IE versions 9 and 10, and found that in those versions of the browser "[Paydirt] JUST WORKS!" We really appreciated that he skipped the slander and went straight for his own research, and we've been having a productive conversation with him since.
And he's mostly right. When I run Paydirt through IE9 I find more or less the same thing. There were one or two small rendering glitches, and our use of the History API is unsupported, but on the whole the site functions pretty well. Within the next few weeks we'll be rolling out functionality utilizing websockets, and that'll be problematic in all GA versions of IE. Without shimming, fallbacks, thorough and regular testing, and a willingness to replicate and fix bugs specific to IE, we couldn't confidently claim to be supporting it. That's why we don't - not for 0.61%.
We're glad that IE9 is as much of an improvement on IE8 as it is, and we're stoked that IE10 looks like it's going to be a very competitive browser. Stiff competition is what's raised the bar so high for all browsers in recent years. Hell, we hope it's the best browser in the world. If it is, and our customers use it, there's nothing stopping us from fully supporting it.
The point isn't that IE is evil and it's users should be punished and excluded. It's that in an early stage startup being ruthlessly metrics driven is critical, and might even drive you to do what seems unthinkable according to the usual conventions.