A Very Modern Mobile Switching Algorithm – Part I

An important question that most web developers ask when developing their first mobile web site is “how do I distinguish between mobile users and desktop users?”. Although this seems like a simple enough question at first, of course there’s more to it than meets the eye. In fact, what do we even mean by ‘distinguish’? How we distinguish their requirements? Their desires? The services they expect? The browsers they happen to be using?

Let’s take a look at some of the questions that surround mobile and desktop site deployment, and how we can deal elegantly with these concerns. In this two-part article we’ll discuss some approaches, and then we’ll introduce a switcher algorithm that we have developed for mobiForge.

Mobile is an adjective, not a noun

The first question to consider is this: to what degree do mobile users even expect or deserve to receive different content to their desktop peers? Of course we live in a world of ever-faster mobile networks, ever-richer browsers, and ever-flatter data tariffs – so there is an argument that says there’s no technical need for different mobile content at all. If your user has a modern smart phone (which can competently render most contemporary desktop web sites), can’t they just use the same site as everyone else?

As a developer, doing nothing certainly seems like a very attractive option – and of course a very easy one. But is it fair on your users? Yes, they have a capable browser that can handle your page markup – but does that actually mean that they want to see the same content and use the same services as your sedentary desktop users? Modern thinking suggests not – as witnessed by an explosion in made-for-mobile (and, pertinently, even made-for-iPhone) web sites. It’s not so much about the capabilities of the lump of electronics in their hand as it is about the needs of the human on the other side of its screen: a user who is mobile, not just a user who is holding one.

A different user, a different context, different needs – and yes, a different browser. These all seem like important design influences that you should be taking account of. Frankly, if a single web site thrills both desktop users and mobile users equally, it is probably only by chance.

The convenience of convention

So the next matter is how distinct desktop and mobile sites are identified. It certainly seems sensible to use the URL or address of the site as a way of differentiating one from the other – this is the philosophy behind the use of the .mobi domain name of course – but is also witnessed on those sites that use patterns like http://example.com/mobile, http://m.example.com, and so on, to indicate a different mobile version or section within an existing site.

A distinct URL address also has the nice benefit that you can use it elsewhere (say, in printed literature) to show people that your mobile site is up and ready for business.

Of course, we think that the .mobi choice is a good one, and we’ll be using it in the examples below. It’s valuable as a reliable convention – one that quickly helps your users to guess, find, and understand your mobile web presence.

But the principles we’re covering in the rest of this article apply however you choose to set up your two sites and their URLs.

Elementary, my dear Watson

So what, you might be asking, about a little detective work when the user visits your site? Can’t I tell what sort of browser they have? And then send them to one site or the other accordingly? Of course – and this is a technique that has been used in mobile for many years. If you have a desktop web site and still run an old-fashioned mobile WAP site, for example, never the twain will meet. Desktop browsers have to go to the HTML web content, and legacy WAP mobile browser have to go to the WML content: they are simply not capable of rendering each other’s markup.

In addition, the technology for doing such device detection is also far from difficult. There are simple algorithms for almost any server-side environment, and of course most rich device database such as DeviceAtlas or WURFL will contain some sort of a flag to help detect the browser one way or the other. (In DeviceAtlas, there’s a boolean property ‘mobileDevice’, to do just this).

But, ironically, the convergence of web and WAP standards (XHTML markup is designed to be used by both), and the rise in the capabilities of handsets, has made this tactic a little troublesome.

There may well be times when a mobile user wants to access a desktop site, such as for information that is exclusively there, or because they are in the “bored” rather than “urgent” state-of-mind, for example. And there may even be times when a desktop user wants to see the mobile site. Indeed some sites are even rumoured to enjoy more desktop traffic than mobile: perhaps due to the slick, focussed, efficiency of many mobile services compared to their bloated, ad-heavy desktop equivalents.

Regardless of the reasons, it does seem presumptuous to force a user to visit one site rather than the other. After all, if you’ve chosen two site addresses in the first place, surely you are also expecting them to be able to choose which they want in their browser’s address bar – not to be shepherded blindly one way or the other. Ultimately they should be given the chance to choose – and then to change their minds at a later stage if they want.

Putting it all together

No doubt you’ve noticed that we recently relaunched dev.mobi as mobiForge. We wanted to make it available to all types of user, whether mobile or not, and to do so, needed to develop a switching mechanism that encapsulated all of the ideas and approaches above.

Very early on we decided we wanted to use two domains. dev.mobi (which we used previously) did detect the browser type to provide a suitable skin to the content, but we were worried that the .mobi in the URL implied that the site had been primarily designed for mobile users. It had not, and in fact over two-thirds of the site’s users were non-mobile. (It’s about mobile, of course, but that doesn’t alone justify the sole .mobi moniker).

So we launched mobiForge.com and mobiForge.mobi as two sister sites. Obviously the former is designed for desktop users and the latter for mobile users. You can, as a user, use your address bar alone to indicate which user experience you want to receive. But there’s far more to it than that.

Hopefully you have visited both sites already. If so, you will have noticed that they each contain a button that switches you back to the other. If you find yourself on the mobile site, for example, the “Switch to our desktop site” button at the bottom will whisk you back to the richer corresponding page on the desktop site.

The converse is also true of course, for mobile users on the desktop site. But that’s perhaps a more worrying situation: a mobile user who has inadvertently started to download the desktop site could be in for all sorts of surprises. The slower speed of download, the inability to easily read the content, the larger size, and the possibly unpleasant cost, of the page: all of these might easily cause huge disappointment to the user.

So the “Switch to our mobile site” button is place right at the top, providing those users with a great escape route as early as possible in the page’s download sequence.

A little friendly advice

But to try and make this scenario as rare as possible, we realised we could also rely on the browser detection technique. Specifically, if we think that a user has inadvertently chosen the ‘wrong’ site for their browser, we can warn them and get them to confirm their choice, or accept our recommendation. If a user visits mobiForge.com with a mobile browser for example, we provide them with a simple interstitial page that lets them proceed (bravely!) to the .com or to revert to the .mobi.

And again, vice-versa. Desktop users are steered away from the mobile user experience by default.

There’s another nice trick to this too. Because we’re using a nice and powerful content management system, Drupal, we have been able to mirror the URL structures of the two sites. So during the interstitial prompting, we also take care to preserve the URL after the domain. This means that if the user was following a .com site link out of an email they received on their mobile, they’ll still get to reach the content intended – just on the .mobi site instead. (And yet again, vice-versa.)

Finally, we know how annoying it can be to be prompted incessantly when you’re trying to get things done. We quickly realised that the interstitial page would get very frustrating very quickly if you were constantly prompted. So, using a cookie, we remember which choice you made on the previous occasion and forward you directly to the appropriate site. We allow you to go back and forward at will between the sites anyway if you’ve changed your mind in the meantime!

And in Part II…

Please take a few moments to see how the approach we’ve chosen works. Press the buttons at the top and bottom of the two sites and toggle at will. (If you’ve got a mobile device to hand or can easily switch your browser user-agent, you can try to provoke the interstitial behaviour too). Remember that your choice of preferred site is stored as a cookie, so you might need to clear cookies for your site to see all the scenarios I’ve described above.

In Part II, I’ll explain a few of the details of the switcher software itself (and in particular a little trick that’s required to stop the possibility of infinite redirects, which some of you might have spotted!).

Next time we’ll also publish a collection of different types of ‘switcher’ graphics you can use. In the meantime, help yourself to the buttons off our site if you want to start setting up something like this yourself.