This version of the site is now archived. See the next iteration at v4.chriskrycho.com.

Responsive Design, Server-Side Feature Detection, and a Big Mess

A couple days ago, Jason Gigsby (@grigs) highlighted this post by Dave Olsen on responsive design from the server-side. The biggest thing that caught my attention was his focus on user-agent detection for altering the delivery of content.

There is some sensible stuff in there; it’s worth your time. In particular, I can see the value in delivering different kinds of resources to different targets, especially in the case of video or images, where resolution and bandwidth may be constrained. That’s a big part of what is driving the responsive <picture> discussion, in fact. But a heavy emphasis or long-term reliance on user-agent detection rubs me the wrong way.

Front end designers and developers have in the last few years finally stopped relying on user-agent detection to make their sites behave in particular ways. That’s a good thing; user-agent detection is often unreliable and finicky; it’s certainly in a constant state of flux. That’s only going to be more true as more mobile browsers allow users to set their user agent, and as browsers for mobile and desktops converge, a la Chrome for Android.

There may be times when user-agent detection is an appropriate strategy on the back end – I’m not sure what they might be, but I’m willing to allow that there are situations in which it may make sense. However, Olsen was explicitly talking about front-end design, albeit from the perspective of back-end development. When someone starts talking about serving different content based on user-agent, I can’t see that working out well for users in the long run. Olsen himself may be a good enough developer to avoid doing stupid things with user-agent detection, but are all other back end devs equally disciplined? In other words, it may be just fine for him, but evangelizing for the practice may land us all in a world of trouble down the line. After all, it’s happened before.

Then I read through the discussion, and this line in Ronan Cremin’s comment stuck out:

A great mobile experience needs to be designed for mobile from the outset, not a rejiggered version of an existing site. Any mobilization solution that utilizes the same basic chunk of HTML delivered to desktop and mobile is missing an opportunity.

The first half of that is quite right, of course; a great mobile experience does need to be designed for mobile from the outset, and rejiggering an existing site will never be optimal. (It is, I should note, still a good step in the right direction for websites whose proprietors can’t afford an immediate full redesign.) I’m increasingly a proponent of the “mobile first” paradigm of design: I consider mobile from the very beginning of my design flow, and it’s actually the first CSS layout I build. Media queries progressively enhance the functionality of larger screens just as other CSS properties progressively enhance the functionality of more capable browsers.

The second half of this quote runs right up against the same thing that was making me uncomfortable in Olsen’s article, though. I never want to prevent a user from getting access to certain content simply because they’re on a smaller screen (or an alternate format like a screenreader; it’s too easy to overlook the accessibility concerns inherent in discussions like this). I always want to deliver the same content, however vast the differences in presentation.

There is no question that data can and often should be displayed differently to a user based on the size of their screen, their bandwidth, etc., especially in the case of web applications as opposed to ordinary websites. Reflowing the content, applying alternate styles more friendly to touch, finding ways to deal with perceived relative importance as proportions change – these are all good and even necessary ways of responding to the vast differences between a smartphone, a 15″ notebook and a 27″ 1080p monitor. Different contexts may demand different presentation – but we should always let the user get the same data.

Returning for a moment to the ongoing discussion of a proposed <picture> element, one of the concerns I raised in a comment that has since been raised by one of the leaders of the project is guaranteeing that the user can get to the highest resolution of the image, even if it’s not the image originally loaded by the page. If I’m on my phone, I may want a site to save me bandwidth and time by loading a lower-resolution image that is appropriate to my screen. But I don’t want this to prevent me from getting to that high-resolution image if I decide it would make a great wallpaper.

Schemes that rely on user-agent detection, instead of fixed standards, seem to run a much greater risk of preventing agnostic access to all the data on the site. For the record, I think that’s a bad thing. Again, there may be ways and places in which user-agent detection is helpful. Some of the stopgap solutions people are putting in place while browsers catch up to the needs of responsive design are great examples. But these should not be understood to be long-term patterns or solutions.

Rather, we should be pushing for better browser capabilities and web standards to support responsive design. If we need bandwidth data, we should ask the browsers to provide it. If we need support for a responsive image element, we should ask the browsers to provide it. The beauty of web standards is that if you think of something beneficial and lay out it carefully, you can submit it and see it get traction. Driving the web towards standards-based approaches works in everyone’s favor.

All that said, I’m still a newbie in a lot of ways, so hit me with your best arguments why I’m wrong. We’ll all come out smarter, perhaps me most of all.

Edit: I just finished reading an article Olsen linked, RESS: Responsive Design + Server Side Components, by Luke Wroblewski. The original emphasis was much more on web applications and vastly customized templates for design. This article, with its narrower focus, I like a bit better, but I still have some significant concerns with some of the ideas he tosses out (like custom url structures). I can potentially see value in user-agent detection for templating, but ultimately I still think it’s a stopgap measure.

In any case, the design community should invest significantly more time in thinking about how to handle responsive templating, which is what Luke W’s article is really driving at.

Discussion

  • Chris-

    First off, thanks much for continuing the discussion. Second, I think my original post must not have been clear enough. The whole point of server-side feature-detection is to offer a way forward for the responsive templating concept that you seem to think might have value. Is there some user-agent detection stuff in there? Yes. Is user-agent detection meant to be the be-all-and-end-all for making decisions regarding how features are templated? No. Is user-agent detection meant to provide completely different layouts/templates to various classes of devices? Again, no. When I say “An Evolution of Responsive Web Design” I really mean that. What I talked about is to make responsive layouts smarter as opposed to throwing those layouts away. If you haven’t, please poke through the demo, tutorial, and template code.

    In my scheme user-agent detection, in the traditional sense, is, again, only meant to be one of the data points that helps server-side responsive templating work. Unfortunately, in the demo I created it looks like it’s some huge part but it really can be a minor section and, frankly, possibly left out altogether. Server-side feature-detection is about just that, accessing browser features but on the server. A user-agent string is used as a key and can store a vast trove of browser data via Modernizr. Why punt that kind of decision making onto the browser (and JavaScript) to provide polyfill logic for including bits of content and, most importantly, media if you don’t have to? If you find value in front-end devs moving towards feature-detection I’m surprised you’d take a dim view of server-side devs moving in a similar direction even if I might suggest that their is still some amount of value to the data found in a user-agent string.

    As you note, at some point tools need to be built to overcome the gaps we have between what we need to support and what those end-points (e.g. browsers) actually support. The downside of standards is that it takes a long-time for them to catch up with what’s actually happening on the ground. I’m simply offering a way forward on the back-end for more complicated systems that might want to use RESS and to do it in a smarter way than just user-agent detection until the standards catch-up. I definitely *wasn’t* suggesting front-end devs pick up user-agent detection or drop what they’re doing. I’m not sure one blog post, meant to pull together a number of a different threads and showing a working example, qualifies as evangelizing a long-term solution. ;)

    Offer a rejoinder↓
    • Thanks for the thoughtful reply. As I read LukeW’s article and saw what you were responding to and adding to, I realized more the direction you were headed, and I also recognized that I spazzed a little about UA-detection, which is just such bad mojo on the front-end side that I’ve developed a bit of a Pavlovian reaction, I think. And the comment I quoted actually set me off way more than your article did; I probably should have been a bit clearer in my own article on that point.

      I agree with you that doing server-side detection can have some significant benefits, and between your and Luke’s examples, I can see the specific places where I might consider doing it myself. My hesitation was in light of the ways I’ve seen quite a few people doing one of two horrible things:

      (1) Using user-agent detection to deliver completely different content to mobile than to desktop, which drives me nuts as a user, not just as a designer. As I noted in the article, that drives me crazy, and it’s not ideology in this case – it’s the fact that when I pull out my phone, I want to be able to see your whole site.

      (2) Only delivering well-designed content to specific types of browsers. I don’t know if you caught any of the hubbub about -webkit and vendor prefixing in general over the last week or two, but people have been doing some headdesk-inducing things in terms of optimizing sites for particular vendors, including (at times) relying on UA-detection.

      But you weren’t arguing for (1) and I don’t know if you’d even heard about (2). Serves me right for bringing a bad set of assumptions to the table. Thanks for the gracious response. I look forward to seeing some of the ways we can do templating work responsively, I’m going to look into Modernizr, and I’m going to be thinking about ways that a browser could supply meaningful data to the server about itself without necessarily having to reply on the user agent string (which, as LukeW noted in the article you linked originally, is a bit risky).

      I think optimally I’d really like for a browser to tell the server a few non-trivial pieces of data when it sends its initial request – things like average bandwidth over the last [x] time, screen info (resolution and DPI at a minimum), touch or cursor oriented, etc. I have no idea how feasible those things are, but it would be fantastic if the server could know those instead of having to trust that the user agent string will allow it to infer that data accurately.

      Offer a rejoinder↓
      • To point #1… *winces* I’ve done it. I think that’s part of the push from my end to find a better way forward. It is wrong to wholly rely on the UA. As for point #2… well aware of it but luckily that’s not my realm on many projects.

        There’s a good thread on the WHATWG listserv about the “non-trivial pieces of data” idea. Like some of the commenters my question would be “Where do we draw the line?” and “Are these features that we build *into* a browser really going to be useful once that browser is actually published?” Meaning, have we moved on from needing that as a technique by the time they’re really available.

        Offer a rejoinder↓
        • I think your comment on (1) summarizes and highlights the challenge here. We do need a better way forward, and particularly when we’re delivering application (or application-like) functionality, the temptation is there and strong to deliver totally different content. I’m just persuaded – both by the ideological arguments put forward by guys like Ethan Marcotte, and by my own personal interactions with sites – that it’s not the best way forward. Unfortunately, we haven’t yet nailed down a single “best way forward” yet; I think responsive flow with media queries is part of it, and I think the kinds of things you’re pushing for with responsive templating are actually a really neat future part of it. (It’s sometimes easy to forget that “responsive” as a general part of design is only a little over a year old. It’s come a long ways in that time, but it’s still in its infancy or at most toddlerhood, even when compared to the rest of the web.)

          Thanks for the link; I’ll read through that. I think the question you’re raising (and they apparently are) is a good one. There are a few that I don’t see going away – bandwidth in particular, but perhaps all of the ones I noted – but I can also see how easily that sort of thing could get carried away. The last thing we want to do is burden the browsers with implementing things no one will actually use. Use cases like the one you laid out, or the first couple proposed approaches for <picture>, convince me that some of these can and should have a life of their own in the browser. The trick is figuring out which ones.

          Thanks again for provoking a good discussion and helping me suss out these thoughts a bit more carefully. :)

          Offer a rejoinder↓

Pipe up!

Anonymity is most unhelpful. Please identify yourself!

You may use GitHub-flavored Markdown and/or these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>