Internet Explorer and the legacy that won’t go away just yet

This week marked the end of support for legacy versions of Microsoft’s Internet Explorer, after it was announced that support for all but the most recent version (IE11) would be withdrawn from January 12th onwards. A patch was released on this date that will regularly nag users of these older browsers, asking them to upgrade.

Every single day since the beginning of January I’ve seen dozens of developers folk praising (and rightly so) this move by Microsoft. It’s a positive step in the right direction, no question.

It’s a sign that things are starting to change, and that one day, one day we’ll be able to liberate our front-end workflow and resulting code of all the various poly-fills, workarounds and practices that help make the websites and products we build look respectable in browsers like IE7/8/9 as well as IE10 to a much lesser degree. What it doesn’t mean is that we can down tools and forget about them.

I had something to say about this on Twitter:

Let the numbers guide you

I did a search for tweets on the topic and this one raised the exact question we should be asking ourselves at this time:

When will our support requirements change? What should be driving this decision?

The problem is, there a lot of developers out there that are heralding the end of support for legacy versions of IE as the end of a lot of their woes: as if a Magical Front-end Unicorn has swooped in and transformed the landscape overnight. ***

In the long term the landscape will be different, but right now we (both site owners and developers alike) need to be looking not only at the wider trends that are widely reported throughout the year, but – as James alludes to in the above tweet – the actual data for the sites we own or are building for our clients to ensure that we’re not delivering a poor experience for these users.

Data published by leading authorities on browser trends (such as W3Counter, Browser Stats, StatCountern etc) and articles such as Sitepoint’s 2016 end of year review all confirm that Internet Explorer versions 6, 7, 8 and 9 still have a collective market share of approximately 3.5 – 5% of the desktop browser market. IE10 has a larger share, however this makes sense given that it’s the most recent of the browsers that are no longer supported.

Granted, 3.5 – 5% is a small percentage, but a small percentage of a whopping great number of users. These older versions of IE are still being used by millions of people, so we need to be making informed decisions based on the available data.

A note on the market share

Back on January 6th I posted something on Twitter about this which I thought summed up one of the big reasons why older IE browsers are still hanging onto this market share. Heather Burns fired back an interesting reply that is a perfect example of why the decision needs to be made based on the available data that shows exactly how users are accessing the site(s):

https://twitter.com/idea15webdesign/status/684737700876947456

Even if we, say,  knock 10% off that figure to account for IE10, that’s still 15% of users that are accessing these sites via what many developers would consider to be a true legacy web browser.

The NHS is a great example of an organisation in one of the sectors I referenced in my earlier tweet that won’t be upgrading all users to IE11 overnight. Especially given the economic and bureaucratic issues they face when it comes to IT projects.

That patch I mentioned at the top of the post? It can be disabled by “enterprise” users: meaning any large organisation that has centralised control of software installed across a significant number of machines. There are hundreds of thousands (if not millions) of these organisations across the world accounting for many, many millions of users.

Make sure the pain is paid for

I, like many other web developers have become accustomed to catering for these older versions of Internet Explorer over the years. At both my former employer and at Make Do I’ve spent countless hours baking IE 7/8/9/10 support into boiler-plates that I’ve built to facilitate speedy and (relatively) hassle-free development.

As web developers we all know the pain that work to support these older browsers can cause. I’ve launched into expletive ridden, vitriolic rants about this work on more than one occasion, which is something of an understatement. We’ve all been that guy/girl on the edge, the computer programmer equivalent of Michael Douglas’ character holding the shotgun in Falling Down.

Yep, been there, thought that.

Granted, poly-fills have eased this pain a little, but it’s still painful and time consuming. Oh well, at least the client is paying for this support. Right? Right?!

Regardless of whether you’re working for an agency or as a freelancer, you should really be factoring legacy browser support into your quotes/proposals. If the client needs to support these older browsers then you need to be having a conversation about adding the required number of days at your usual day rate. Period.

Note: Don’t get me wrong, I’m still advocating that we look after these users, we just have to ensure that we as developers aren’t doing this for free.

If you or the agency you work for aren’t doing this, or you’re just throwing legacy browser support in as “part of the package” then you’re missing an opportunity to both increase your revenue and help contribute to the decline of the market share these browsers have.

Mark Wilkinson made an excellent point in response to a tweet of mine:

Quite right too. The web design/development community can help knock a few decimal points off those market share figures by making it clear that we won’t continue to offer support for free.

The increased cost of carrying out this work will (to a degree at least) lead to a decrease in support for these browsers when new websites and online products/services are launched. The result is that users of these older browsers will end up wanting the better, richer and more functional experience that comes with an upgrade and therefore a modern browser.

Furthermore, many frameworks,libraries and other resources that we include in our workflows are going to drop support in the coming weeks and months: some already have such as ReactJS dropping support for IE8 on the day support was withdrawn. This ultimately makes the task of providing support for older browsers using these kind of technologies more difficult as they continue to evolve, which is detrimental to the overall user experience.

Note: Naturally, progressive enhancement ensures we can still provide a usable, functional experience, even if that experience is considerably more “basic” than the “full fat” version.

Increased development costs combined with poorer user experiences should hopefully drive more organisations (directly) and users (indirectly) toward upgrading to the most recent version of Internet Explorer or indeed, other browsers like Firefox, Chrome, Safari or Opera.

Wrapping up

The pace of decline in market share for these older versions of IE is going to speed up as a result of this patch and all the public relations surrounding the withdrawal of support. However, for all we know it could be another 12-18 months before it’s low enough to truly justify downing tools and abandoning practices. That said, I sincerely hope that I’m wrong and it drops off quickly!

*** The Magical Front-end Unicorn (MFU) has this power at its disposal, but chooses not to wield it. It’s the MFU Gotham deserves, but not the one it’s going to get right now.

Advertisements

5 thoughts on “Internet Explorer and the legacy that won’t go away just yet

  1. Great article Dave. I think developers like ourselves do need to help out here and like you mentioned above it is important that we make clients aware of the differences and issues legacy browsers cause. This combined with the fact that we have to charge a lot more to make websites work well on the older browsers then give these clients a decision to make on whether paying the extra or upgrading their software is the right way to go.

    Charging nothing extra or even not having that conversation and making it work on all browsers just means clients never know there is a problem with legacy IE browsers in particular.

    Think about when the iPhone (iOS) was launched. Apple make a conscious decision to not allow it to use Flash Player, perhaps because they knew at the time that it was not going to be part of the future on web trends. Therefore instead of patching things to make it work for all those that didn’t like it, at the cost of making their devices run slower etc. they decided to not include it.

    Take a look now and Flash is disappearing of the web slowly but surely (well apart from video services but they probably will eventually find something else).

    So wrapping up here, make sure you inform clients that you either don’t support older versions of IE, and as Microsoft themselves have said they don’t support lower than IE11, we as developers may as well do the same – or make sure you are charging for legacy sites compatibility.

    Like

  2. It’s worth adding that it is only in the past few months that NHS IE7 use has disappeared from the browser stats.

    There’s a fascinating comment on this post I wrote about the issue three years ago from someone discussing locked down green-screen systems still in use. (Remember those green screens? Screensavers were invented to stop the display from burning itself onto the glass? Yup, still in use.)

    Like

  3. Great article Dave and a very valid point made by Heather. Large organisations are certainly much slower to upgrade their technology. We do quite a bit of work in the rail industry and, for example, a WordPress-based intranet site we designed for a train operator currently has 38% IE 8/9 use (and about 3% IE 7!), mainly because their ticket office computers run such old kit and software. I can think of other organisations, e.g. financial services, that have the same outdated browsers, so unfortunately I don’t think we’ll be seeing the end of IE 8/9/10 for quite some time!

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s