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.

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 stating that she knew of an NHS website that still has ~25% of its users using a legacy IE browser; 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):

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.

Thoughts on contributing to WordPress

When I attended WordCamp U.S last month, I tried to spend some time in the lightning talks track to mix things up a little bit.

One of the speakers on the second day was Morgan Estes, who gave a talk about taking the first step to becoming a WordPress contributor. I found his talk inspiring, and it really changed my personal perception of contributing.

I think it’s fair to say that there are plenty of others in the WordPress community who, like me, share the perception that contributing to WordPress as contributing code to core.

Contributing code to WordPress core is an itch I’ve been wanting to scratch properly for about the past twelve months. It’s actually in my list of development goals for 2016. That said, I have not, nor will I ever feel any pressure to make this happen. I’m content with the fact I’m doing great things with WordPress whilst working on client projects.

However, I’d really like to get more involved and share my own ideas (and code!) to help improve WordPress, so I can give back to the community of users that I’ve been a part of for nearly ten years in one way or another.

What Morgan made me realise that day was that I am giving something back, with my other contributions as an active member of the WordPress community.

For example, 2015 was the year I ventured into public speaking, delivering talks at couple of local WP meetups and two WordCamps. When I first decided to venture into speaking I had one goal: to help at least one person. From the discussions I’ve had these past nine months I know that my talks have helped at least a few dozen people, meaning I’ve already contributed something to WordPress and made a difference. Result!

I’ve now got the confidence to write and deliver more talks for the WordPress community, which is an ongoing commitment throughout 2016 and beyond. I may not be the best or the most experienced speaker in the world, but sharing my experiences and things I’ve learned is going to help others and that contribution means a lot to me.

Plugins is another area where I’m trying to give back. My first two plugins are now listed in the plugins directory, and I plan to continue writing plugins moving forward. This means I’m now committed to contributing code to the community. Granted, it’s not core code, but that doesn’t matter: my plugins are still going to help at least one person.

This is the best way to look at contributing. As Morgan said himself during his talk, it’s all about helping someone scratch the itch they have, or doing something that helps you scratch your own itch. The best thing is that quite a lot of the time, doing the latter also means you’re doing the former!

At Make Do (organisers of the WP Sheffield meetup), we’re really focused on increasing our contributions to WordPress in 2016. WordPress helps each of our team put dinner on the table every month as a result of our client work, so it’s important that we give back.

No matter what you’re doing: whether it’s translating WordPress, writing plugins, building themes, speaking at WordPress events, helping on the support forums, writing/updating documentation or even just dealing with WordPress questions/issues on Twitter you’re helping at least one person in the community.

And that is just as helpful and rewarding as each line of code you contribute to core. Plus, you stop people from scratching…

My development goals for 2016

2015 was a great year for me professionally. I felt that I really grew as a developer: especially with my WordPress hat on! It felt as though I’d been more focused and productive than any other year since I put down DSLR cameras and started down the career path of working with and building the Internets for a living at the start of 2010.

Not wanting to rest on my laurels, I’ve set myself ten goals for 2016 that I’m going to really bust a gut to try and hit before the end of the year:

  1. Have ten plugins listed in the plugin directory. I listed my first two plugins on New Year’s Day so I just need two more per quarter to hit this goal.
  2. Write and submit at least six code contributions for WordPress core. These contributions can be in the form of patches to resolve existing bugs/issues, or proposals to add brand new code. Ultimately, the goal is to successfully contribute at least one line of code to core in 2016!
  3. Have three themes listed in the theme directory: one for personal blogging, a theme for small businesses and another for non-profit organisations.
  4. Write and deliver four brand new talks: with one of them being a non-technical talk.
  5. Speak at two more WordCamps in the UK that I haven’t spoken at before.
  6. Apply to speak at WordCamps outside the UK, with the goal being to speak at one.
  7. Speak at four more local WordPress meetups that I haven’t spoken at before: with one of them being my local Manchester meetup!!!
  8. Organise or be co-responsible for organising an event in the UK. This could be a non-WordPress conference, WordCamp, workshop or a local developer meetup.
  9. Design, build, launch and market a small web app from scratch with at least 50 users signed up by the end of the year. I’ve plenty of side project ideas I’d like to try out!
  10. And finally, complete my long overdue personal site using React and the REST API, which has been a “work in progress” for far too long!

These goals are heavily WordPress themed, but that’s to be expected given that I work for a wordpress agency. Some of these goals – particularly core contributions – have been on my mind for a while now so I’d like to step up and deliver on them.

If I knuckle down half as much as I did last year I’m confident that I’ll hit a lot of the above. Whether I can get a 10/10 score is yet to be seen. Either way I sense a #busy year coming on!

What are your development goals for 2016? Anything you really want to get done?