This is the second in a series of four posts on different approaches to mobile web development. For an overview of what it means to be mobile friendly, check out the previous post.
The first option I’ll discuss is the one that is the most popular by far: use user-agent detection to route users on phones to a separate mobile site, typically at m.example.com. In a nutshell, this technique uses server-side logic to solve all three goals of mobile web development at once – if the user’s browser looks like it’s on a phone, you serve them mobile content, formatted for their phone and optimized for speed.
Conceptually simple, this is the easiest option to add to an existing site, especially if you are using a CMS or Web application that supports templates. Since only the mobile-specific content, styles, and scripts will be sent to mobile users, this method also provides for the best performance out of any of the other options presented here. Finally, it also allows for completely different user experiences on desktop and mobile – they’re two different sites, after all!
Unfortunately, this approach is not without its drawbacks. For starters, you are now maintaining two different pages for every page on your site that you would like to expose to mobile users. If you are using a CMS, is possible to arrange your site templates in a way that minimizes this duplication, but any time that there is a difference between the mobile and desktop templates is a potential source of complication in your code. Similarly, this increases the implementation time of any new site features, since you must now code two sets of front-end logic.
Even more important than that, though, is the fact that user-agent detection is inherently flawed, and anything but future-proof. Every time a new browser comes out you must adjust your algorithm to accommodate it. And false positives are particularly scary – it could be embarrassing to serve desktop users your mobile site accidentally.
When it is Right to Choose This Option
Firstly, if your target audience includes users on older or low-end feature phones it is worth noting that you may need to employ this strategy to some degree no matter what. This is because the default browsers on some feature-phones do not support consumption of the same markup you would code a website targeted at desktop with, but instead understand formats like XHTML-MP or the older WML.
Another case where you may be forced to use this approach is if you cannot, for whatever reason, modify your existing desktop site, and need to have a 100% separate mobile site. Though it’s not ideal, at least you have this option.
Most of the major web apps you see in the wild have chosen this path, including Facebook, YouTube, Digg, and Flickr. In fact, we picked this strategy for the mobile versions of addons.mozilla.org (AMO) and support.mozilla.org (SUMO). If you’d like to see the source code behind an example of this approach in action, feel free to check out the github repository for AMO or SUMO.
If you’re unhappy with the drawbacks of the Separate Sites technique, stay tuned for next week, and we’ll take a look at one alternative – Responsive Design.
Steve Fink wrote on :
groovecoder wrote on :
Samat wrote on :
Jason Grlicky wrote on :