I make websites for mobile phones. Or, at least, that’s what I used to say.
Nowadays, it’s complicated. Builder of websites and applications that, with minimal exception, work decently well on nearly every kind of physical thing that is web-enabled doesn’t fit well into the OCCUPATION box on tax forms.
Explaining my job is complicated because the web itself is complicated. It’s already a spicy, mysterious dish, cobbled together with some questionable ingredients. It’s hard to say just what we’ll have on hand tomorrow—or how we’ll be able to satisfy all of the fussy devices joining the feast.
The mobile web was the future#section2
A number of years ago, we joined hands and felt the sun on our faces and chanted “The mobile web is the future!” and went off to build it.
We started by (mostly) making and maintaining separate mobile websites. That sometimes felt cumbersome, and so we learned about Responsive Web Design and felt better that we were merely making and maintaining separate mobile web layouts. We started talking about swipe gestures in public. Then tablets happened. Eh, we thought, we can still handle this.
Then some thoughtful people started realizing that, perhaps, treating the mobile web like this Big Separate Thing might be counterproductive. Jeremy Keith, for example, proposed that “There is no Mobile Web”, which at the time seemed like a big old buzzkill. We had skills. Mobile savvy. Right?
Reverting back to the shorter title of regular old web developer was scary. Without the word “mobile” in there somewhere, how could we prove that we’d gone through the elaborate hazing ritual of mobile web development and in fact were still showing up every day for more beatings?
Not all of this was posturing. There were legitimate things that differentiated what we were up to from “traditional” web development. We’d learned a lot. Chucking out the new special sauce of mobile-tailored sites and apps in favor of a vanilla, lowest-common-denominator web? That would be silly.
But once we started to question the terminology, it was easy to get coaxed into dinner party arguments: What makes something mobile? What is the mobile web? What is the web, anyway, really?
My efforts to find a replacement for the word “mobile” haven’t amounted to much more than semantic air freshener: cloying, artificial cover-ups. I’ve used such stinkers as pan-device web. To get around describing how adaptive layouts look “on phones,” I say even lamer things like “in narrow-screen environments.” Barf.
Yet I don’t think it’s too grand to say that some of the trends that emerged from pioneering mobile web development represent the future of the entire web. Devices everywhere. Different displays, different inputs. Complexity. Integration of hardware characteristics. Even less control over the ultimate representation of our content.
Welcome (back) to the World Wide Web#section3
So, let’s say it’s just the web again, now. No extra adjective needed. But it’s not the old Web, it’s the future Web. It’s changed. It got a summer job, went off to college, got sophisticated.
Looking at this new web and seeing beyond the specificity of the mobile web, or at least seeing it as an extension of the web, allows us to shore up some of the more fragile foundations we’ve laid and find ways to build the web that make a bit more sense.
Because the detail- and hack-heavy way we’re coming at this browser and device explosion will not scale. It has already broken down. Building a basic web page that works on a whole lot of devices has become in many ways a time- and soul-sucking morass of polyfills and workarounds. We sometimes spend more time tracking down why web fonts are spitting out garbage on a particular BlackBerry than creating and honing meaningful content.
Do as little as possible#section4
Instead, I think we need to try to do as little as possible when we build the future web.
This isn’t a rationalization for laziness or shirking responsibility—those characteristics are arguably not ones you’d find in successful web devs. Nor it is a suggestion that we build bland, homogeneous sites and apps that sacrifice all nuance or spark to the Greater Good of total compatibility.
Instead it is an appeal for simplicity and elegance: putting commonality first, approaching differentiation carefully, and advocating for consistency in the creation and application of web standards.
Getting to this less-is-more future web involves, in part:
- Integrating what we’ve been learning on the mobile web—“mobile first” design practices, performance focus, progressive enhancement, and, yep, Responsive Web Design—into the future of our overall web crafting toolkits;
- Understanding the difference between inspired details and distracting minutiae, and assuring what we do do has impact;
- Introducing less risk, or managing the risk we introduce—because each workaround or device-specific tweak we make introduces risk;
- Putting more oomph and involvement behind our requests for the reliable support of web standards in browsers and across platforms, while making sure we’re learning and using the web standards we’re asking for; and
- Realizing when things aren’t in our bailiwick and getting ourselves off the hook for every technical eventuality.
Am I asking you to eschew everything unique about mobile (or other) devices in favor of cramming a one-size-fits-all blah webbiness into everything with a browser on it?
Nah. The do-less future is not about creating a great dumbing down, but instead making sure the pile of technical tasks required to get a decent site or app out the door doesn’t smother us entirely.