We have reached 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 planet.
First off, I’d like to suggest that we approach building our web applications with an acknowledgement of who needs to use this application and what their capabilities are when and as they are using it. Asking those questions early in the process should be an important part of any application’s design considerations.
Unfortunately, everyone wants the most bleeding-edge web development frameworks and technologies while still supporting legacy browsers. Let’s be realistic for a minute and acknowledge that’s becoming less of a possibility. Supporting older browsers will hinder the technical capabilities of an application as well as reduce the selection of development tools. That said, let’s jump into a few hurdles with browser and mobile testing that we encounter in our work process.
Internet Explorer 8 and 9 are fading away
There’s a reason Internet Explorer is so notorious in web development. There are always little kinks that all the other browsers harmoniously work through but Internet Explorer often handles things in different and unexpected ways.
Today, we are still considering IE8 and IE9 the lowest rung of our browser ladder. They are both becoming more and more difficult (and expensive) to maintain for modern web applications. We are seeing the rise of javascript frameworks and a movement to remove support, as well as Microsoft itself no longer supporting anything less than IE11.
We have certainly supported these browser versions in the past but as time goes on, the path of resistance will grow stronger still for this browser and its users.
Ok - but… I have to support it because of yada yada yada…
Sometimes we are maintaining a legacy application where users MUST use these older versions of IE. How the heck can you do some testing to make sure your new code isn’t breaking anything?
First hurdle to overcome is making sure that you have access to a modern Microsoft browser. IE11 or Microsoft Edge both have developer tools that will let you test for older versions of IE to see what your web page would look like.
If you are on Windows that’s an easy step, but for Mac users it becomes a little more difficult. The best way to actually test these browsers is to emulate a real Windows environment. To do this, you can either use bootcamp to install Windows on your machine or use a virtual machine like VirtualBox. I like to use this automated installer to get all the Windows VM disk images that I need to test for.
What about mobile?
When I was first starting out as a front end developer I saw a photo of a developer’s workstation that was covered in different types of smartphones and tablets.
I thought that might be what my workflow would have to be like. I was overwhelmed by the amount of devices that I would need to test.
As my career progressed, I realized that I can rely on browsers for a large part of my mobile testing because they have such robust device and mobile emulation capabilities.
These days I’ve been using Chrome’s Developer tools to emulate different screen breakpoints. Chrome’s developer tools (as well as Safari’s developer tools) are so useful for remote debugging (debugging by connecting a mobile device to a computer), when I am testing on a physical device.
Remote debugging is handy because I am able to to use the developer tools to inspect elements inside my mobile browser and interact with the console. This makes it much easier to track down bugs that are device specific.
Remote debugging alongside xip.io allows me to browse to my laptop’s IP address on my device and immediately debug any changes I make in my codebase immediately! Without these technologies you would have to deploy your code each time you want to test a change. This can save so much time not having to push everything up for incremental changes.
Shifting my perspective about writing CSS responsively has been so important as well. It has worked much better to write my CSS to flow between breakpoints, instead of optimizing styles for most common screen widths. Styles should not break as you scale between breakpoints and make sure to choose a limited number of breakpoints so everything snaps to the next media query at the same time.
Wondering about your own application?
Discussing browser and device capability in the planning stages of our applications should be at the forefront of our conversations. In our experience it’s been much easier to debug legacy browser issues early when the code base isn’t enormous; especially because legacy browser errors are typically cryptic or nondescript.
If you need help making sure that your application is compatible across browsers and devices, we’d love to help! Feel free to give us a call.