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.
This article perfectly articulates a growing feeling I’ve had about this subject for a while.
Couldn’t agree more. I think we can look forward to a simple and elegant web.
You hit the nail on the head with this line: “Without the word “mobile” in there somewhere, how could we prove that we’d gone through the elaborate hazing ritual of mobile web development…”
Hard to give up the badge of honor. 😉
And yes, just ‘web’ is far more simpler. (Hopefully it won’t morph into ‘Web 3.0’!)
Couldn’t agree more. The web’s level of complexity has become ridiculous. Focus on content, communication, performance, and utility to the user etc, vs fancy design (or risk your sanity and budget).
I do like the fact that the digital ecosystem necessitates this approach.
Bravo. Great post.
Agreed! Sticking with progressive enhancement as a foundation principle has meant for me that polyfills aren’t necessary. Browsers that can handle “more”, get “more”. Those that can’t, don’t. That requires a bit more thought up front. Building out the site and browser testing along the way are a lot less painful when I don’t force something on the browser that it deems unnatural.
Great article. Very much agree with you and the other comments here. Thanks!
Amen. I need to think more like this and will do from now on.
Great article.
Let’s just focus on the content first, and enhancing the experience on browsers that can handle more.
Great article. I particularly agree about making a distinction between important details that will make an impact and the frivolous time-wasting details.
I’ve also experienced the situation where code is tweaked for a specific device with no thought about what impact it could have elsewhere.
I also learned a new word: ‘Bailiwick’.
Sometimes just getting things done beats all of the extra conversations any day.
I agree. always make your do do have impact 🙂 The less do do the better. Keep it simple!
I totally agree. I almost felt like I was over the hill and not smart enough to do this job any more. The real trick, though, is convincing the designers and particularly the managers and clients… As Jacey Gulden says, (https://medium.com/p/270048a88c70), responsive design is a matter of Process, it’s not something you can tack on during development without going crazy and busting your schedule and budget. That’s one strong reason I like designing in the browser now, is it never leaves a chance for the developers to be blindsided with a slew of overly-complex, desktop-only designs and only a few weeks to build and launch the site…
Totally agree. Simplifying is always the answer, otherwise the complexity will become ridiculous, it already is. I think part of the problem is being too rigid with how the design looks on different devices. I think the the point would be to have a working, usable site on every device instead of arguing about pixel differences and letter spacing on no name smartphones.
I’ve never been a web developer, I’m a software developer who uses web technologies. There are other codekits out there you can dabble in if you are having trouble making this distinction. dotNet (windows), cocca (osx, ios), and html/php (web) are the 3 major kits of the day, with a splash of opengl thrown in to each.
You are obviously on to something here and in some regards, going back to basics, and I mean very basics, the initial spec for HTML was quite responsive and device independent. In the beginning you could use mosiac or navigator or lynx even and the web experience was virtually identical. It wasn’t until the dawn of Javascript, DHTML, CSS, Flash and more that we had to differentiate platforms. Hours were spent making a page render identically in IE and NN. It seems like the diversity of platforms is almost as challenging as the maturity and diversity of the technology we use and we forgot that simpler is better and less is more. Thank you for your insightful article.
Good points raised here. It’s hard to let go of old (bad) habits, but we’re now paying for our own hubris. Web designs were always meant to be fluid, but as desktop screens became larger and larger, we simply added negative space and positioned with pixels. The lack of frivelous visual embellishment and use of relative measurements are somewhat of a throwback, really.
Adam,
I’m not really up on my web history, but I disagree that web designs were always meant to be fluid. And, assuming that they were originally meant to be fluid the question for me is should they be fluid?
If the web can be seen as a tool that’s in the service of the human desire to communicate (at least remotely) with one another then I think it would be a good idea to look at the visual component along with the content component of this tool.
Here I sit in front of this screen for at least eight hours a day. It’s true that I’m receiving impressions that have to do with how another person has arranged a series of words (i.e. content) to convey an idea or emotion.
But, it’s also true that I’m receiving impression that are purely visual. A block of text communicates verbally, but it also reaches my eye as a text-ural shape that has a visual relationship with it’s surroundings.
The notion that visual/compositional relationships have a strong ability to communicate has been understood for thousands of years, and I find it supremely arrogant on our part to think that, in the space of thirty years, we can cook up a new and improved communications tool (called The Web) that ignores visual form.
So the tables are turned, and we as humans now find ourselves serving the Web, and scrambling to keep up with this technocratic network that (each Fall season) produces every kind of screen size, screen proportion, and screen resolution under the Sun.
Many of these technocrats even go so far as to try to persuade me that their approach to web design is very much in alignment with Daoist sensibilities. After all, Daoists are unquestionably known (???) to be very fluid in their dealings with others. In light of this assumption about how a Daoist would do web design there seems to be this push to develop something that we refer to as Responsive Web Design. But, there’s a certain irony to this responsiveness that we’re advocating because it seems to involve a great deal of Automation. So, now we have a Daoist that both fluid and automated! A kind of cyber-Lao-tzu. On the other side we ourselves seem reluctant to take a certain Responsiveness and Intentionality upon ourselves with regard to developing visual relationships into what might truly be called a visual compositions.
The question for me is not so much about getting stuck on print layouts versus web, but about whether the web will grow to become a tool for verbal communications only, or a tool for verbal and visual communication together. If the ruling majority decides to go down the first of these two routes then I would propose that we stop referring to ourselves as web designers as it sounds too artsy. A better name might be “content management specialists”. I believe that the web needs to maintain a spark, and I don’t think that it can be maintained without some form of visual design.
Nor do I think that visual composition should be belittled with the industry-specific word of “style”. By “visual communication” I’m not referring to a kind of stylistic frosting that we find in the ever popular world of website “themes”. Instead, I’m referring to a deliberate attempt at creating a sort of “visual body language” that can be arranged upon a two dimensional surface (be it paper or pixels), and which complements the verbal content.
Paradoxical as it may seem, this visual body language can only happen when compositions are fixed, and not fluid. Pictographic “gestures” don’t communicate intentions in a visual way, when all of our divs are float:left;
Thanks for the thoughtful article!
A timely reminder that less is more. Always has been, always will be.
Excellent. Moar please @lyzadanger.
Couldn’t agree with you more, I come from a graphic design background and now I am a UI designer. I like this simple and great usability direction! Great Article! More pls!
Amen! More time on content and design. Less time on hacks.
Back in the mid-1990s, my catchphrase for designing flexible websites was “I want it to work when I get a web-enabled pocket watch.” At the time, too many web designers put notices on their pages like “best viewed in Netscape 3.5 or later” or “best viewed in IE 5.” Meaning it wouldn’t work in the other popular browser, and wasn’t usable at all with lynx or a screen reader.
Then I got me a web-enabled pocket watch (with phone!) that didn’t even require the funny phone-only XML of other pocket watches. My websites worked fine. (Usually.) And oddly enough, many of the oft-ignored rules of yore were once again important: no plug-ins, avoid browser-specific hacks, separate content from presentation (Sir Tim’s cardinal rule), keep page sizes small.
Some rules age well. Our phones have better browsers than old computers– even for viewing content designed for those old computers. Wireless networks are much faster than dial-up. And content is always more important than presentation.
But I suspect we’ll be going through this exercise again. Once we’ve gotten used to designing for small screens, the screens are going to get smaller. Monocles or bracelets or charms. Once we’ve forgotten to reduce memory and bandwidth overhead, once the last patch of Antarctica has mobile access, we’ll colonize space and discover just how bad network lag can get.
And yet Sir Tim’s first web page, circa 1991, will still render fine on my e-thumbnail, if I can wait 8 minutes for the message to reach me from Earth.
I’m looking forward to that.
Great article: The “less-is-more future” web is an appeal for simplicity and elegance.
Totally agree, great article.
I think that, as far as we go towards a future with more and more devices, we can’t be crazy enough to think that we can cover every screen size and particularities about all rendering engines available.
So the “less is more” is the best approach, since mobile first and progressive enhancement are getting more and more important on our workflow.
You make some good points and I completely agree with the do less way of thinking. I have worked on a couple of projects where I have spent the majority of my time making a site look perfect on every device and screen size. It was a good learning curve for me and I gained some valuable skills but I can’t help feeling like it was unnecessary.
Do less is definitely the future.