Recently I attended Edge Conference 2013 at the Google Office in New York and also spoke on the panel of ‘Legacy Clients’. It was a great experience to be a part of that event (for a lot of reasons) one of which was the chance to speak on such a great topic there. However, after the event I felt that there were a lot of points I missed out on while on stage, and that we still haven’t fully delved into the realities of dealing with various browsers and users in a particularly new or groundbreaking way. The video of the panel is below, for those interested.
So the following are a collection of my thoughts on the topic. Some of them might have been mentioned by me or others in the talk, and some of them are ones I wished I had talked about while on stage.
A lot of what I’m talking about is also mentioned in Tom Malsen’s talk on BBC’s ‘Cutting the Mustard’ approach.
The device landscape is changing so much and so rapidly that it is is no longer a good idea to keep in mind certain browsers. I would argue that ‘browser support’ is no longer relavent in this age - it stems from the time on the web when pretty much everyone was on desktop and had just a few browsers (and just a few older versions of them).
Nowadays, you have Opera, Chrome, IE, Safari, Firefox and more on desktop as well as Opera Mini, Opera, Chrome, Firefox, IE, Safari, Dolphin, Maxthon and more on mobile platforms like iOS, Android, Windows Phone and other feature phone platforms too. There is no guarantee that if a person uses, say, Chrome on desktop, they will use Chrome on mobile too (and vice versa).
You also have various screen sizes - various mobile phones have different form factors, you have people viewing things in portrait mode and landscape mode, you have normal resolutions and HiDPI (or retina) displays too. You have tablets (and tablet specific browsers like Coast by Opera) and these are getting smaller, so much so that there are a new band of devices known as ‘phablets’ (devices too small to be classified as a tablet, but too big to be classified as a phone).
Even if we start to test in all the various versions of all the browsers on all the platforms and devices, we still won’t have an accurate idea of what the user experience of our web apps will be like because of one major thing - the network. If you have a great smartphone on a great device, but you have a crappy network (or data plan) you will use your internet time on it very differently. However, if you have the same browser and device but are on a fast wi-fi connection, then you might use your time on the internet more liberally and maybe even use web apps differently. This means user expectations on how the app should behave might also differ based on whether they have a super slow connection or a really fast one. (one example would be of a news site where on a slow connection the user might not try to seek out videos and audio instead going straight to text content, while on a faster connection he/she might watch video reports more and read a bit less).
You also now are getting phones which have operating systems previously seen only in smartphones, but now in phones which are in the sub $100 range category (which was the domain of feature phones). What this means is that you’ll get phones running a browser with a decent rendering engine but the phones are so underpowered that your JS heavy sites won’t be able to run properly.
All this is in addition to embedded browsers (like facebook on iOS and Android, the Twitter native app etc) which also take up a quite an amount of mobile web traffic - and then you have proxy browsers like Opera Mini, the Nokia Xpress browser and more used by hundreds of millions of people every month (and many of them use it as their primary way of accessing the web).
In other words, from now on, supporting legacy browsers will become much much more complex - in fact, let’s stop calling them legacy browsers from now on.
Instead, we should focus on the user environment (a combination of the network speed, device capabilities, resolution, and web feature support). This means making a core experience capable of running everywhere (instead of making a full fledged site and testing on a lot of browsers) and then conditionally loading additional functionality by progressive enhancement and feature detection. Stop caring about what browser brand the user has, instead focus more on the capabilities (or limitations) of the user’s total environment.
Of course, the amount of different devices and browsers (and their versions) coming up make it impossible to test on all of them. However, that does not mean you stop supporting them. You shouldn’t have an ‘unsupported’ browser - in the sense that every browser should at least get the core experience (or the core content) even if it doesn’t have all the bells and whistles that the modern browsers have.
Keep in mind, you cannot test in all of these browsers. Nobody is asking you to test your core experience in each and every browser (and every device under all network conditions). Just pick a few from each category (older browser from desktop, popular mobile browser on underpowered phone, also test in a slow network) and see if your core experience holds up in those or not. After that if there is a complaint from a user that their browser is not rendering your site properly, then of course, take a look and try to fix it - but the main idea is to make the core experience such that older ‘html4’ browsers would also not have trouble getting the main content. Even if it does not look super pretty, at least the user should be able to accomplish the task for which he/she loaded your site. At the very least, test on one older browser, one proxy browser (Opera Mini would be the best bet) and then whatever modern evergreen browsers you want. The core experience should work on all of them.
The only sane thing to do in this world of a gazillion different browsers and devices and connection speeds and resolutions - is to create a core experience which could be consumed by everyone. Have this as the default which can be accessed by everything. Then on top of that conditionally load more bells and wistles. This is exactly what progressive enhancement is, and it’s not really a very new concept. However, we still to this day rarely see people doing it right.
In other words, going forward, we should stop with the notion of ‘unsupported’ browsers. The world is different now. Gone are the days when there were just a select few older browsers to support. There are so many browsers and so many different devices, in so many different contexts that its a losing battle trying to cater to them all. We should create an experience accessible by all and build from there. Creating a light core experience also has the added benefit of being better accessible to search engines and chances are (though not always the case) its also better accessible by screen readers.
We don’t talk about media queries when talking about supporting older browsers right now … but in the future, this will be the case. And as the world is shifting, we will find that things won’t be about supoorting older browsers in the future, it will be about older devices. So in the future, even for older browser/device support, you will need to grapple with media queries.
So lets talk briefly about media queries, more specifically, popular breakpoints used in media queries. Given the overabundance of various devices and screen sizes, this approach will not scale and is not future proof. There is only one solution to all this, which is to not care about any device in particular. Start small (preferably) and keep changing the screen size until your design looks bad. At that point, introduce a breakpoint and write CSS in a media query to address that. Rinse and repeat.
All this complexity means that its increasingly difficult to browser sniff your way out. As it is, browser sniffing is bad practice and notoriously bad when it comes to making your apps future proof. As a rule, I encourage people not to browser sniff. However, as with any rule, there are a few exceptions … so if you do have to do UA sniffing, then keep the following points in mind:
Polyfills have a cost. Every time you include a polyfill, thats some additional data your user is paying for when he’s downloading that page on his mobile network (a lot of people around the world still have per-KB/MB based data plans). It also makes your pages heavy and its one more http request. So before using a polyfill, ask yourself whether using it is critical or not. If its just a ‘nice-to-have’ feature, then probably its probably better to not use the polyfill.
Another category of apps are those where there is not a polyfill to cater to older clients, but alternative techniques are there. For example, you cant polyfill for the geolocation API in IE7, but another solution could be to ask the user to enter their PIN code and determine further functionality through that. In some cases, as a last resort, you could fall back on a plugin based solution (like flash or slverlight).
The third is trickiest. The category of apps where the core content requires using some API which cannot be polyfilled, and for which there is not a workaround too. In those cases you just need to accept the fact that the app simply wont work there, and let the user know that the browser required to run the app needs certain features unavailable in the browser.
There are a few tools which could help in testing, whether its older IE versions or tools to simulate slower network speeds. Some of the good ones are the following: