Andy recently published 320 and up, a fork of Mobile Boilerplate that inverts his previous boilerplate media queries i.e. now it starts with the small-screen styles and layers on the styles for larger widths, rather than beginning with larger-width styles and nullifying them for smaller screens.
This is definitely the best way to apply width-specific styles, be it with media queries or with JavaScript. But I get a little nervous when I see pixel values that correspond to specific device widths: 320 pixels, 480 pixels, etc.—it’s certainly an improvement on relying on one mythical width like 960 pixels, but I worry that it still means crafting the display of content to match the dimensions of currently fashionable viewports. This is what Mark describes as the “canvas in” approach:
It’s my belief that in order to embrace designing native layouts for the web – whatever the device – we need to shed the notion that we create layouts from a canvas in. We need to flip it on its head, and create layouts from the content out.
Now it may well be that your content is pixel-based—images or video perhaps—and the dimensions happen to correspond to the viewport widths of specific devices, but in my experience most of the content I deal with is still very much of the written word variety …and pixels aren’t necessarily the best unit for dealing with text. That’s one of the reasons why I tend to use em-based media queries.
My basic point is that it should be the content that dictates the media queries. For some sites, it might be appropriate to only serve up a linearised layout to very small screens while applying a columnar layout for slightly larger devices like tablets. For other sites, tablet-sized screens should get a linearised layout—it all depends on the content.
One of my favourite examples of content-out thinking is Dan’s article on type-inspired interfaces. I think there’s a general agreement amongst web designers that we should be designing from the content out but there’s still an over-reliance on canvas-in tools like predefined grids. Likewise in the world of wireframing and information architecture, when we should be concentrating on the content we often gravitate towards designing the menus and navigation first.
This is something that Luke talked about with Jared recently, mentioning his design principle of “content first, navigation second.”
Luke has famously advocated a mobile first approach to web development, which is a great way of focusing on what’s most important to deliver to the user. But don’t take it too literally. In some ways it would be equally viable to try out “print-stylesheet first” or any other “non-desktop environment first” strategy. The key point is that you’re thinking about the content first and foremost:
Losing 80% of your screen space forces you to focus. You need to make sure that what stays on the screen is the most important set of features for your customers and your business. There simply isn’t room for any interface debris or content of questionable value. You need to know what matters most.
That isn’t to say that you can’t serve up some extra nice-to-have content to wider screens, but that should be added on—possibly with conditional lazy loading—rather than having everything including the kitchen sink thrown in from the start.
Mobile web design has already established a number of excellent best practices whereas traditional “desktop” web design has become the domain of laziness and complacency. The result is a web of bloated documents with buried content, as documented in Merlin’s Flickr set, Noise to Noise Ratio:
Sure. There’s definitely some excellent original work in there — in the middle of all those ads and self-links and chrome and value-added “journalism.”
Yeah. Keep looking. No, seriously. There’s gotta be something in there.
Right?
There’s a general agreement that the “mobile” user is not to be trifled with; give them the content they want as quickly as possible ‘cause they’re in a hurry. But the corollary does not hold true. Why do we think that the “desktop” user is more willing to put up with having unnecessary crap thrown at them?
Unnecessary page cruft is being interpreted as damage and routed around with tools like the Readability bookmarklet, Safari’s Reader functionality, and Instapaper. These services exist partly to free up content from having a single endpoint but they also serve to break content free from the shackles of stifling overwrought containers. This isn’t anything new, of course; we’ve been here before with RSS. But the existence of these new reader-empowering tools should be taken as a warning …and a challenge—how can we design for our content in such a way that the reader won’t need or want to reach for Readability or Instapaper?
Some of the worst offenders in creating bloated content-crushing designs—often news sites—have separate mobile versions, usually at an m. subdomain. There the content is served up without the frills, cruft and pagination of the “desktop” version. I’ve started noticing that when people are sharing links—via Twitter, email, or whatever—it’s often these leaner m. versions that are getting passed around …precisely because they are often easier to read, no matter what device you’re using.
We’ve been here before, as I pointed out in a comment to Paul’s misguided post on mobile design:
In the bad ol’ days, it was common practice to create a “separate but equal” text-only site for screenreader users. It ghetto-ised those users and it was, frankly, a cop out. These days, it’s understood that screenreader users should get the same content as everyone else, but that the site should be built the right way to begin with. (interestingly, some sites noticed that “regular” non-screenreader users were choosing to go to the “accessible” version because it was faster and simpler—there’s a lesson to be learned there for those who still think of desktop and mobile sites as different things)
Needless to say, I disagree completely with this proclamation from Jakob Nielsen:
Desktop computers and mobile devices are so different that the only way to offer a great user experience is to create two separate designs — typically with fewer features for mobile.
I’m perplexed by the reasoning that concludes that if a website is suffering from clear usability issues, the solution is to create a splinter site for some users while leaving everyone else to suffer on. Note that I’m not suggesting that everyone get the same experience—far from it. Thanks to progressive enhancement (and let’s face it, responsive design done right is a perfect example of progressive enhancement) we can serve up the content that people want and display it to the best ability of any particular device.
That’s the key difference: start with the content, not the device.
This is a really exciting time for web design. The increasing diversity of devices is throwing into sharp relief just how complacent and wrong-headed our traditional fixed-width bloated desktop-centric approach has been. As with any period of change, there’s plenty of nervousness too. People are scrambling to figure out how best to deal with mobile devices:
- “Should I be learning Objective-C?”
- “Should I be mastering HTML5?”
- “Should I be learning a mobile app framework?”
You could be doing any or all of those things. But don’t skimp on the content strategy.
Reminder: the usual caveat applies.