We’re reaching a point where there are too many devices and browsers in existence to realistically test for all of them. Under typical constraints, we can only go so far to make sure that everything is compatible for every browser and device on the market.
We approach development with a rational acknowledgment of who will be using the platform, and what their digital capabilities are. Asking these questions early in the process plays an important part of any platform’s considerations.
We appreciate that some want to embrace bleeding-edge frameworks and technology whilst supporting legacy browsers, but we have to be realistic and acknowledge that’s becoming less of a possibility.
Support for older browsers can hinder the technical capabilities of a platform, as well as reduce the selection of development tools available. But is the situation that cut and dry?
Adiós IE8 and IE9
There’s a reason why Internet Explorer has become notorious in web development.
Browsers always have kinks that need to be ironed out, but Internet Explorer handles things a little differently.
Take Internet Explorer 8 and 9: they’re both becoming more and more difficult (and expensive) to maintain for modern platforms. We’re seeing the rise of JavaScript frameworks, a movement to revoke support, as well as Microsoft itself pulling support for anything less than IE11.
We have supported these versions in the past, and will still do so if required, but the path of resistance will grow stronger for Internet Explorer and its users.
Not ready to cut the cord?
That’s not to say there aren’t times where we develop for older browser versions, or we’re maintaining a legacy platform where users MUST use these older versions. So how can you test to make sure your code isn’t breaking anything?
First, you need to make sure that you have access to a modern Microsoft browser. IE11 or Edge both have developer tools built in that will let you test older versions of IE to see what your end product will look like.
Now, if you’re on Windows that’s easy, but for Mac users, it becomes a little more difficult. The best way to test these browsers is to emulate a real Windows environment. To do this, you can either use Boot Camp to install Windows on your machine or use a virtual machine.
What about mobile?
It can be easy when you’re first starting out to be overwhelmed by the amount of devices that you need to test for.
Eventually you’ll realise that you can rely on browsers for a large part of your mobile testing because they have such robust emulation capabilities.
Remote debugging (debugging by connecting a mobile device to a computer) is particularly handy because you’re able to use developer tools to inspect elements inside the mobile browser and interact with the console. This makes it much easier to track down bugs that are device-specific.
Without these technologies, you’d have to deploy your code each time you want to test a change, which isn’t ideal. This can save so much time not having to push everything for incremental changes.
And my platform?
At the beginning of every project initiation meeting, we discuss browser and device capability, it’s as simple as that. In our experience, it’s so much easier to debug legacy browser issues early on when the code base isn’t enormous. We believe if something’s worth doing, and testing absolutely is, it’s important to take the time to do it right.
Comments are closed here.