Detection

One of the recurring themes at the Mobilism conference earlier this year—and more recently at the Breaking Development conference—was the subject of server-side user-agent detection. I posed the question in absurdum on the Mobilism browser panel:

A useful tool for developers or spawn of Satan: which is it?

It’s a contentious issue, as Alex’s strident defence illustrates. Personally, I’ve never been a fan but that’s mostly because of the long history of really, really bad UA-detection in the past. When I discussed this issue with Lyza we came to a détente, agreeing that there is nothing inherently wrong with server-side UA-detection: it’s what you do with it that counts.

In their presentation at Breaking Development Bryan and Stephanie outlined the kind of detection that they have used. Crucially, it assumes a very basic small-screen default—rather than assuming a desktop browser—and later double-checks the profile on the client-side using feature detection.

Luke recently outlined another kind of cautious device detection that he’s calling RESS: Responsive Design + Server Side Components, sending subtly-different DOMs to different classes of device. He also recently wrote about why Bagcheck has a separate mobile site and it strikes me that RESS could alleviate the concerns he mentioned regarding responsive design for Bagcheck.

I think that RESS could be a very useful technique as long as it assumes a safe default: a small-screen, low-bandwidth default. That way, any UA detection would be done against a fairly limited set of user agents: desktop browsers and maybe tablets. To me, that seems far more reasonable than trying to pattern-match against the sprawling jungle of mobile devices in the wild …not to mention the swampy morass of licensing issues with Device Atlas (and now WURFL too).

As ever, smart defaults are really important. Just as truly responsible responsive web design goes hand-in-hand with a mobile/content first approach, I think that any server-side detection should do the same. It completely inverts the problem space. Instead of thinking “How can I stop this nice-to-have content/functionality being sent to mobile devices?” you can assume a mobile device by default and then your question becomes “How can I make sure that this nice-to-have content/functionality is only sent to desktop devices?” (the answer probably involves some kind of conditional loading with JavaScript).

A thornier problem with server-side UA-sniffing is that, regardless of whether you’re testing against a list of mobile devices or you’re testing against a list of desktop devices, you’re still committing yourself to an arms race. You are now obligated to keep your list of browsers up to date.

Still, the rate of desktop browser releases is a lot slower than the rate of mobile browser releases. So if a new desktop browser is released and it ends up being served a mobile-optimised DOM, I think that’s better than inadvertently serving a desktop-optimised DOM to a whole bunch of mobile devices.

That’s just my opinion of course. As ever, the standard disclaimer applies.