That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.
It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0.
If you use a CSS feature that isn’t supported in a particular browser—like, say, an older version of Internet Explorer—that browser will simply ignore that CSS rule. So you don’t get that rounded corner, or text shadow, or whatever it was. Browsers have the same error-handling mechanism for HTML: if they see something they don’t understand, they just ignore it. The browser will not throw an error. The browser will not stop rendering the page. Browsers are very liberal in what they accept.
Anyway, my point is—and I can’t believe I still have to repeat this after all these years—websites do not need to look exactly the same in every browser.
“But my client!”, cries the Smashing Magazine commenter, “But my boss!”
If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.
It’s like Mike Monteiro says about clients: if they just don’t get something about your design, that’s not their fault; it’s yours. Explaining your design work is part of your design work. It’s the same with web development. It’s our job to explain how the web works …and how the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.
That was true fourteen years ago when John Allsopp wrote A Dao Of Web Design, and it’s still true today. Back then, designers and developers were comparing the web to print and finding it wanting. These days, designers and developers are comparing the web to native and finding it wanting. In both cases, I feel like they’re missing the fundamental point of the web: you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.
Paul Kinlan published a post called This Is the Web Platform where he tabulates the current state of browser support for various features. “Pretty damning” he says:
the feature support that is ubiquitous across the web is actually pretty small especially if you are supporting IE8.
That’s true …from a certain point of view. But it depends on your definition of “support”. If your definition of “support” is “must look and work identically to the latest version of Chrome”, then yes, you’re going to have a smaller set of features you can use (you’re also going to live a miserable existence). But if your definition of “support” is “must be able to access the content and accomplish the task”, then as long as you’re using progressive enhancement, you can use all the features you want and support Internet Explorer 8, 7, 6, 5 …you can support every browser capable of connecting to the internet.
There is a difference between support and optimization.
I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.
It’s a subtle Lakoffian thing, but when we talk about “the browser” as if it were a single entity we might be unconsiously reinforcing the expectation that there is one Platonic ideal of browser rendering and that’s what we’re designing for.
There’s another phrase that bothers me, and it’s the phrase that Paul used in the title of his article: “the web platform”. This is something I talked about back in November in my presentation The Power of Simplicity:
But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.
I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.
What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.
And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.
And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.
The web is not a platform. It’s a continuum.
But I can’t. Something went wrong. You see, Vine’s video pages are built in a way that expects everything goes off without a hitch. The web browser will receive all the necessary assets in the necessary order and execute everything exactly as the developer intended. Unfortunately, that’s not the way the Web often works.
(For those curious, I was using the most up-to-date version of Google Chrome on a MacBook Air running the latest operating system on my home’s broadband Internet connection. Pretty optimal conditions, right?)
So I post about it on Twitter. Friend and colleague Helen Holmes saw my post and kicked off a lengthy back-and-forth that convinced me to commit my thoughts to the page. I’ve been meaning to write about this particular topic for a while and here’s what’s been rattling around in my head.
The Web is a Continuum
The way Vine’s video pages are built illustrates the fault in thinking of the Web as a platform. Platforms are static, defined software environments responsible for running neatly packaged bundles of code: a downloadable native app, an installable desktop application, a Flash movie. iOS, Android, Mac OS X, Windows, Flash—these are platforms.
This is not the Web. Rather, this is not today’s Web. Today’s Web is a continuum.
That right there highlights the problem with thinking of the Web as a platform. Something will go wrong, even under nearly ideal conditions. And when something inevitably goes wrong, what happens to your website? To your users?
What are we to do? How do we design for hostile browsers?
Nearly a year ago, I likened the Web to a layer cake. A delicious metaphor, to be certain, but not entirely accurate. In the intervening eleven months, I’ve thought back to that post and the metaphor’s shortcomings. I think I’ve cracked it: The Web is experience layers, built from the bottom up, with each successive layer enhancing the previous.
Designing from the Bottom Up
In his book Responsive Design Workflow, Stephen Hay details his process for designing in text. The entire book is worth your time, but you can read this particular chapter for free online. Stephen also detailed this technique as well in his presentation at Mobilism back in 2012.
Stephen advocates a content-first approach using plain text. The emphasis on content is critical: everything in your interface is content whether it be the text of an article, the navigation, or control elements like form inputs. It’s all content and it all needs writing.
I love this content-focused approach to design. It just makes sense.
Moving up a layer from plain text, Stephen recommends the popular Markdown text formatting syntax. Markdown is a simple set of formatting rules for describing common text components such as headings and lists and maps closely to the elements in HTML. Awfully convenient. There are a bunch of great Markdown editors available—I use Byword—and every one of them will easily convert Markdown documents to HTML.
Now that you have an HTML file full of well-structured content, you can begin layering on design. This is where existing design tools and techniques like branding guidelines, style tiles, and Photoshop mockups are most useful. The HTML generated from Markdown is barebones, so you’ll want to add additional structural elements as necessary to accommodate your website’s visual design.
This is, to a degree, designing in the browser. I urge you, though, to think of it as designing with the browser. Use the browser as you would every other tool at your disposal.
A Progressive Experience
If you’ve read this far and thought, “Why, that sounds like progressive enhancement,” you’d be correct! Progressive enhancement is the best strategy for building for today’s Web. With so many people connecting to and interacting with the Web on a mind-boggling number of devices of varying screen sizes in an infinite array of circumstances, it’s critical to design layers of experience. Any layer atop another should serve to enhance the base-level experience of the previous. The essential functionality of the base layers should continue to function smoothly in the absence of higher-layer enhancements.
Approaching design through the lens of experience layers is the design strategy for the Web; one that’s better for users and designers alike.
Many thanks to Trevor Davis for reviewing an early draft of this post.