The status quo with regard to how users receive browser upgrades has changed dramatically in the last few years – modern browsers are now evergreen, they are never significantly out of date with regard to standards support (generally a matter of weeks), and ones that are not (generally mobile) are statistically never more than a year or so back. This means that in 2013 we can write software using standards and APIs created in, say, 2012 instead of 2000 – but by and large we don’t – and that is hurting us all.
It’s not about a specific version…
Historically, a large number of users of got their browser upgraded only as a side-effect of purchasing a new computer. Internet Explorer 6 was released toward the end of 2001 – well over a decade ago – pre-9/11/2001. It wasn’t fully compliant with the standards of the day – and for five years, nothing much happened in IE land, so anyone who bought a new machine until about 2007 was still getting IE6 for the first time. This meant that until very recently many businesses and Web authors still supported IE6 – and it was only with active campaigning that we were finally able to put a nail in that coffin.
So, now we’re all good – right? Wrong.
A great number of companies have followed their traditional policies and took this to mean that they must now offer support back to IE7, some have even jumped to IE8 which seems like a quantum leap in version progress, but… If you write Web sites or run a company that does, this is now hurting us all: it’s time to stop.
The problem is in the gaps not the versions…
Let me add some data and visuals to put this into perspective… If you were to create a giant table of features/abilities in the Web Platform today in most evergreen and the vast majority of mobile browsers and compare them with the abilities of non-evergreen IE browsers, remove the features that have been in there for more than a decade and then zoom WAY out, you would see something like the image here (and then you’d have a lot of scrolling to do). Rows represent features, the green columns on the left represent evergreen browsers and the red columns on the right represent IE10, 9, 8, 7, 6 (in that order).
If you want the actual dirty details and to see just how long my (incomplete) list of features really is, you can take a look at:
- this table which uses data from caniuse.com and shows that 109 out of 134 features that they track are supported in most evergreen browsers, but pretty much none of them before IE9
- this table which uses data from webbrowsercompatability.com and shows 460 of a total 1403 properties/features that they are testing for are available in most evergreen browsers but, again, pretty much none of them before IE9.
Now, if you really look at the data, both are slightly flawed, but the vast majority of the picture is crystal clear…
- There are an ever increasing number of gaps in ability between evergreen browsers and old IE. More importantly is where the gaps are: Many are some of the most powerful and important sorts of features to come to the Web in a really long time.
- We can’t wait years for these features because meanwhile the user/business expectations for features made possible by these APIs keep increasing.
- Solutions/workarounds for missing features are non-standard. They start getting bulky as you increase their number, they are less maintainable, require more code and testing (anecdotally, I have worked on a few small projects that spent almost as much time working out cross browser problems as the entire rest of the project).
How it hurts us all…
Directly, this is hurting you or your company because it means you spend a significant amount of time and money developing for and supporting browsers which are so far behind the curve – and the work you are doing is already out of date.
What’s more though, by supporting them you are effectively enabling these users to continue inadvertently bad behavior which is free to fix – and the longer they stay around, the more other companies follow suit. You are creating a self-fulfilling prophecy: My users won’t upgrade.
What can we do?
Luckily, this is actually a really solvable problem… All we have to do is get users to upgrade their silly browsers – and it’s free.
I propose that we set two dates as a community and do the following:
- Try to get cooperation from major sites like we did for SOPA and make sections of the interwebs go semi-dark for those users (like we did for SOPA) on the first date – while we tell them about the second date (next bullet)
- Upon the second date, we collectively stop serving them content and start serving them up 403’s (I’d propose July 4th – Independence Day in the US, but that doesn’t internationalize well).
I think there are a very small number of users who still don’t have high speed access, for those people, you could recommend them to Best-Buy where they can pick up a copy of Google Chrome on CD. If you have other ideas, want to help coordinate a date, want to submit scripts that people can use to black out their site or even want to share another way that users can get disks by mail, leave a comment.
Clarification: I am not suggesting that the entire Web start serving 403 responses to anyone with an older version of IE here – I am suggesting that sites stop support/new development for those browsers. Eventually, for some classes of sites, this will mean that their site is actually unusable (try using twitter or google plus with IE4, I haven’t, but I bet you won’t get far) – if that is the case, a 403 page asking users to upgrade is an entirely appropriate response which is actually better than a broken user experience. This is about helping users to help us all.
Our support of non-evergreen browsers is killing us all, let’s work together to spread the word and fix that pro-actively, as a community.
Thanks to Paul Irish and Cody Lindey for helping to hook me up with some data.
briankardell
I agree that older browsers do take more time to support. However, not all of us have the luxury of not supporting them. I work for an ecommerce website, and traffic is often measured in dollars. So, we could say for example that 10% or our revenue comes from IE8 users. Depending on the total revenue, of course, this could be a rather large number. If the total revenue is $2 million, then IE8 revenue is $200 thousand.
If the IE8 user comes to our site and tries to buy something, but they can’t because we tell them their browser is out of date, they are more likely to go to a different site to make the purchase rather than install a new browser. My company is unwilling to throw away $200 thousand.
But what does it cost to support IE8? Is it even close to the amount of revenue we get from those users? I don’t actually know, however I believe right now the cost is well below the revenue we get.
I would love to drop support for IE8, but unfortunately I don’t have that luxury.
It definitely costs you money to support IE8 in terms of more code, lost opportunity, etc. and it is significant. At some point your company will stop supporting IE8, the question is when. I am calling for a campaign where we work together to move that date forward. Even if your company merely participated in the ‘sopa-like’ blackout day (if you are unfamiliar with or don’t recall, have a look at the link in the article) noting that _many_ sites will start sending 403’s, that would help. Short of that, there are still things you can do to help: pass it along – others will do it. Use a script like the one available from http://browser-update.org/ which is akin to UK’s cookie notification – it’s unobtrusive (and too easily ignored IMO so not as effective), but at least it is something.
A 403? Seriously?
To me this is analogous to saying: I want the Internet to be available everywhere. Except China. Oh, and Africa. Oh, and let’s also exclude poor people.
Remember when people used to talk about how important it was to have universal access to information?
Casual follow-up to apologize for oversnarkiness 🙂
Access to information is important, but it is a simple fact that many of the sites/apps that we are talking about who need those features and APIs won’t be accessible to someone with old browsers already… Try surfing the Web with IE4, or worse something that uses a terminal interface. If you can’t access the information in the site, a 403 is actually probably the correct response code, sent along with ways for them to address. Sites will eventually drop support for browsers, we just want to give it a push. Fixing this issue is free and easy and you can have multiple browsers (though not multiple IEs) on the same machine – the rationale for people in China or Africa not to upgrade seems to be mostly because they’ve never got another browser because we don’t ask them to, but I could be wrong. Still, all I am looking for is a campaign to move the ball forward. If you’d prefer to create a campaign for some infinite backcompat strategy, you are free to do so and I’d be interested in how you accomplish that and your rationale as to why it is necessary.
I actually love your desire to push the web forward, but you shouldn’t block anyone’s access. Give them a polite warning and let them browse a stripped down version. Even a broken version is preferable to a 403.
Agree with Zach. Providing a basic experience to any old browser that doesn’t fall in your general audience should require little or no effort or testing at all. The hard part is ensuring that your usage of new features on top of that HTML doesn’t break the experience that would have otherwise worked. Broadly qualifying all CSS and JS enhancements can go a long way towards simplifying this goal. For example, you might choose to qualify all of your visual and behavioral enhancements based on media query support, or querySelectorAll. Including IE8+ in the latter example might be a fair line for your enhanced experience. Depends on the site.
I agree we should continually evaluate where to draw the line for enhanced support of old browsers, and always design for the best features and experiences, but supporting browsers that fall outside that criteria can cost very little (nothing even) when enhancements are qualified. This approach not only broadens access, but simplifies testing and QA – users and developers rejoice.
Browser support need not be treated as a boolean. We have the tools to make more granular and inclusive decisions than that.
Thanks for moving the discussion back to here Scott. I don’t think that I am suggesting anything that conflicts with what you are saying – I added a clarification toward the end of the post. By all means, if you can do progressive enhancement or serve up degraded, but functional and usable content with a budget that you can afford – I fully support doing that. Instead I am merely stating that no one really thinks that their site is infinitely backward compatible or that anyone would get very far with sites like Facebook, Google+ or Gmail or Twitter using Internet Explorer 3.2. For many sites, at some point, without a disastrously huge effort or compromise they pass a point where degradation will be “graceful” or “helpful” if you are not actively developing support for that browser – in those cases, it is actually less helpful for those users to get the “degraded” content which is full of errors and is completely unusable… In these cases, I would argue that you do them (and us) a better service at that point to help educate and facilitate an upgrade in any way you can (a nice 403 which can educate and perhaps even give an alternate URI for very scaled back/circa 1998 compatible experience – or even just something they have to pass through like the SOPA blackout page in step 1) – those are all individual business calls. It’s really the idea that is important and I am merely positing that we need to be more active in our move toward evergreen.
Pingback: Regressive Disenfrancishement: Enhance, Fallback or Something else. | briankardell
Nah. I’d much rather see JS frameworks disappear, and much, much more plain old html. None of this new stuff seems to have added anything except loading times; the content quality has not increased a bit.
Take this site for example: it has nothing that could not have been done equally or even better with just plain html. For example the “follow” thingamawhatsit at the bottom is half out of the screen on my browser, which it would for sure not have been if it were plain html. So, I loaded more code, waited the page to render for longer, and it works… worse. Huh? What’s the point?
Pingback: Botas Ugg España
Here we are 6 years later and still having to support even more old browsers. The only way a campaign like this would have worked is if an browser upgrade is available for *old* devices.