Looming Large

Sitting right at the heart of responsive web design lies one simple principle - that you cannot guarantee what a website will look like on a device or a display that's not in-front of you. We love an acronym in the IT sector and I've just created a new acronym: LOOM, meaning 'Looks OK On Mine'. The acronym is intended to shine a spotlight upon one of the biggest misconceptions in web design. To begin illustrating the point, here is a live example from one of our own responsive web design projects.

One month ago, just as I had settled down to working from home, I received an email from Nigel at DWP Imaging to tell me that somebody he knew had commented that the words on DWP Imaging's website were too large.
 
Now, I was aware that we had placed some headlines on the web pages with larger-than-usual font sizes so I asked Nigel if his friend would be kind enough to send me a screen grab of what he was seeing because the website looked ok on my *devices. What arrived in my inbox next was more than surprising.
 
*The image at the head of this blog post shows the five devices I use to test websites on and that one web page will look different on each.

The screengrab sent to me (image to the right) came from an Android device running the Chrome browser but what I saw on my own Android device bore no resemblance to what had been supplied. At first my assumption was that the person in question had increased the font display sizing in their phone's OS settings. I tried for hours to increase the font size in both the Android OS and in Chrome's settings - neither were able to replicate what the user was experiencing. The closest I was able to get to it was on an iOS device with the OS font sizing cranked right up to the maximum 300%.

We do love an acronym in IT

Now, I'll openly admit to a little bit of PICNIC but what I was actually feeling was more like LOOM.

The user's device was displaying ultra-large type and I was struggling to grasp why the DWP Imaging website should be causing this user an issue because, surely, every website would be displaying massive type too? I was unable to resolve this myself and needed help so I asked the user if they'd mind using an error checking page I'd developed for Web Diffusion, our own website management system. After a bit of gentle probing via email, it turned-out that the user hadn't increased their font size. Shortly after sending-out the request, the response from the test form came back to me and things started to get even more confusing. The user was running exactly the same version of the Android OS and exactly the same version of Chrome as I was and the screen resolutions of our two devices were broadly similar.

Technically, what went wrong?

Underpinning the responsive web design approach are what we term as "breakpoints" - a set of conditions which, when met, apply a defined set of browser styling commands. Typically, these conditions are the display width of the browser's viewport. Things become complex when mobile devices have the capability of displaying images x2, x3 or x4 the screen display resolution (so called retina images).

DWP Imaging's website had a styling rule written (by me) into its CSS that was aimed to differentiate between an iPhone being held in a landscape orientation and an iPad being held in a portrait orientation. My CSS code used the -webkit-device-pixel-ratio attribute to help identify whether an iPhone or an iPad was being used. The -webkit extension meant that this condition only really targeted iOS devices, however, it appeared that platforms other than iOS had now begun to take note of the attribute.

Where we ran into difficulties was with devices which not only took note of and acted upon the attribute but, critically, also declared the width of their viewport in a way that deviated from the norm. We saw this in the report our user kindly submitted; where the Android device identified itself as having a high pixel density but declared its window_innerWidth=379 - whereas on other Android devices, which did not display the characteristic, a measurement of window_innerWidth=980 was more typical. The upshot was that on devices which declared the lower window_innerWidth the font-size set for the body of the HTML was rendered x3 larger.

LOOM: (acronym) - Looks OK On Mine!

The problems with the acronyms we techies love to band about such as LOOM and PICNIC is that they're crafted from the viewpoint that the user's at fault. Sure, as users of tech we all do dumb and stupid things but, most of the time, we do it because we intuitively assume that's how the tech should work. Observing users makes for better tech.

So whose fault was this?

Given the assertion of the foregoing paragraph, the appearance of the ultra-large type on DWP's website was clearly neither the fault of the user and nor was the oversized type the fault of DWP. And, no matter how much LOOM I felt whilst figuring this out, the fault was not attributable to the device manufacturer or the developer of the web browser.
The Web's responsive by default.

The fault was of my making

The web works just fine on its own, thank you very much. The web standards which define HTML syntax are standalone and subject to peer review and development. Web Designers are the problem. Our job is to take web content and apply style and positioning rules so that the text and images are presented across any device in a legible and branded fashion. The CSS code we write to 'make things better' can also break the flow of the original HTML source code. The latent breakpoints we create are little more than 'hacks' and 'shims' to change the appearance of the content based upon some assumed, anticipated and projected properties of the device display. The fault was of my making, no-one should have to foot the bill for this and so the you break it, you pay for it rule applies.

Links

Sub@omic responsive website design DWPi: Creative Commercial Photography Sub@omic's Fibonacci Breakpoints