Corresponding on Responsive Design

We’ve been seeing and participating in discussions quite a lot lately about responsive design, the mobile web, how native apps fit into an overall web strategy — with clients, in blogs and comments, and most recently in an email exchange with Jason Rhodes, primary developer at Johns Hopkins University.

In these exchanges, I responded with some opinions we’ve started to formulate here at FG (particularly as we’re heads-down on several responsive “one web” projects, including an eventual redesign of our own site) that I wanted to share with a wider audience. Happily, Jason agreed to let me excerpt his email (thanks, Jason!). Here’s the gist of our exchange:

It started with a post by Paul Boag called ‘Making Mobile Mistakes’, in which he argues in favor of custom mobile websites (separate from standard desktop sites) that provide limited content for ‘the mobile context.’ I responded in the comments, and soon after received an email from Jason:

JR : I read that Boagworld post, and I agree with comments by you, Stephanie, and Jeremy… I’m extremely uncomfortable making assumptions about what the user wants to see based solely on the device they’re using. Smells like UA sniffing when what we want is something more akin to feature-detection…

I recently started a job as primary developer for Johns Hopkins
University, and our Director of Digital Strategy and I have been
doing a lot of thinking about our "mobile strategy" for the
university. Basically, people want an app. There's the cool factor,
having an iPhone and Android app in the market is going to appeal to
hip/trendy students, or so the traditional thinking goes. And then
there's just regular website mobile strategy: even if we contract
apps, how do we optimize our current websites for viewing on mobile?

Do you think there are scenarios when a native app is the best
solution, and how would you make that decision? Also, how would you
try to convince a client to get away from and rely on
CSS/JS responsive techniques instead? Are there other content
optimizations (similar to [the image size stuff you guys have been
that can work alongside the layout optimization that we now have
with @media queries?

SJ : We’ve been hearing this a lot lately, too: Organizations want exposure in app stores (or at the very least the major ones for iOS/Apple and Android), but they’re not thrilled with the prospect of developing and maintaining content on separate platforms and in different codebases. They’re unsure of how the apps fit together in their overall strategy. The one thing they do know is that their existing web experience is too desktop-oriented and isn’t serving their mobile audiences appropriately.

I think relying *solely* on User Agent sniffing and content
negotiation as the basis of your entire web strategy is not very
sustainable, or forward-looking. Even if it were technically sound
(i.e., if there were no User Agent detection issues, such as
spoofing, or user preferences that deviate from defaults, etc.), the
entire concept still rests on the notion that all browsers and
devices are known, and we can cater to each one based on its known
set of capabilities. But the web moves very, very fast: each time a
new device hits the market, a device database needs to be manually
updated with information about how to cater to that new device's
default capabilities. It's a constant game of catch-up.

And technical issues aside, simply redirecting users of a certain
device class to a separate site assumes an awful lot about what
users want based only on their browser. I constantly encounter sites
that default to delivering very limited content based on a 'mobile
context': that is, if I'm on a phone I must be in motion with
limited attention: quickly looking for directions, contact info, or
a very limited set of most recent content.

But a smartphone or other 'mobile' device is just as likely to be
stationary and tethered to high-speed connection as on the move — I
know lots of people, myself included, who use an iPhone or iPad to
surf the net while watching TV in my living room. And, a
high-resolution laptop can easily be slurping the painfully slow
wifi on a bus to New York.

This is all to say that we agree entirely with [Mark
Kirby](, [Jeremy
Keith](, [Mark
Boulton](, [Stephen
and others, that there is no singular, *reliable* mobile context.
And if you agree with this premise, we recommend reframing the
question of your mobile web / native app strategy: just as on the
desktop, the demands of your site's content and functionality should
drive its implementation.

Of course, there are some scenarios where a native app may be the
best choice: a highly interactive game is one example. There may
also be cases where a client or company wants to limit delivery to a
very tightly-controlled audience, and selling exclusively through an
app store and targeting a specific device will offer that type of
limited access.

But if the project goal is to reach as broad an audience as
possible, a web-based app or site that works on a truly broad range
of browsers and devices is the most findable and accessible format
you can offer users as a whole.

For a universally accessible web-based approach, I'd recommend the

-   As a baseline, I'd highly recommend a mobile-first responsive
    approach: markup and content should be lean, essential, and
-   CSS should be constructed with fluid layouts, using the mobile
    presentation as the default full-width default, and using
    min-width and max-width media queries to adjust the presentation
    (and potentially behavior) at various breakpoints all the way up
    to desktop resolutions. The fluid layouts are particularly
    critical here, since the breakpoint widths themselves can't
    possibly offer a perfect fit for every device and window
-   While HTML source order imposes some limits to how much we can
    change presentation of content, we've found it's quite feasible
    to shift content hierarchy, collapse unwieldy navigation into
    menus, and even flip content out of its source order -
    horizontally and sometimes vertically - when it's advantageous
    to do so.
-   If your primary reason for having a native app is exposure in
    the app stores, there are great tools for wrapping your
    already-functional web experience in a native application's web
    view. [Phonegap]( and [Titanium
    Appcelerator]( are two that come to
    mind. They also offer APIs to tap into native capabilities, such
    as the device's camera for instance, that can't be accessed from
    the browser alone (yet at least). This approach allows you to
    exhaust all possibilities with web technology which you can
    deploy through the browser before moving on to native, and we
    think that makes a lot of sense. I believe Netflix uses this
    model for their apps and website with great success.

While it's understandably a big undertaking, we believe that a
single, device-agnostic website that's built with a lightweight,
responsive-design approach is the most accessible and maintainable
solution in many cases.

With any luck, we'll soon look back at this practice of assuming
which content a user on a mobile device wants as one of those naive
and awkward stages in web designer history — like those days when we
were positive that users would be enthralled with Ken-Burns-style
Flash intros. :P

All blog posts