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.