Variability

a vibrant pitchfork

The ongoing innovation on the web has changed a lot how we approach our designs. Now we have web fonts, video, audio, images for low and high resolution displays and other features that rely heavily on fallbacks. To make them work as expected, we use the same font in EOT, TTF, OTF and WOFF formats; the same video in WebM, OGV, MP4, MOV and Flash; the same audio in MP3, OGG and WAV; the same image in different sizes with affinity towards WebP because of its 30% better compression than JPEG. We have come to a point where our sites can't have the same level of reach with the same amount of effort as before. Defending this reach starts to gradually cost us more and more. Creating separate files and referencing them from code is a maintenance problem that causes us to lose ourselves in the details, leading to smaller thinking. Our development gets slower, because we need more time to find the files on the disk and more time to read the code.

Another thing that changes is variability, which isn't something we often think about. For example, if we buy a mobile phone, its performance shouldn't be very different than another one of the same model and brand. Otherwise we may feel betrayed by the seller and request a refund. Once we notice that someone gets a better value for the same price, we will start to demand the same value too.

When our users open our site in different browsers, they'll see the same things, but their experience can be very different. If the download size of a single font in two different formats can be 18kB and 70kB respectively, it means that the user of the browser that supports this font format will need to wait much longer. A difference of four times might not seem much, but it's only for a single resource. Such a high variability could be an early indicator that the user's expectations won't be met in case of a browser or platform change. And that is a threat to how the user will perceive our work. If a site loads all resources in 2s in one and in 10s in another browser, that's high variability. Although we can't control it, we can at least limit wide ranges simply through a clear decision what to support and what not. Even the best existing products today aren't for everyone and if they were, their quality would suffer. Price is just one mechanism through which producers can target only a segment of all available consumers, even if they claim that their product is for everyone.

When I saw the early variants of @font-face with all the font formats inside, I was reluctant to use it. It felt somehow very wrong to me. Now, when the support of font formats has improved radically, people have pointed out that we can remove all of them except WOFF and then compress it with the FontSquirrel tool, embedding only the characters that we need. I already knew that Google is doing something similar with the fonts they made accessible through their CDN as they weren't quite happy with their sizes. Icon fonts are another alternative that might be worth paying attention to, since we include only the icons we need, which saves HTTP requests. Whether this becomes a more maintainable alternative than CSS sprites, only time will show. However, we must be careful with our desire to put everything in a font. When we speak about fonts, we still mostly mean type and not symbols, so it's useful to keep the distinction.

Different video, audio and image formats are great, but depending on the browser, they can have varying loading times. Network load and latency also introduce variability, which is said to be especially true on mobile devices. If our website relies on external services that we can't control, and they respond differently according to their current load, it also means that we introduce variability in our design. Even what might seem not variable can be variable. For instance, if we have a processor-heavy application, it might run equally well on all browsers, but perform very different on devices with different battery characteristics. This will highlight the differences in time it can be effectively used.

For our users, variability can raise the issue of fairness. What can still be perceived as fair when it varies? We can make our new application invitation-only, but this isn't fair to the people who weren't lucky enough. And it will be seen.

What we can do is to always be cautious for the variability we introduce in our designs and seek ways to limit it.

bit.ly/XQwoF9