background image

A Very Modern Mobile Switching Algorithm - Part I

Section Feature Image
Posted by James Pearce - 03 Oct 2008
Twitter share icon Facebook share icon Google Plus share icon

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.

It's the user, stupid

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,, 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 on an iPhoneSo 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 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., yesterdayVery early on we decided we wanted to use two domains. (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 and 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

The interstitial pageBut 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 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.

Posted by James Pearce - 03 Oct 2008

James Pearce's picture

James Pearce was previously CTO at dotMobi and co-author of Wiley's "Mobile Internet for Dummies". He has the mobile web in his veins, having worked previously at Argogroup, AnywhereYouGo, and as founder of old-skool mobile blog, WAPtastic. James has declared every year since 1997 to be "the Year of the Mobile Web" - and is finally right. Right now, he's travelling the world and living the mobile dream.

Posted by cranstone 5 years ago


So far the Mobile user has to contend with the following:



If you stop and think about it for a moment this is ridiculous. There is simply no need to segment the web further than it is right now (TBL is definitely against it). The alternative solution to this problem is simply to "extend" the current HTTP protocol and make it smarter. It was designed to support this.

The user/customer should never have to think about where he/she is going. 99.9% of them will type in http: - simply because this is an already learned behavior. After that the browser and the web server should handle the rest.

The "industry" problem has not changed. It's simple to state: "what are the current device and terminal capabilities", and yet hard to solve.

I would argue that the more complete solution is one that allows the web server/developer to know more context than is currently offered by the browser. This means more than just viewable area or screen resolution.

Pressing switches and buttons to ask the customer to change his/her "user-agent" is way too techie. People (other than techies) have no idea what a user agent is. And in most cases they are inaccurate.

The more complete solution is to remove the complexity from the user entirely and simply have the web server recognize the devices context in real time. A method to do this was invented 30 years ago. Simply extend the current protocol. Section 12.1 points to the fact that it can be done.


Peter J. Cranstone
CEO 5o9 Inc

Peter J. Cranstone
CEO 5o9 Inc

Posted by James Pearce 5 years ago

Peter, I think we agree entirely.

Of course it is possible to deduce what broad genre of use experience the user probably wants to have, with user-agent detection, and then to deliver what you think is the most suitable 'tuning' of that experience based on further knowledge about that browser. This can be done either using data from the device or by querying central repositories of device data.

(Which of the two works best is another discussion!)

I certainly don't advocate that users should change user-agents. (I mention it in the article only as something that curious developers might want to do to see how our algorithm works).

What we're doing here is nothing more magical or controversial than many transatlantic e-commerce sites that use your IP address to alert you to the fact that you might have meant when you mistakenly typed .com and vice-versa (but which can be overriden as a memorised user choice).

I don't recall anyone complaining that "broke the web"!

In other words, it's a well-established tradition to use a site's top level domain to indicate the preferred (geographical or linguistic) context of the user. We're merely saying that "mobility" is another dimension of context: worthy enough of its own site in most cases.

But a philosopher's stone in mobile is the assumption that technologies and protocols can reliably second guess what humans want to do. Success is about serving the warm, unpredictable creature on the other side of the screen.

What we're trying to do here is reconcile their desires with what technology might otherwise mandate. We're not arrogant enough to force one experience on to someone if they'd rather tolerate another - for whatever reason.

Which technology knows that I am, as a human, in a relaxed, patient, time-rich state of mind? Sometimes I am prepared to tolerate a regular desktop site within my usual mobile context (for the sake of a richer experience or a deeper level of content) - but only the neurons in my brain know when that is.

(Presumably the same, non-existent technology that knows I'm in a hurry when using my PC and magically skips all the bloated styling and popup ads that are distracting me from getting to the semantic matter at hand!)

A colleague of mine likes to say: "It's just a small matter of software". But then there are also human beings.

Posted by yeswap 5 years ago


Thank you for writing this very important post. The approach of guiding users toward the appropriate site (non-mobile or mobile) based on detected browser capabilities combined with giving the user the ability to override redirection and choose the site variant they prefer is something I've been preaching and practicing for years.

The interstitial dialog is a nice extension of this concept which I hope to apply to and soon.

Dennis Bournique

My blog - It's all about the mobile web.,

Posted by James Pearce 5 years ago

Thanks Dennis.

I'll hurry up and post the algorithm so you can steal it! :-)

Posted by arnthorsnaer 5 years ago

We took a similar approach to our own site which has a mobile and a desktop version. Good to see that this approach makes sense to others as well.

Posted by robman 5 years ago

Hi James,

here's a post I recently created that outlines a powerful approach that we've been refining for 2 years now.

We call it "Not-Device" Detection.


Posted by James Pearce 5 years ago

Rob, that's pretty interesting - thanks for the link. What I like is the fact that you're (perhaps unwittingly) pre-empting a future where the web is mobile by default and desktops become a dying niche :-)

What I think you're missing though is the mechanism by which users can override the detection choice.

Yes, the site owner should have ultimate dominion over the user's experience.

But, on the other hand, if I, as a user *know* there are two available experiences (which are both handled by my capable device), I should be allowed to choose which is for me. Especially if the two sites differ by more than jiggled markup: there may be some service on one that is simply not available through the other.

Occassionally I *do* want to go to instead of Thanks for the IP-based suggestion, guys, but do let me toggle to the other if I want.

(This analogy is a well-solved problem, and where I drew original inspiration from)

Posted by robman 5 years ago


"unwittingly"...very witty 8)

And I'm fairly comfortable that I'm not missing the point about "user choice". In fact I go to some effort to point out what an important design pattern that is.

We always recommend that the user has an option to navigate to the PC version of the site. They may just choose to do that. Or they may be a bot and simply follow that link.

For example, our site for IAG includes a link with a query string that let's you override the auto-detection.

So I think we're definitely on the same page...just perhaps top and tail...if not approaching it from different sides 8)


Posted by jlbruno 5 years ago

"I certainly don't advocate that users should change user-agents."

And why not? What if the device makes this an acceptable solution?

The Samsung Instinct (on Sprint) has a 'button' to switch between mobile or desktop mode. All this does is send a different UA to the site. Granted, this doesn't work for all sites...some will still detect a mobile device and lock you to their mobile site. And some that offer their own switching (like you) then set a cookie, that overrides the UA checking.

But if this was something that more devices did, and more sites had to account for, I think it's a pretty easy way to allow access to both the mobile and desktop versions of a site.

Posted by James Pearce 5 years ago

Hi Jeff, I was just making it clear that when I mentioned that in the article, it was merely as a developer's diversion rather than something I expected users to do.

I'm surprised if users have the faintest clue what they're doing when they toggle such things - or what impact it will have on the made-for-mobile and made-for-desktop sites they visit.

I'd love to know how many average mobile users know even what a user-agent is. Or hey! Even HTTP ;-)

I'd also like to think that a single button on the site itself is easier than "menu - settings - advanced - user-agent - toggle - ok - ok - ok - ok - ok - refresh"

(I'm joking a little but you know what I mean)


Posted by jlbruno 5 years ago


I don't expect that the users would understand the technical aspect of what they are doing.

The button to do this switch on the Instinct is not buried in a menu. Check out the's the third button down on the left.

It either looks like a big desktop monitor, or a cell phone. Clicking it is 'supposed' to switch between mobile and standard version of the site.

Posted by James Pearce 5 years ago

hey - yes, that looks cool ;-)

Posted by admin 5 years ago

Part 2 now available here

Posted by daniel.reyes 5 years ago

Interesting article... but when trying to print it (using Firefox 3) only prints front page. That is, until the end of the first paragraph of "The convenience of convention". Somebody knows why this happens ? Thanks. Whit IE7 print ok.