It's easy to take for granted the work that goes into ensuring that all shoppers get the same, high-quality experience regardless of the device they use to browse your site. Personally, I've used Chrome for years and I admit that when I work on things for this site, or simply tinker on my development site, I only test it works in Chrome. This is fine, right?
But what if your site is your source of income? What if you run... an ecommerce site? Well, that's what you guys do, and it would be remiss of us as an organization if we didn't take seriously the myriad of different ways that your shoppers browse your site. If something that works for, say, Chrome, doesn't work in Internet Explorer then you could potentially be losing out on conversions. And what do conversions mean? Cash.
In this article, I want to talk about this. I want to talk about what steps we have done to protect compatibility across browsers and devices, what you can do as a developer on the platform, and what changes we're making in the near future.
Why is Browser Compatibility Important?
A second issue arises when users do not continue on a browser's upgrade path. Each update to a browser will introduce support for new standards, improvements, and bug fixes. While many modern browsers automatically update (or prompt the user to update) many users simply don't. As the majority of people stay on the upgrade path, we end up with a scenario where most people can take advantage of particular features, but some can't. This growing gulf creates a dilemma: what do you do?
Approaches to Supporting Older Browsers
Catering for older browsers has been something that web developers have had to deal with for a long time. There are a number of approaches, broadly speaking, that can be used to address this issue:
- Don't use the feature at all — simply accept that it won't work for some users, and so not implement it.
- Find an alternative, safer way — some new features can effectively be seen as shorthands for old features, so you could just find another way to do the same thing.
- Use a polyfill — this is similar to the above, but is closer to the idea of 'regressive enhancement'. This means implementing something using the new features, but having something in place if the browser doesn't support it.
- Use the features anyway — who cares about these people! Let's use the feature anyway! It doesn't matter if the site is unusable for them!
There's no universally correct approach, although the last one is probably the farthest from being correct in most cases.
Internet Explorer 8
One particular example that'll come up time and time again is IE8. It was released in early 2009 and became the last version of IE to be compatible with Windows XP. In other words, if you use XP and IE, you were locked into using IE8 and could not upgrade further.
Indeed, this is where we find ourselves currently — but not for much longer. At the time of writing this, NetSuite (and SCA core code) supports IE8, but this is changing. From 17.1 onwards, and with the release of the Elbrus version of SCA, we will no longer support IE8. While we recognize that are still some users using IE8, we no longer recognize them as a minority significant enough to continue to write code that supports them.
While we have been embracing the first three approaches listed above, we have now felt it's time to embrace the fourth. Microsoft themselves have ended support for IE8, which expired on January 12, 2016 and since then we have been considering our options and monitoring the situation. Now, we have decided to take action.
What Will Happen When Support is Stopped
It is the Elbrus release that stops supporting IE8, so older source code (eg Vinson and Denali) will not be affected as that code was written to support IE8. However, any new features included in Elbrus will not support IE8, so if you migrate to the new version you'll no longer support IE8.
However, dropping support does not mean the site will break entirely but that users may find that some won't work as they expect. Our line on this is akin to "the application won't crash".
As I said at the start, this could have a financial impact on you. If you want to make this move, you should take a look at the analytics about IE8 usage. Don't just look abstractly at the global usage (which you can do on sites like NetMarketShare) but the ones specific to your site. At the time of writing, NetMarketShare reports that about 2.88% of traffic across the entire web is from IE8 users but, in our experience, that percentage is even lower on SCA sites. One internal estimate puts it around 0.02% (with revenue from these sources accounting for approximately 0.03% of the overall total), and it's a number we've noticed has been declining over the past couple of years.
Checking The Numbers
The best way to check this for your site is to use Google Analytics. Log in to GA and, in the menu, go to Audience > Technology > Browser & OS.
The table on this page breaks down the traffic by browser, regardless of its version. To drill down to specific versions in the context of that one browser, you can click on its name. However, we want it in the context of the entire site (all browsers). To do this, click on the Secondary Dimension dropdown and select Users > Browser Version. After the table refreshes, detailed information will be shown.
The important information to look out for is:
- The percentage of sessions originating from IE8
- The goal value total for IE8 (in particular its percentage)
Presumably, you'll see numbers that match ours: that approximately 2.5% of your visitors use IE8, and approximately 0.05% of your revenue comes from these shoppers.
You may be thinking, yeah it's only 0.05% but it's still revenue! Why would I want to give that up? Good question, but the real question is: how much revenue are you missing out on by being constrained by this limitation? How much more could you make once you're liberated from it?
The jQuery Problem
In SCA, we use jQuery version 1.11, which is nearly three years old. This seems a little odd, right? I mean we're using pretty cutting edge technology, but why use such an old version of jQuery? The reason is that this is the last version to support IE8.
Since April 2013, when they released 2.0, explicit IE8 support was dropped. This update reworked a lot of the underlying code of jQuery, some of which simply doesn't work on IE8. With this update, the message was, "it might still work, but we won't guarantee it". Indeed, from our point of view this wasn't enough — we needed that guarantee because that's what you expect from us.
However, if we drop support for IE8, then that means that we can also upgrade of jQuery version to a much more modern one.
If you read my article on jQuery promises and you know a thing or two about them already (or you did your own research) you may have known that the promises in jQuery 1.11 do not match the universal standard for promises. There was a lot of discussion around the time about what a promise should be, and what exactly it was that jQuery had implemented.
It wasn't until version 3.0 (June 2016) that jQuery implemented what is known as the Promise A Plus specification for promises. This specification was community driven and took a while before it became a standard. Indeed, you can read the interesting discussion that took place in the GitHub issue.
I should say that Elbrus probably won't feature an updated version of jQuery — it'll probably contain 1.11. The point is that as of this release, we won't officially support it. It is not until later releases that we will start to deprecate the version and introduce a new one.
Mobile and Tablet
While IE8 on desktops may pose a problem, mobiles and tablets introduce other headaches.
The first source of anxiety comes from the sheer number of versions of the Android operating system currently in use:
This is then further fragmented, first by device manufacturer and then by device. OpenSignal reported in August 2015 about this and the report makes for interesting reading. At the time, while iOS had 85% of its users on its latest version, only 18.1% of Android users could say the same.
This also says nothing about the in-built browser, which is also open source and subject to possible modification.
Many big software vendors are generating lists of specific devices and OSes that they support in order to address this problem. This may be too drastic for you and your ecommerce site, but it's a symbol of the problem.
Testing Your Own Site's Compatibility
I said it before and I'll say it again: you need to test your site using browsers other than the one you develop in. There are idiosyncrasies across the different ones, and these could potentially cause your shoppers problems if you don't catch them first.
So what do you do? Write a bunch of code and then just try it out on as many devices as you can find? Well, let's be smart about this.
Can I Use ____?
A good place to start is CanIUse.com.
This site tells you whether the bit of HTML, CSS or JS you want to use is supported by different browsers. For example, if you were thinking of getting fancy and using flex boxes on your site, you may want to think again as IE11 only offers partial support.
This is a good place to start because if you know beforehand that a certain browser won't support a specific functionality, you can just junk the idea of using it (or seek out alternatives/polyfills).
Indeed, if you dig deeper into this stuff you will see that you can also run comparisons between browsers. If you do, the comparison between IE8, IE11 and Chrome 54 (the current version at the time of writing) is pretty stark. Indeed, while many of the newer browsers now offer native promises (ie ones without the use of jQuery), IE11 doesn't support them. This whole thing seems like one big headache, right?
Browser Testing Services
Did you know that Microsoft make standalone versions of their older browsers available for download? Indeed, one way of doing this testing (without having a whole load of devices) is simply to get virtual machine programs and download images of various OSes and browsers and do the testing that way.
This is pretty handy as they can all be run for free from your computer and can really help you see what your customers are going to see. If you head back to IE8 on Windows 7, you'll see that your site isn't even responsive. You'll probably also find that so many aspects of it simply don't function how they do on Chrome or Firefox.
However, if you don't want to do it this way — and you want some cool additional tools along the way — then you can use a hosted service. We don't recommend any particular service, but there are some out there that I think are pretty good. Both BrowserStack and SauceLabs offer excellent services with an array of features. Indeed, recognizing the pain of ensuring compatibility with IE, BrowserStack even make a point to market themselves as having specialized in that area.
One final thought about your own site: sometimes there are no substitutions for testing things on your device. Most modern personal computers do not have touch screen capacity, nor are they natively using small resolutions. Sometimes the only way to truly test your site is to get a mobile and a tablet, and just hammer your way through the site.
For example, we suggest that you should make the buttons on your site big and touchable, so that buttons are bold and bright and easy to use. While they may seem obvious and easy to use when you shrink down your browser window and use a pointer, how do they hold out on your mobile? Again, don't just stick the one that you use! Take a look at your analytics and determine where your customers are coming from. You may find that a significant number of your shoppers are using older or more obscure devices and browsers. If you've made a modification that affects your critical path (ie, adding to cart, logging in, placing an order) then you should be sure that these users can still take advantage of it.
Services like Google Analytics allow you to compare current data with historical data, even enabling you to drill down and see these things from the perspective of browser/device combinations. If you are interested, I strongly recommend taking a look at this. You may find that a number of your users are frustrated by a recent change to your site and aren't able to check out. Using that data, in combination with the devices and browsers they use, may lead you to a way to fix their problems and in turn increase your conversion rate.
If there are any key takeaways from this article, let these be them:
- There are very real differences between browsers, operating systems and devices — and you need to account for them
- Some of your users will use significantly older browsers that do not support the latest technology — if you want their business, you'll need to cater for them
- One browser we're no longer going to cater for is IE8, due to its dwindling usage and the fact that Microsoft no longer support it
- There are many ways to prepare and test for different browsers: first by ensuring you use compatible functionality, then by testing, testing, testing
There are a lot of permutations of device, operating system and browser. Use your analytics to find out who your key shopping demographics are and focus on them. Similarly, take a look at the data and see if you can identify any weaknesses: for example, you may find that a certain demographic represents a significant proportion of visitors but a small percentage of your conversions. If that's the case, you may want to test that combination to see if there are issues on your site.