In the last year or so, “Responsive Design” has become quite the buzzword. It’s not just industry jargon or a little article on A List Apart anymore. Project managers, business analysts, salesmen and marketing executives are tossing around the term “Responsive Design”. Heck, a year ago I was explaining the concept to an executive, and now executives are asking for it by name. I’ve even heard of executives asking where the “Responsify” button is in Tridion. Now that Responsive Design has become a buzzword, I’m seeing its meaning and intent get distorted. So, I’d like to offer a gentle “realignment” of where “Responsive Design” fits in the web experience.
A Step into the Past
Before we get into why Responsive Design isn’t the (complete) answer, let’s get historical. A brief glance at the history of the web can help us understand how Responsive Design is all the craze these days.
How old are the languages of the web?
The first web browser came out in 1990, and HTML came out in 1991. CSS, the language that styles the web, came out in 1994.JavaScript joined the crown in 1995. HTML is now in its fifth version and is just barely old enough to drink. CSS was still underage when media queries became recommendation in 2009. JavaScript was finally old enough to buy cigarettes about two weeks ago.
How old are smart phones?
The first public cell phones became available in 1983. Text messaging came a decade later. The first commercial phone with a web browser came in 1996. The first phone with an HTML browser came in 1997, and the iPhone came 10 years later in 2007, with web-friendly Kindles and iPads coming a mere three years later.
Cell phones are old enough to buy houses, text messages can’t drink, smart phones can’t drive and tablets can’t keep a dry diaper.
So…what’s the point?
Web technologies and mobile devices have been evolving separately, but symbiotically. Phones and technologies are two wings of a plane —one doesn’t linearly influence of the other as much as both influence the livelihood of their passengers.
The web is too immature, smart phones are too young, and tablets too new for us to treat Responsive Web Design like it’s the complete answer to the problem of “non-desktop browsing” when we haven’t been browsing on non-desktops for too very long.
Media Queries
What do they have to do with responsive?
CSS is the language that styles HTML; it makes the web pretty. In the latest version of CSS (CSS3), a new module was introduced called Media Queries.
Media Queries are a thing that we can now put in stylesheets that allow us to query the medium with which you’re viewing the web page. A media query can detect the height, width, resolution, orientation, and even the aspect ratio of the thing you’re using to view a web page. What’s so revolutionary about the media query is that, in the past, we had to do this with JavaScript or another programming language. Now, we can find out height, width, and even whether it’s a black & white display in the stylesheet, without programming.
Media queries were, and still are, pretty darned revolutionary.
A dab o’ history
CSS3 brought the “media queries” module into recommendation status in 2009 —two years after the iPhone was released. In 2010 Ethan Marcotte wrote his ground-breaking article on the practical application of media queries as “responsive design”. But the first draft of the media query specification? Written in 2002. The original concept? Dreamed up in 1999 —as a way to possibly deal with layouts on screen, print, and fax. Check out this introduction from one of the memos that was written pre-specification (emphasis mine):
A number of Internet application protocols have a need to provide
content negotiation for the resources with which they interact [1].
A framework for such negotiation is described in [2], part of which
is a way to describe the range of media features which can be handled
by the sender, recipient or document transmission format of a
message. A format for a vocabulary of individual media features and
procedures for feature registration are presented in [3].
The media query was thought of as a content negotiation, not a design fix
The media query as a mobile solution
When Ethan Marcotte wrote his article on Responsive Web Design, He hadn’t drifted far from the original idea of the media query:
In their book Interactive Architecture, Michael Fox and Miles Kemp described this more adaptive approach as “a multiple-loop system in which one enters into a conversation; a continual and constructive information exchange.” Emphasis mine, as I think that’s a subtle yet powerful distinction: rather than creating immutable, unchanging spaces that define a particular experience, they suggest inhabitant and structure can—and should—mutually influence each other.
Marcotte is clear that the media query was a means to break free from a static space. Instead of the space defining the experience, he suggests that the space and the content respond to each other. He also made it clear that Responsive Web Design does not necessarily address the goals of the end-user:
Rather than quarantining our content into disparate, device-specific experiences, we can use media queries to progressively enhance our work within different viewing contexts. That’s not to say there isn’t a business case for separate sites geared toward specific devices; for example, if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.
Responsive design is meant to keep content from getting pushed into a disparate experience —when it’s unnecessary to do so
Responsive Design isn’t the complete answer
When we look at the history of the web, the media query, and Ethan Marcotte’s own words, we see that responsive design never originated with mobile in mind, nor is it meant to solve a mobile problem. Responsive design strictly solves a design problem.
What Ethan said…
if the user goals for your mobile site are more limited in scope than its desktop equivalent, then serving different content to each might be the best approach.
responsive design doesn’t make your content more relevant
Responding to end-user goals
Responsive design just makes content look better in smaller screens. It takes no consideration of the fact that the end-user’s goals might be drastically different.Let’s take my favorite example of a restaurant website:
On a laptop or tower, the end-user may be more interested a reservation or reading a menu. On a tablet, that same user might be more interested in the menu and how to place an order. On a phone, the same user might care more about getting to the restaurant or calling them. Three different devices, three different goals. A responsive design makes the restaurant menu smaller, but does it make a map display on the homepage?
I’ve logged plenty of hours making carousel sliders fit on mobile phones, but exactly zero replacing sliders with something more relevant.
The Rest of the Answer
I don’t yet have the whole answer. What I do have is a solid understanding of one half of the answer. Responsive design makes sense, so long as the content does, too. But historically, we’ve been okay with changing the content to the website.
M-dot websites aren’t totally wrong
When you change the content of the page, you’re closer to the old-school way, which I call the “m-dot” approach: m.somesnazzywebsite.com. The m-dot approach is where you have a separate website with separate content, a separate design, and even separate URLs. If you think about the purpose of a website —that you have a collection of similar content that drives to a similar goal, how is this bad? If you would have a .org for the non-profit division or a blog. for the blog —then how is it wrong to have an m. website when that content is focused specifically on mobile?
M-dot websites still aren’t right
The downside to the m-dot approach is that, unlike your .org website, the content is meant to be similar to a desktop site. It’s not totally unique content, it’s …similar content. Content authors, understandably, don’t see the value of two websites, two designs, two publication targets, and …two versions of the same content. This is why responsive web design saves the day.
Responsive…what, then?
Where responsive web design is right is that it makes the content fit on a variety of screens. Where m-dot strategies are right is they make the content fit for the user. Maybe this is why Ethan Marcotte said,
This is our way forward. Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience.
“facets of the same experience” doesn’t mean you should have just one experience
Responsive Experience
Responsive web design makes sense, so long as the content does, too. But what if the priorities have shifted? What if there are new goals? What if, and God-forbid this be true, that a design is for the content, and not the other way around? What if Marcotte is still right that the goal of responsive web design is to make our designs facets of the same experience? Doesn’t that imply that we still need to provide multiple experiences?
I’m not proposing that we isolate the experience to a single type of device. Instead, I’m suggesting we offer an experience to a collection of devices. Desktops, tablets, phones can all offer unique experiences. And if we’re grouping the obvious experiences together, how about the not so obvious ones like game systems and televisions? Aren’t these all unique ways to experience a website? Couldn’t the content priorities be different for each of these users? Do we have to define the experiences by the inputs (i.e. gamepad, keyboard, touch)? No, but it’s certainly an approach that we can take. The input certainly influences how a user accesses content, which can affect the content priorities of that user.
Maybe an insurance website should provide a load of different goals on desktop, but be focused on logging in and making payments for tablets. Perhaps that same website helps you file a claim or find an adjuster on a phone. Maybe on a TV or a game system, it helps you insure your electronics. I’m not proposing that the content in one experience be inaccessible from another. I’m suggesting that the content be presented to match the priorities of the user.
The technical side of a responsive experience
I don’t want to dive deep into the technical approaches of the responsive experience. Instead, here are some high-level technical requirements that I’d propose:
- The CMS should deliver content dynamically, not statically
- An MVC framework is necessary
- Content should be stored with a taxonomy
- The taxonomy should classify content along the type of experience
- device detection should occur server-side
- content delivery should occur server-side
- Within each experience, or class of devices, there should exist a responsive design
TL;DR
Responsive design isn’t the whole answer. The originators of the media query didn’t intend it to be a mobile solution, and Ethan Marcotte never labeled it as one, either. Neither the history of media queries nor that of cell phones, suggests that responsive web design is the entire solution for mobile.
Instead, responsive web design solves a design issue, plain and simple. Content does not become more relevant with responsive design and user goals are not more easily accomplished because of responsive design. A user visits a website for the content, not its presentation.
We need a solution that allows a website’s content and its presentation respond to the needs of the user.
FYI:
A few months back I was in an SDL Tridion 2013 Bootcamp and I got a presentation for SDL Mobile. The SDL Mobile solution aligns with the Responsive Experience that I’m proposing – so much so that I thought SDL had hacked my brain. I am sure that there are other Responsive Experience solutions out there, but SDL Mobile is the only one which I know by name. If you know of other existing Responsive Experience solutions, post ’em in the comments.
Permalink
Great post, thank you for writing it. You haven’t really touched on it here, but experience is proving that all-in-one websites tend to have much larger page weights and are much slower to load, to the extent that some websites which should know better are serving megabytes of content and taking over 20 seconds to load for a simple page on an iPhone (unoptimized image assets and large numbers of external Javascript calls being the biggest culprits, but also redundant codepaths and invisible elements contributing to a slow render time).
Delivering modified experiences to device classes is thus mandatory for acceptable performance in most cases: not only “best practice”, but “the only acceptable practice”.
In addition, given the huge number of tablets and the inability of Media Queries to properly identify Tablets and TVs from mobile devices purely by screen size, Device Detection really is very important.
Permalink
A good article, but I have to disagree with two of your technical axioms… Device detection and content delivery don’t necessarily need to occur on the server side.
I have a system that accesses the same content from the server (as raw DITA), and on the client side transforms it into HTML for the request. I can modify the transform before executing it, so I can respond to client-side status when deciding how to present the content. And so, for example, I can filter content depending on user role. And not only content, but I can also filter the search database with the same mechanism, so search “just works” with the filtered content. This is just a single, small example. And it all happens on the client side.
Now, I guess I could use the server to determine the user’s role. But this is for product docs — the product client already knows the user’s role, so I actually get user role on the client side. Maybe technically it comes from the server, but by the time I’m interested in it it’s on the client. I don’t see why device information can’t be detected on the client side as well.
Permalink
I don’t think we have to disagree on that point. I believe that device detection and content delivery can both happen on either side. I think that what’s needed is the proper blend of device detection, content delivery, and feature detection. It’s the blend that’s the biggest challenge. What’d I’ve envisioned is the server-side doing device detection to determine the class of devices (possibly determining the views), and then some client-side feature-detection to determine user interactions (touch vs. keyboard), and then media queries making ONLY the right thing fit on the right screen.
I have a pretty solid idea of how I’d want to put this together on a node.js server with angular.js and mongoDB. I don’t know if I could tell you how this would work in more traditional MVC frameworks, though. But, suffice to say, we don’t have to disagree on where to put delivery and detection.
Permalink
Yes, I think in fact we’re in violent agreement about the need for dynamic content production, in response to the given request. It’s a matter of implementation details when you talk about server- vs client-side processing to produce the response. I’d only say, don’t limit your view to server-side processing. It can be done on the client side, and I *am* doing it on the client side. For some circumstances, there’s value in doing it on the client. But I don’t think that amounts to any meaningful disagreement at all.
Permalink
Superb history!
Nit: Did you mean “crowd” not “crown”?