It’s pretty amazing how far you can take responsive design these days. Between the latest CSS tricks and a splattering of JavaScript, you can turn an elephant into a mouse, and make it dance on a parallax-scrolling ball. It’s time to reconsider whether you should, though.
There’s a point on the trade-off curve where rearranging everything, hiding half the page, and then presenting it as “the same template, just styled differently” is simply not meaningful. Nor is it simple. Nor is it efficient. A one-size-fits-all HTML base document is not a trophy-worthy accomplishment in itself, lest we forget.
The way we think about this at Basecamp is as a nip’n’tuck. If you’re just stretching or shrinking things a bit, then responsive can definitely be easier (we do that on this blog, for example). But the further you move towards a full make-over, the less it makes sense.
This is particularly true if your framework of choice doesn’t make it needlessly complicated to use separate templates for separate purposes. Rails 4.1 has a feature called variants that makes it trivial to share the controller and model logic of your application, but return different HTML templates when the devices call for it. It’s this feature we’re using for the Basecamp mobile views (which in turn are embedded in our mobile apps) instead of the prevailing responsive paradigm.
By going with dedicated templates, we don’t have to include needless data or navigation that’s going to be hidden by the responsive rules. We have less variables to think about on the individual page. It’s just a simpler workflow where it’s easier to make changes without considering a smather of side effects.
So the next time you’re marveling at a responsive design that’s able to make the best use of a 27” iMac at full screen and a fit neatly on a 3.5” iPhone as well, you might want to ask yourself why you’re trying to make one performer do so many tricks.
Michael Hoffman
on 12 May 14The point that it’s not intrinsically valuable to serve one document for all screen widths is well taken. However, I do think there is a kind of simplicity that follows from this approach. Managing one template is, ceteris paribus, simpler than managing two (or more); large-scale refactoring of the view(s) will be more complex with variants. The fact that the variants share a controller action (and helpers) mitigates this issue—and, of course, all else is never, ever equal. All of which is to say: both paradigms have their uses and it’s silly to be dogmatic about either in the abstract. I take it you agree.
Ethan Marcotte
on 12 May 14Great to hear about your experiences, David—thanks for sharing them.
However, I’ve found the “hiding” you’ve described is a result can be mitigated with some careful planning at the outset of a project. As I described in my book, some “mobile first” thinking can help focus your content/interface on what really matters, improving the experience for all users.
Of course, if you’re hiding a significant amount of content on different device classes, then yes: I’d agree that some UA-driven negotiation is probably valuable for that project. But in my mind, a well-planned responsive design aims for broad content+functional parity from the outset, and proceeds from there.
Kenny Smith
on 12 May 14“Mobile first” is the key to responsive design. This leads to deep thinking about what’s critical in the interface and how to present it. Going the other way typically leads to chopping things out, leaving the user with less functionality. I personally find this very frustrating. Not to say that differing screens should never have their own templates but a mobile first strategy can go a long way to a better interface all around.
Tom Aarts
on 12 May 14Any chance you can share the (simplified) logic you’re using in the conditional when using variants for rendering mobile views?
Tim Wright
on 12 May 14To echo and add to Ethan’s comments. A lot of the problems I’ve seen in the struggles of implementing and managing a responsive design circle around content strategy and communicating across teams as to what exactly is considered, “valuable,” to the user. It can be an elegant solution, but can also get hairy very quickly when RESS (and other types of detection) gets folded into the process.
Responsive Design is certainly not always the answer, if your site or application genuinely has a different usage in a mobile context, that’s when we start seeing a lot of hiding and showing of content and yes, a UA solution is probably best.
Thanks for sharing, it’s good to hear about others’ experiences!
AJ Kandy
on 12 May 14The other factors in considering mobile-first responsive is speed, and consideration of the limitations of a mobile device. Does a RESS approach add time to the already considerable mobile latency? Are there scripts pinging the backend every so often, without the user’s input (firing up the device radios, shortening battery time)? Every bit of research I’ve seen shows that mobile users don’t want a cut-down or read-only version of the site or app they’re using; they want full functionality for mobile productivity. How we as designers get it to them is the real challenge. RESS might be one solution, but as others noted, maintenance and refactoring can be challenging (esp for smaller teams); RWD and mobile-first design might have some initial complexity, but, at least to me, feels closer to an optimal solution.
Luis Aguilar
on 12 May 14In my case, the hard part of using something like variants would be selling to the development team that it is more convenient to use several templates per target device than having one template and use multiple CSS style sheets to transform the UI depending on the screen size, as this could increase overhead due to maintenance of these extra templates.
I’ve been using responsive design for some time already, I think is important to have a good planning of the UI (content, structure, etc.) before building it so it is flexible enough to adapt to screen size using only styles. In my opinion, modifying styles is less obtrusive than modifying a template.
twiz
on 12 May 14I’m excited about the implications variants have for A/B split testing.
Eric Anderson
on 12 May 14To me both approaches have merit. Using both strategies depending on what makes the most sense seems a reasonable method. The important thing missed on many “responsive” designs are:
Focus on speed of loading – Many sites look good at a variety of widths. But it takes forever to load on a low bandwidth, high latency device. To me all the work of making it “responsive” are secondary to making it fast.
Focus on simplicity – Phones and tablets are MUCH more fragmented than the desktop market. There is also a bigger lag on updating. With a desktop browser I can simply download and install the latest. With a phone I may need to buy a new phone to get the latest. This fragmentation and slow adoption rate of new tech means it’s easier for things to break. Keeping things simple reduces the breakage. Loading your page with lots of fancy tricks may cause it to work great on the iPhone but make your site totally fail on another phone. To me if there is a way to do with without excessive JS I opt for that approach. Also progressive enhancements and graceful degradation is crucial. I can tell you how many times I have used a “mobile friendly” site that I sure looked and worked great on the developers phone but the fails to even work in the most basic way on my phone.
Provide an opt-out – Provide a way to view the normal desktop site on your mobile device. Often features are trimmed on the mobile device due to screen size. Giving me a way to see the desktop version gives me access to those features. I may have to do a bit of zooming around to use those features. But sometimes a clunky interaction is better than a complete loss of function. Also once I am done accessing the desktop feature not present on the mobile version provide me a way to get back to the mobile version.
Look at the in between sizes – Many developer obviously target certain resolutions. But the sizes between those targeted size may look awful because they toggled between the target resolutions. At least take a look at the pages as you move from one to another size. Focusing on the in between sizes means your site doesn’t look awful on devices that don’t have exact resolution of the iPhone or latest Android device.
Bryan
on 12 May 14@Ethan Marcotte Your “A Book Apart” book on Responsive Web Design is excellent and from my experience (since delving heavily into responsive web design work) your comments on this matter are spot on.
Mark
on 12 May 14To counter Ethan’s point: In complex organizations with small in-house teams (with big workloads and WAY too many Executive chefs in the kitchen), careful planning is unfortunately not always possible. In these less than ideal situations I can see David’s take on this as being really useful. A mobile template system can offer a way to buffer the user from the crud that invariably finds its way onto sites of this nature and provide them with the best possible experience.
Michel
on 12 May 14We’ve extensively used prepend_view_path with great success for accomplishing the same thing without littering our view folders with variants. Did you try going that way? If so, what made you opt for variants instead?
Juan
on 13 May 14A good mobile interface usually will require a dedicated design approach to really work, not just to quickly shrink a large interface. For general purpose websites the damage is small, but for an app with more interaction, the user experience might be quite damaged by this approach.
Justin Avery
on 13 May 14First off David thanks for sharing your approach to Basecamp, as a product I know and love to use across multiple devices it’s great to know how you are solving problems.
Where you’ve finished with…
— —... we should rather be aiming for is an interface that allows us to accomplish out goals on a small viewport that extends to make the best use of a large screen to accomplish those same key tasks in a continuous improvement manner.
We should be looking to add value based on a range of different factors including the viewport size, pixel density, network speed, device features rather than focussing on mobile/tablets/desktops.
The approach the BBC have taken in serving core content from a mobile first approach and loading in supporting content under certain criteria is a a great example of this.
— As a complete off topic side note, the comment preview for blockquote doesn’t show any styling difference in the comment. Would be great to add that.
Thomas Edwards
on 13 May 14A supermarket I visit does this “different views” thing, but at Christmas and Easter, only the desktop site got the seasonal opening hours as nobody bothered to update both templates. It’s fine if you’re building a product you carefully curate, but useless when a client gets involved or there’s a budget for everything.
This discussion is closed.