A Very Modern Mobile Switching Algorithm – Part II

This article follows on from last month’s Part I, where we discussed some of the principles of handling mobile users and switching their experiences. If you haven’t read it yet please do so before we dive into some of the technical ideas and implementation details.

By the end of this article, I’ll be assuming you’ve got some programming skills and know fairly clearly what we are trying to achieve!

If you recall, we’ve chosen a blended approach of a two-site configuration (one each for mobile and desktop users), browser detection (to spot if the user has likely visited the right one), and user choice (allowing them to override our judgement for whatever reason).

Although I didn’t mention it in the body of the article itself, one of my follow-up comments drew the direct analogy with country-code domain switching. Many international services use your desktop’s IP address to detect whether you’ve likely visited the right country-specific site or not. The left-hand image shows what you see when you visit http://expedia.com (by implication, the US service) from Ireland, for example:

Notice how you have the chance to override their judgement – you may be checking flight domestic US flight prices for a friend, for example – and your choice can be remembered by the service. The right-hand image shows the links (which Expedia place at the bottom of the .com site) that let you switch back to the other countries’ sites.

Here, we are going to do exactly the same thing for mobile, with one exception: we won’t be giving the user an option as to whether to have their choice remembered. Since this decision will be stored in a cookie (which is bound to the desktop or mobile browsers separately anyway), they will rarely need to change their choice, and we may as well make it persist by default.

The algorithm state machine

Part I of this article described how the switcher algorithm behaves from a user’s point of view. Essentially we can display desktop pages, mobile pages, interstitials, or provide a redirect from one domain to the other. I recommend you remind yourself of the nature of the two interstitial pages and the experience we are trying to achieve.

From the serving application’s point of view summary, we want our algorithm to broadly behave like this:

• If the user has a desktop browser, has requested a desktop page, and hasn’t previously expressed a desire to have the mobile experience on this browser, give them that desktop page. If they have, redirect them to the corresponding mobile page.
• If the user has a mobile browser, has requested a mobile page, and hasn’t previously expressed a desire to have the desktop experience on this browser, give them that mobile page. If they have, redirect them to the corresponding desktop page.
• If the user has a desktop browser, has requested a mobile page, and hasn’t previously expressed a desire to have the mobile experience on this browser, give them the desktop interstitial to confirm their desire.
• If the user has a mobile browser, has requested a desktop page, and hasn’t previously expressed a desire to have the desktop experience on this browser, give them the mobile interstitial to confirm their desire.
• If the user has either browser, is on either page, but wants to switch to the other experience, let them click a link that explicitly takes them there (and register that desire).
• Ensure that users can’t get into an infinite redirect loop between the two sites.

In the hope that a picture tells a thousand words (although I’m slightly dubious), we can model these flows visually. On the left we have a desktop user, and on the right, a mobile user. At the top, we indicate the desktop domain, and at the bottom, the mobile domain. The legend for each of the connecting lines is below the diagram.

• A: Desktop browser, desktop domain, no cookie to indicate mobile preference. Gets desktop site.
• B: Desktop browser, desktop domain, cookie to indicate mobile preference. Redirects to mobile site.
• C: Desktop browser, mobile site. Interstitial to confirm choice:
  – (unless D: cookie to indicate mobile preference. Gets mobile site.)
  – (unless E: cookie to indicate desktop preference. Gets desktop site.)
  – followed by F: choice confirmed for mobile. Gets mobile site.
  – followed by G: choice confirmed for desktop. Mobile domain cookie set if possible*. Redirects to desktop site.
• H: Mobile browser, mobile domain, no cookie to indicate desktop preference. Gets mobile site.
• J: Mobile browser, mobile domain, cookie to indicate desktop preference. Redirects to desktop site.
• K: Mobile browser, desktop site. Interstitial to confirm choice:
  – (unless L: cookie to indicate desktop preference. Gets desktop site.)
  – (unless M: cookie to indicate mobile preference. Gets mobile site.)
  – followed by N: choice confirmed for desktop. Gets desktop site.
  – followed by P: choice confirmed for mobile. Desktop domain cookie set if possible*. Redirects to mobile site.
• Q: Either browser on either site, changes choice. Current domain cookie set if possible*. Links to other site.

* NB, if we are providing a link to go from one domain to the other, we have to use client-side Javascript to set a cookie on the domain we are leaving, since there will be no further HTTP responses from that domain, and cookies are domain-scoped. However, this fails relatively elegantly for non-supporting devices and search crawlers: it merely means the interstitial will appear again upon re-visiting the original domain.

Although this may seem very complex, in fact, when deciding which actual response and markup to deliver to the client according to these rules, the serving application only has four variables available to help make that choice:

• The domain requested by the client: example.com or example.mobi
• Certain headers sent by the client: to be identified as either a desktop or a mobile browser
• A cookie to indicate which experience the user has previously preferred, if any
• A particular magic CGI parameter: to indicate that the user is transitioning from one site to the other

Detecting the domain that was requested by the user is very straightforward in most server-side environments. It can be taken straight from the HTTP “Host” header that appears in each request from the client. And the user-agent (amongst other headers used for recognition) is extremely easy to determine too. Figuring out whether it is a mobile or desktop browser is slightly harder, but still straightforward (as we will see).

Cookies also occur in HTTP headers sent by the client, and CGI parameters occur at the end of a URL (?like=this). Both are easy to access, and your server-side environment probably provides convenient ways to access their values directly.

Incidentally, each of the four variables listed above take either a binary or tri-state value: “mobile” or “desktop” – or not present at all, in the case of the last two. Don’t forget that there are two cookies in play here. Since cookies are scoped to a domain, there is one associated with the mobile domain, and one associated with the desktop domain, each of which may take the values ‘mobile’ or ‘desktop’.

It may not yet be clear to you why we need the magic CGI parameter too. Let’s take a few minutes to think about that. As you might have noticed, there’s an unpleasant condition that might occur if the two cookies contradict each other. If the desktop domain cookie indicates that a mobile experience is preferred, and the mobile domain cookie indicates that a desktop experience is preferred, the user will go around in an infinite loop. Not good.

So what we do is place an extra parameter on the URL when redirecting or linking the user from one domain into the other. This basically is the first domain’s way of saying to the other “the user really wants to come back to your site: ignore their previous choice to switch away from you”. This CGI parameter therefore needs to take priority over cookies.

The truth is in the tables

So let’s consider the logic of actually serving up a page. For simplicity in this article, let’s assume that both domains are actually resolving and being served by the same web application. (This means we can do everything in one piece of code too). When a user requests a page, and in response to the four variables above, the web application will execute one of six possible outcomes:

• R1: a desktop page on the desktop domain
• R2: a mobile page on the mobile domain
• R3: a redirect to a mobile domain URL corresponding to the requested desktop page
• R4: a redirect to a desktop domain URL corresponding to the requested mobile page
• R5: a mobile interstitial prompt page
• R6: a desktop interstitial prompt page

For all of the four variables, we need to list their possible values, and map them to the six possible outcomes. This is the essence of coding the algorithm, and it’s time for some good old-fashioned truth tables: just like your electronics teacher used to love.

For four variables, with two or three relevant states each, there are theoretically 36 possible combinations. Fortunately, it turns out that only 16 of these are actually distinct and relevant for the purposes of this algorithm. You can confirm this as ‘an exercise for the reader’ if you like – but we’ll cut straight to the critical combinations in the table below.

* NB, remember we can only consider the cookie relevant to this domain

Take some time to think through a few of the rows above. You ought also to be able to see some comforting symmetry. I’ve spent some time trying to reduce this truth table to a series of simpler conditions, but sadly, the best efforts of Boole and De Morgan have proven fruitless: you’ll see the table above appearing fairly unchanged in the final code. Another experiment for the reader: to try and do better!

Anyway, phew… I hope you’re still with us. Don’t worry, it gets (a little) more straightforward from here on.

Pseudo-code

As I mentioned, it’s simplest to consider a single application with both the desktop and mobile domain resolving to the same scripts. Of course you can separate them out if you want. But in the approach below, we will need a check to determine the domain that the client browser has requested.

Let’s first articulate the logic from the above section into some simple code. We’ll assume that the logic is run with the following variables set:

These aren’t always each other’s complement. If desktopDomain is true, then mobileDomain is theoretically false (and vice versa), but if desktopCookie is true, then mobileCookie isn’t necessarily false (since neither may be present). We can also hedge our bets slightly with the browser recognition (which is never quite the exact science it should be). There may be circumstances – thanks to troublesome user-agents – where we are fairly sure that a browser can be treated as a desktop, even if we are not completely sure that it is not mobile.

Armed with these variables, let’s launch into the logic with some pseudo-code – to be read in conjunction with the table above. The return value from this function is R1, R2, etc (as listed in the table) indicating the correct response to return to the user.

Using the return value, the code that calls this function will then decide what to display or render.

Setting up an environment

We’re getting close to the point at which we can start building our own switchr. In theory, we have discussed enough of the switcher approach for you to implement it in entirely your own way – with a pattern appropriate to your language and platform of choice – and in a way which is sympathetic to your application design.

Nevertheless, we’ll go ahead and build one as part of the remainder of this article. I guess you could take this code verbatim if you want – it comes with no warranties! – but more importantly, we’re doing this to make sure you understand how one can put the theory above in to practice.

A word on setting up the environment for running this sample implementation. I’m assuming you know how to get a web server (in this case, Apache) up. We basically want two complementary domains pointing through to the same application code. We’re going to have a single file called index.php: you should place this in a directory somewhere:

… and configure the Apache server to serve up that file or directory for two vhosts. In your configuration file, you should have something like:

Note that this is not intended to be a replacement guide for configuring your web server! There’s plenty out there to help you get started with such matters.

Both domains’ DNS entries need to resolve to this server. It’s unlikely that you own the root domain records for example.com and example.mobi, so if you want to use those two, you’ll need to override the DNS entries for them on the system you’re testing this out with. You can do this in your /etc/hosts file (also available, but deeper down under ..windows/system32/drivers/ on a Windows machine). Assuming your browser will be on the same machine as the web server, something like this should do it:

Alternatively, simply replace the domains in the code below with two that you do have proper registry/hosting control over. That will be important if you’re planning to test this out with a real phone coming in from an external network.

Finally… some code!

The moment you’ve all been waiting for… You’re probably ready to see some real code. As I’ve said, this is a sample implementation. But feel free to drag, drop, copy or paste portions into your own applications. I’ve chosen to use PHP since it’s relatively easy to understand for most developers – and a little bit of find and replace should see it quickly working in Java or C# environments.

Firstly, let’s implement the switcher logic from above as real code. We start off by defining some constants representing the various responses that the switcher can return.

Secondly, let’s provide some settings, an entry point the switcher as a whole, and some code that will call functions to actually populate the incoming variables:

Having retrieved values for the main variables, we then retrieve the outcome from the switcher algorithm, and pass it on to a handler that will return a suitable response. (We’ll come back to that function itself at the end of the article).

The first two constants at the top of this portion of code should be changed to map to the domains you are using in your application. The second two are the names of the cookie and CGI parameter respectively. You don’t have to change these unless you happen to use cookies or parameters named “switcher” in your application for some other reason.

The function to identify which domain has been used to reach this application needs simply to check whether the HTTP “Host” header finishes with a sufficiently-qualified portion to distinguish one domain from the other:

Moving on to the recognition, there are a number of ways to identify whether a browser is a desktop or a mobile client. For example, dotMobi’s DeviceAtlas database contains two relevant properties: “isBrowser” and “mobileDevice”.

For the purposes of keeping this implementation self-contained, we are going to use a derivation of Andy Moore’s mobile detection code (as introduced here), and simply use its inverse as the desktop detection rule.

Since this is therefore being called twice, we put a global variable at the top to act as a cache for performance purposes. If you’re building your switcher in an OO-way, you’d make this field static: it won’t change during the lifetime of a page (or indeed during the lifetime of the session, but that’s another topic).

Finally, we need to be able to access cookie values, and whether the magic CGI parameter has been set. PHP makes both very easy:

This, collectively, is enough code for the switcher to decide what to do. But of course that’s not the whole story: we need to actually act upon that decision. The way in which the interstitial pages are displayed – and especially the pages of you sites themselves! – will be up to you. But we’ll run through some placeholder examples here, if only because we need to show how the cookies and CGI parameter get set.

Firstly, let’s have a function that renders a link to switch to a given one of the two domains:

This section of code has two noteworthy aspects. Firstly, note how we use Javascript to attempt to set the preference cookie on the domain we are just about to leave. This is great if it works, but degrades gracefully – as we mention above – if it does not.

The second function is responsible for placing the magic CGI parameter into links to the other site. It may seem a little verbose, but that’s because we would like the same URL path to be present when the user arrives at the other site (rather than merely taking them to the top of it). Since your application may already use CGI parameters, our code is making sure we’re not destroying parameters that already there – and that it isn’t in the query string already.

Remember that the presence of this CGI parameter is used to overrule any previous cookie preference on the destination site. It only needs to be present on that first request (because the cookie will get changed to update your new desire) and need not be preserved whilst moving around inside the application subsequently.

The third function here is convenience to set a cookie value for the user’s preference in a response from the server.

Emitting some markup

Now we are in a good position to prepare a response to the user. Let’s start by creating two interstitial page templates. Now, it’s certainly a bit crude to place HTML as literally as this into the middle of a script, but of course you’ll be able to adapt these as much as you wish in your own applications.

You can actually make one interstitial page plain enough to work on both desktop and mobile browsers: no device adaptation is particularly required for a page as simple as this. But feel free if you’d like to have them separate. I’ve done so here to make it clearer what’s going on.

Let’s also write a couple of simple “Hello world” pages that represent the mobile and desktop variants of your site. Of course this is merely for demonstration: you’ll need to figure out how to best wire this into your own application. But look carefully: they show at least how you’ll want to use the link function to place a link from each site to allow users to switch to the other.

Integrating it all together

We now have all the pieces of the jigsaw. Just to summarise, we have:

• Functions that provide us with the clues as to what the user is requesting (e.g. _switcher_is_desktop_browser)
• The main decision tree of the algorithm (_switcher_outcome)
• Functions for creating links between sites (_switcher_link and _switcher_current_path_plus_cgi)
• Two interstitial page functions (e.g. _switcher_mobile_interstitial)
• Two placeholder page functions (e.g. _switcher_mobile_page)

The only logic we are now missing is that which takes the outcome of the switcher and dispatches the correct response. That’s fairly simple:

Note how we use the PHP header() function to change the Location: header and create a redirect. Specifically we’re looking for a temporary HTTP “302” response code here (rather than a permanent “301” which might prevent a browser from ever revisiting the original site.)

The proof of the pudding

And there, folks, we have it. Our simple implementation!

Let’s put all that code into a single file, our index.php that’s sitting at the top of the web server. (I’ve created a complete index.php from all the fragments above and peppered it with a few comments. Download it here, unzip it, and save it in the web server directory we discussed above.)

Then pull up a web browser on a machine that can resolve the two domains. It’s very helpful if you’ve got something like the Firefox User Agent Switcher to check this out – with a few mobile user-agents in your list already.

Firstly, leave your browser’s user-agent set as the default desktop browser. Visit the desktop domain. Fingers crossed, you should see:

It’s detected us correctly as a desktop user, and given us the desktop page on the desktop domain. I’ve opened up Firecookie to be able to show you that the server has also set a cookie on this domain to suggest our satisfaction with this choice.

Now, imagine that you would like to see the mobile site despite your browser’s abilities. Click the switch link in the page. You’ll get the mobile site:

No surprises here – but notice how the URL contains the magic CGI parameter. If we’d followed the link to get here without it, there might have been a previously-set cookie to send us straight back again.

Now, let’s say you type in the desktop domain address again, directly. Don’t click the link in the page: simply type in http://example.com to your browser address bar again.

You should now find yourself looking at the mobile page again. This is because you’d previously expressed a preference not to have the desktop experience, so it sent you straight back here. In my installation of Firecookie, (I think it might be a bug in their plugin!) I’m even able to see the cookie that is set back on the desktop domain – with the value ‘mobile’ – which provoked this behaviour.

Next, remove your cookies (with Firecookie or by clearing your browser’s temporary files). Change your browser’s user agent to a mobile device – say, the Nokia N73 – and type in the desktop domain, http://example.com, again. You should find yourself looking at the interstitial page:

From here, you can either proceed to the mobile site (as appropriate to your user agent) or continue to the desktop site (as indicated by the address you typed in). Exactly what we wanted!

Finally, to give you some confidence that this will work for any page within your site, add an arbitrary CGI parameter onto the end of the address in your browser bar, such as …/?a=1.

You’ll notice that this gets preserved as we move around between the sites and interstitials. This allows people to share bookmarks and not have to worry about which type of browser their friends are using!

The End

Well, thank you for making it through to the end of this epic article. I hope you think the effort was worth it.

I am convinced that the key to a successful mobile web for today and the future is being able to cater for a range of different experiences whilst retaining user choice. This switcher represents a very flexible way to do that.

If you’d like to take the switcher algorithm and the code further, please do so: the code comes with no warranty, but feel free to take it, use it, extend it, and publish it as you wish. There are also some pretty icons you can decorate your links with.

Otherwise, have fun. Please share your experiences back with us in the comments below – and let us know how you get on. Good luck!