…But it doesn’t end there.
On MobiForge a few weeks ago, Ronan Cremin pointed out that most top sites use some form of server-side detection to send different HTML to different devices. In a follow-up article, he takes Google as a specific example to show just how widely its content varies between an iPhone, a BlackBerry Curve, and a Nokia 6300.
I’m not arguing against server-side detection, and sending different content to different devices. I think it’s an essential part of an adaptation strategy. But I just want to quickly point out a few reasons why it’s not enough in order to cover the whole spectrum of browsers. Here are a few things that you won’t know when a browser makes its first request to your web server:
- The height and width of the viewport being used. (Including the device’s portrait/landscape orientation.) If you detect a mobile device, you will be able to look up the device’s “standard” dimensions in a device database, but the user’s actual viewport may be different. If you place a web app on your iPhone’s home screen, and run it without browser chrome, it will send the same user-agent string as when it is running in a browser with chrome (thus reducing the available height). The user may be viewing your site in a browser panel embedded in a separate app, which may present a different viewport. As Stephanie Rieger explained in “Viewports all the way down…“, anyone can create embed a web view of arbitrary size in a home-made ebook.
- The zoom level. Lyza Gardner wrote about how zoom levels and different text sizes can mess up pixel-based responsive layouts. A user-agent string contains no information about whether a user has changed the default font size in their browser. It does happen, and probably more often than you think.
Basically, just because the user-agent string says “iPhone” doesn’t automatically mean you’re dealing with 320 x 480. Server-side detection alone will not give you the full picture, and only doing adaptation client-side robs you of the opportunity to perform really useful server-side optimizations. The best approach is a blend of the two, as Luke Wroblewski describes in “RESS: Responsive Design + Server Side Components“.
RESS is MORE.