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?
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.
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 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 .
A framework for such negotiation is described in , 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 .
The media query was thought of as a content negotiation, not a design fix
The media query as a
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.
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 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
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.
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.