A brief list of false dichotomies

In the world of web development, there are many choices that are commonly presented as true or false, black and white, Boolean, binary values, when in fact they exist in a grey goo of quantum uncertainty. Here are just three of them…

Accessible and inaccessible

Oh, would that it were so simple! If accessibility were a “feature” that could be controlled with the flick of a switch, or the completion of a checklist, front-end web development would be a whole lot easier. Instead it’s a tricky area with no off-the-shelf solutions and where the answer to almost every question is “it depends.” Solving an accessibility issue for one set of users may well create problems for another. Like I said: tricky.

Documents and applications

Remember when we were all publishing documents on the web, but then there was that all-changing event and then we all started making web apps instead? No? Me neither. In fact, I have yet to hear a definition of what exactly constitutes a web app. If it means any URL that allows the user to interact with the contents, then any document with the slightest smattering of JavaScript must be considered an application. Yet even on the desktop, applications like email clients, graphics programs and word processors are based around the idea of creating, editing and deleting documents.

Perhaps a web app, like obscenity, cannot be defined but can only be recognised. I can point to Gmail and say “that’s a web app.” I can point to a blog post and say “that’s a document.” But what about a Wikipedia article? It’s a document, but one that I or anyone else can edit. What about Twitter? Is it a collection of documents of fewer than 140 characters, or is it a publishing tool?

The truth is that these sites occupy a sliding scale from document to application. Rather than pin them to either end of that scale, I’m just going to carry on calling them websites.

Desktop and mobile

The term “mobile phone” works better than “cell phone” because it defines a phone by its usage rather than a particular technology. But it turns out that the “phone” part is just as technologically rigid. Hence the rise of the term “mobile device” to cover all sorts of compact Turing machines, some of which just happen to be phones.

In web development, we speak now of “designing for mobile,” but what does that mean? Is it literally the context of not being stationary that makes the difference? If so, I should be served up a different experience when I use my portable device in the street to when I use the same device sitting down in the comfort of my home or office.

Is it the bandwidth that makes the difference? That would imply that non-mobile devices don’t suffer from network scarcity. Nothing could be further from the truth. Performance is equally important on the desktop. It may even be more important. While a user may expect a certain amount of latency when they’re out and about, they are going to have little patience for any site that responds in a less than snappy manner when they’re at home connected with a fat pipe.

Is it screen size that matters? That would make my iPod Touch a mobile device, even though whenever I’m surfing the web on it, I am doing so over WiFi rather than Edge, 3G, or any other narrow network. What about an iPad? Or a netbook? When I was first making websites, the most common monitor resolution was 640 by 480 pixels. Would those monitors today be treated as mobile devices simply because of the dimensions of the screen?

I’ll leave the last word on this to Joaquin Lippincott who wrote this in a follow-up comment to his excellent article, Stop! You are doing mobile wrong!:

Devices really should be treated as a spectrum (based on capabilities) rather than put into a mobile vs. desktop bin.

Have you published a response to this? :



Jeremy Keith recently wrote a post about some of the false dichotomies in web development. When faced with two options, we are often presented with a solution that paints one option black and one white as if there was no middle ground. I’ve attempted to write a post along a similar lines many times, though to be perfectly honest, none of my drafts painted the scene quite as well as Jeremy did:

In the world of web development, there are many choices that are commonly presented as true or false, black and white, Boolean, binary values, when in fact they exist in a grey goo of quantum uncertainty.

What prompted my thoughts on the subject (at least recently) was a post on Simply Accessible entitled Speed vs. Accessibility. In the post, Derek Featherstone tells a story of someone who went so far as to change their markup, in a manner that made it significantly less semantic, in order to save a few bytes in file size and therefore improve performance. The result? They saved about 50 bytes, but lost contextual meaning and reduced accessibility. This lead Derek to ask if it had to be speed or accessibility (by the way, the answer is no—they can coexist).

The truth of the matter is, web development is a series of trade-offs. Sure, some best practices overlap between say, performance and accessibility. Many, however, do not. To make an educated decision requires a healthy level of knowledge both of the project being worked on, and of these concerns (semanticity, accessibility, performance, etc.) and their implications. Knowing what is most important to a project will give you a roadmap to follow when you inevitably have to decide which trade-offs to make.

It’s for this reason that I give little credence to the many one-sided argumentative posts you will see online. The goal should always be to be as semantic as possible, but you should also strive to be as performant, as accessibile and as well designed as possible. For example, anyone who reads my blog knows how seriously I take performance. In my opinion however, I would never be willing to adjust my markup as the person in Derek’s story did in order to shave a few bytes of my HTML. I may be a performance zealot, but to me, having a well structured page is the base from which I prefer to build off of. I believe a well marked up document provides the ideal starting point for optimal semantics, accessibility, performance and maintainability. This means that my sites will never be quite as peformant as they could be and I’m ok with that. I’ll do my best to optimize my site in ways that I think maximize my gains and have a minimal negative impact on my markup. There are many far more effective ways to optimize my site without having to pay such a steep price.

So by all means, find something you feel strongly about—learn about it, share your knowledge with others, become a strong advocate for it, but always remember that web development requires a balance. Find a solid base to build from, determine the considerations most important to the project and always keep those in mind as you make your decisions about what trade-offs to make.