Not-Device Detection Example Code

25 01 2009

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.

  1. An iPhone/iPod Touch version using /iphone/index.html
  2. A Plain Old Mobile (POM) version using /pom/index.html
  3. 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 too
RewriteCond %{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.

While this may look a little complex if you’re not comfortable reading regular expressions…I think you’ll agree it’s extremely simple when you compare it to this spaghetti diagram over on the .mobi forum.

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

25 01 2009

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 as easily as, 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, or 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.

(Or expect me to write comments like this 😉 No hard feelings I hope!)

26 01 2009
29 01 2009

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,,,, to the mobile site, for those guessing.

However, we still promote our 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.

29 01 2009

Excellent…glad to hear it was useful.

That’s also exactly the same type of approach we recommend to our clients. Implement a basic and robust solution until you have enough hard data to build a real business case for specific devices.

I’d be interested to hear about any specific capabilities or limitations you’ve found that you really needed to or wanted to handle…other than the iPhone of course.

BTW: Your marketing point is a good one. We’re launching an initiative soon that addresses just that point.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: