Approaches to Mobile Web Development Part 2 – Separate Sites

mozilla

4 responses

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 Good

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!

The Bad

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 Mobile SUMO Screenshot

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.

This aside, in my mind there is one case where this strategy really shines over other methods. If the functionality you would like to provide to your users on mobile devices is extremely different from that on a desktop, then using Separate Sites is simply likely to be the most practical choice. This is because you have the option of sending completely separate HTML, JavaScript, and CSS to phones and PCs.

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.

Examples

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.

Next Week

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.

4 responses

  1. Steve Fink wrote on :

    It seems worth mentioning that another drawback of this approach is that a web site’s idea of what works on a mobile device is often very different from the actual users’, to the point that many mobile users prefer to use the desktop version. It’s a big hammer, and it’s very easy to get lazy and smash some fingers with it.

    Sometimes it’s a matter of the site author guessing wrong (or not tailoring properly to what makes mobile different); sometimes it’s different motivations (eg it may be easier to get to the content and avoid ads on the desktop version.)

  2. groovecoder wrote on :

    love these posts. inspiring for what we’ll do with developer.mozilla.org

  3. Samat wrote on :

    Could someone list where in the AMO and SUMO codebases user agent detection is performed?

  4. Jason Grlicky wrote on :

    Samat: If I’m not mistaken, I think both AMO and SUMO are using the django-mobility library to house their shared detection logic:

    https://github.com/jbalogh/django-mobility

    Hope that helps!