Why Building a Device-Aware Website is Problematic
You read that headline, and now you’re thinking “Wait, what are you saying? Of course, your website should be device-aware! How else would websites be responsive?” Well, sort of. What developers really want is for the experience to be media aware, not necessarily device aware.
There is a difference between being media aware and device aware. A web developer’s toolbox has many options that allow their site to be content aware or media aware. Device aware is achieved by building a website for a specific operating system, browser, or a particular set of devices. When making an experience device aware, developers generally resort to using something that was not necessarily designed to decide a site’s behavior, like Javascript or CSS attributes.
A Varo Case Study
An example of this recently came up at Varo. The requirement was to render the content in iFrame on mobile browsers and an object on desktop browsers. It was a mandatory requirement that we could not change. After some research, we chose to test the any-pointer attribute. If the browser was reporting that any-pointer was fine, it meant a mouse or another accurate pointing device was in use. The fine-pointer indicates a desktop browser since it can indicate a precise position. Otherwise, it was mobile, since touch screens are not as accurate.
We went through testing, and the device-specific behavior worked, so we thought we had a workable solution. We went into production, and all was looking good, and then we received a new set of testing devices. This new group of devices had a mobile phone where the regression test failed for the device-aware behavior. On this specific device, the pointer was fine even though it was using a touch screen. This scenario led to a mad dash to create a stronger solution. We ended up parsing the user agent to find the operating system used. But this, too, is easily broken since the browser developer can change the keyword at any point.
The above situation is a perfect example of why device-specific behaviors are fragile. The test relies on attributes and methods that other developers did not intend for this use. Since they are expecting specific purposes, they can and will change attributes to achieve their requirements and features. And further, since device-aware solutions use methods or attributes in a non-standard way, a simple change and the feature can be broken. We may use alternate techniques or even combine techniques to build a robust test to identify the user’s device. However, in the end, it’s not necessarily meant to decide behavior and will always have a more significant potential to break.
What should we do?
The ideal route to take in these situations is to work with the product owner and UI designers to find a solution that uses feature detection. At this stage, we can test whether the feature is browser compatible.
For example, let’s say we were trying to use location services. We can test the Geolocation API, along with the methods required, that are ready to use. While testing, we check what is needed rather than some other attribute that indicates it can be used. Unfortunately, we do not often get the ideal, so we need other options.
The next best option is to work with the product owner and designers to find a solution that works across all devices. By doing this, we bypass entirely any need to test what device a user is using. When all options are exhausted and the only option left is to go down the road of device-aware, confirm that the regression test suite is watertight and runs regularly. The regression test suite should be run regularly irrespective of code change. This will confirm that the devices and browsers still support the feature. Since we are relying on a fragile solution having a regression suite that covers it and potential changes in browsers is ever more critical.
In the end, what we want is to provide a reliable experience our users can rely upon. We are #customerfirst, after all. This can be challenging enough when supporting various devices, across multiple operating systems, browsers, and experiences. Building a robust, maintainable codebase helps do this, but when introducing device-aware behavior, we are not doing that. Due to their nature, device-aware features can easily be a production problem. There are numerous other issues, including the customer inconvenience, extra quality assurance costs of regression, issues of resourcing, and delays to other projects when a problem occurs. For all these reasons, if a device-aware requirement comes and you can avoid it, do avoid it.
Paul is a web developer specializing in developing UI, with a passion for making it accessible for everyone.
