Corresponding on Responsive Design
April 2020 note: Hi! Just a quick note to say that this post is pretty old, and might contain outdated advice or links. We're keeping it online, but recommend that you check newer posts to see if there's a better approach.
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 that 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 m.mysite.com and rely on CSS/JS responsive techniques instead? Are there other content optimizations (similar to the image size stuff you guys have been working on)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 Hay 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 following:
- As a baseline, I’d highly recommend a mobile-first responsive approach: markup and content should be lean, essential, and compelling.
- 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 resolution.
- 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 assumingwhich 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