Not-Device Detection Example Code

Well I guess it wasn’t “just” after xmas – been a bit busy enjoying the Australian summer!

We’ve had a lot of interest in the “Not-Device Detection” solution and lots of requests for example code so here it is.

Below is an example snippet from an httpd.conf (e.g. configuration for Apache) using mod_rewrite. This assumes you have 3 main version of your homepage.

An iPhone/iPod Touch version using /iphone/index.html

A Plain Old Mobile (POM) version using /pom/index.html

A standard PC version using /index.html

Of course you can apply this model to more sophisticated solutions that also single out other specific devices or more complex collections of sub-pages. Other examples of this could also be implemented using perl or php scripts, but the performance is much better at the web server configuration level.

So, for this example let’s step through the code.

First make sure you have the RewriteEngine switched “on”.RewriteEngine on
Then detect the iPhone/iPod Touch first since they’re so easy to identify.# iPhone/iPod redirected to iPhone index
RewriteCond %{HTTP_USER_AGENT} ^.*iP(hone|od)(;|\s).*$
RewriteRule ^/$ /iphone/index.html [PT]
The line below allows a user to choose to view the PC version by adding ?pc to the URL (e.g. from a specific switcher icon)RewriteCond %{QUERY_STRING} !^pc$ [NC]
You may want to exclude a number of standard bots here using generic strings.
You may also want to add exclusions for specific monitoring tools etc. here tooRewriteCond %{HTTP_USER_AGENT} !(spider|crawl|slurp|bot) [NC]
Then here’s the meat of the “Not-Device Detection” solution. You’ll notice that it mostly consists of !^ statements that say if this browser is NOT Linux, NOT Windows (excluding Win CE), NOT OS X or OS 9, NOT Solaris and NOT BSD then we’ll assume it’s a Mobile Phone and redirect it to /pom/index.html.# Plain Old Mobile (POM) redirection (by exclusion)
RewriteCond %{HTTP_USER_AGENT} !^.*Linux.*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*Win.*$ [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*Windows\s+CE.*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*OS\s+(X|9).*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*Solaris.*$ [NC]
RewriteCond %{HTTP_USER_AGENT} !^.*BSD.*$
RewriteRule ^/$ /pom/index.html [PT]
Otherwise it should just receive /index.html as normal.

I’d like to thank James for creating this work of art…now whenever I want to explain to a client why having a .mobi domain is a wrong headed and silly idea that makes your web strategy more complicated I just point them to this single diagram.

Anyway, I hope you find the example configuration described above useful. If you have any questions or would like any help implementing this please post a comment here.

4 responses

It’s always sad when people are impolite about your own hard work. I think it’s unprofessional too. Still, if it keeps your clients happy…

Our algorithm has nothing to do with the dotMobi domain. It’s a piece of free advice that reflects what most modern mobile developers are trying to do with their sites.

Also, you are hardly comparing like-with-like. “You think a calculator is complex? Well wait until you see a spreadsheet!”

You’ve come up with a simple pattern to distinguish mobiles from desktops. There are many of these around the web; some even from the earliest days of WAP.

I think you are being very novel in identifying desktops rather than mobiles (which is more common and less elegant). That’s very cool, and I would strive use it within our approach. I also like the implicit performance you’ll get from running it in Apache rather than the app itself.

But otherwise, I can only assume you didn’t read our article or didn’t understand it.

You’ve entirely forgotten about the human on the other side of that device.

The key point of our algorithm is that it leaves the opportunity for the user to override the decisions that the detection makes, toggle between the sites, (depending on their context and state of mind), yes, support multiple domain entry points if branding dictates (but that can be m.site.com as easily as site.mobi), and then remember the user’s decision so that they can have a streamlined experience the next time.

None of that is possible with your simpler approach.

I’m afraid to say that single-entry points for both PC & mobile sites are rather rare these days, I think because few mobile users have the confidence to try arbitrary URLs.

State-of-the-art is to have m.site.com, iphone.site.com or site.mobi. Now that may seem cumbersome, I agree, and will probably change over time, but it seems to be a convention right now.

It also seems to be what the mobile search crawlers expect – and I wonder if you’ve done any mobile SEO analysis on this approach. (After all, you are banning them from your mobile site altogether… now that *is* novel!)

The bottom line is this: do you really think your regular expressions are smarter than your clients’ customers?

I think you’re bringing something very interesting into the mix here, but please leave the attitude at home.

Thanks for the code – it was very easy to include this into our site to serve a simple version for our mobile use case. I like the option to access the desktop version with the “pc” query string.

I think the not device detection is a great and fast way to forward users to the mobile site, if they are trying to enter our regular and most pormoted domain name into their phone. We are also forwarding common domain patterns like example.com/m, example.com/mobile, example.mobi, m.example.com, wap.example.com to the mobile site, for those guessing.

However, we still promote our mobile.example.com domain, just to tell our users that we are “mobile ready”. But that’s marketing.

Once we know our most popular devices, we start adding bells and whistles for them – detected by WURFL & Co.

MOB are an Innovation Lab specialising in Mobile and Online Business. We work with you to turn your ideas into profitable operating business models. We develop solutions that get you MO'Business.http://MOBusiness.com.au