Over the last 2 years we’ve been refining a simpler and more powerful approach to device detection than everyone else seems to be focusing on.
While WURFL, Device Atlas, etc. are all great resources for very specific capability profiling…we’ve found that turning the problem upside down made much more sense and delivered faster, better results.
The key thing that most developers seem to be trying to do is to identify if a user IS using a specific Mobile Device.
The problem with this is that the User Agent strings on Mobile Devices are inconsistent at best…and completely useless or even non-existent at worst.
Once you accept this the inverse answer becomes clear.
PC browsers are much more reliable and consistent in identifying the Operating System they belong to. Also, there is only a small handful off Operating Systems you need to detect. So this is how our solution works.
We call this !device-detection (“Not Device” Detection).
If your User Agent isn’t one of the following Operating Systems:
- Windows - Macintosh/Mac OSX - Linux - FreeBSD - Solaris - (Add niche OSes here)
And your User Agent doesn’t contain one of the following strings:
- bot - slurp - spider - crawl
Then you are almost guaranteed to be on a Mobile Device.
Within this group you can then also clearly identify the important groups that are consistent:
- iPhone/iPod Touch - Windows Mobile
We have implemented this method for two major Telco’s a major Insurance company, our leading edge Mobile Payment service and our own web projects. This is a strategy that has proven to be very effective and only requires a simple set of regular expressions in the form of Apache mod_rewrite directives that can work in either Apache or IIS.
We also couple this with a simple design pattern that provides a link from the Mobile site back to the PC site just in case we accidentally mis-classify a user. After all they should be able to ask for the full PC version if they really want it.
We’ve also recently put together a case-study that looks at some well known large corporations in Australia to see how they are or are NOT handling automatic device detection. The results are very surprising.
A full copy of the presentation is online on slideshare
Now we thought it’s time we shared this strategy in order to broaden the on-going device detection discussion.
The SmartMOB Toolkit 
Superb solution. Elegant and wonderfully !what-everyone-else-is-doing.
i guess it is about what your end goals are. In some cases, our clients want specific designs and UI for each mobile device.
In other cases, we need to push specific compatible content to mobiles – where you need to know the exact device and campabilities.
You mentioned device atlas which i will check out now – Have you tried handsetdetection.com?
Hey Don,
absolutely agree it should be based upon your goals.
Both handsetdetection.com and atlas are based on WURFL…which is very easy to use independently of those services.
We’re not advocating against WURFL…just that it’s not needed unless you’re targeting specific fringe features of non-mainstream handsets.
We’ve done this in a few cases for some of our Telco clients that had devices with 128px wide screens and low memory profiles.
However these were still best treated as exceptions to our “Not-Device” Detection model.
is your script available for others to use?
Hi Seth,
it’s a pretty simple set of regular expressions in your httpd.conf – or could be implemented as a script if needed (but a script is slower).
We’ll probably put some examples online after xmas…but feel free to send me any questions you have in the meantime.
After xmas … Please share some code for your genius approach … I don’t like to be the first one who posts his newbie version here!
A couple of years ago this solution wouldn’t have been feasible but we have come along way, devices are more capable!
As mobile becomes more popular users will want to consume more diverse content meaning more device capabilities which will not particularity be standardized
This method will work very well for serving basic xHtml pages but would cause problems when serving more complex content
Let’s use a very simple example, say I run a mobile portal and I would like to provide streaming video in different quality, low for 2.5g, medium for 3G and high for HSDPA.
How would your solution take into account serving the correct content to devices?
Hi John,
yes “Not-Device Detection” is designed with xhtml mobile websites in mind. The goal is to allow people to promote “one web address” that supports all the relevant devices.
Images, audio and video are indeed more complex. The serving is pretty straightforward (even for streaming media), but matching it to the device and network capabilities can be a pandora’s box.
Just taking your example – you could easily use WURFL to identify the connection bearer that a specific device supports. However this will effectively just tell you the “max_data_rate” and not the “current data rate”. The problem here is that many HSDPA or 3G devices roam onto lower speed networks like GPRS if the connection is poor.
This just leaves two options.
First, you could test the connection speed through transfer monitoring at the server level to guestimate how fast the device is downloading data. However this is just a guestimate…and even if the user starts on something that looks like an HSDPA connection, it doesn’t mean they’ll stay on that speed throughout the download. Otherwise this is a reasonably viable solution. If you’re interested in how this works I can put together a more detailed post for you.
Second, you could use network introspection using information from the user’s Telco. However there’s two big challenges here. First, this means you need an API level connection to all of the Telco’s that your users may be connecting from. On our mobile websites we see users connecting from all over the world and just the integration costs for this would be prohibitive. But even if you could do that the single biggest problem is that most Telco’s “still simply cannot tell you the answer”. Not for any security or privacy reasons…just because they can’t. For example – we recently architected a multi-device portal system for one of the largest Telco’s in Australia and another one for one of the largest Telco’s in the world and neither of them had the relevant internal facilities for identifying the current bearer speed for an individual user.
One simple options is to just let the user choose (e.g. “low” or “high” bandwidth) as people did on the web for a long time. It’s not ideal…but does give the user control.
This is an interesting area for discussion, thanks for you question.
Using the small set of known OSes is a very interesting approach, as it makes the detection algorithm a lot more lightweight and easier to understand and modify.
If I’m not wrong, this is your algorithm:
isMobile = ALL – desktop – bots
I’d be interested to find out what is the false-negative rate, i.e. detecting a mobile device as !isMobile. For example, could there be browsers on LinMo devices that send “Linux” as their OS? (I don’t know LinMo, just a hypothesis.)
In any case, I like it enough that I’ll probably replace the detection script at my site to use this technique instead.
Thanks for sharing!
Hi Wil,
that’s a nice efficient summary of the algorithm…yes 8)
We have had some cases of false-negative’s, however the set is very minimal.
One example is a certain model of Palm Treo that pretends to be Win98. Another example is certain transcoding services.
Our view on this is that these devices/services are “!telling the truth”.
We have two strategies for dealing with this.
1. If we can justify that this is a reasonable size or valued group of users then we put in an exception. Currently this set on our client’s sites in production is very small. We’ve also found that this approach is less work and less fragile than constantly updating the traditional model as new devices/manufacturers are added to WURFL.
2. We provide a common design pattern across our sites to let users switch to the device view they want. This helps them become aware there are multiple views available as well as providing choice and helping with SEO.
BTW: If you find any specific devices you think break this model please post them here so everyone can benefit from this information.
Thanks for the feedback and good luck with your site…
Hey Rob,
I’m glad developers are speaking out about some of the other tricks of mobile device detection!
A couple of other cards we’ve played at Mobify include looking for X-WAP-PROFILE HTTP header and checking the whether the HTTP ACCEPT header includes mobile specific content.
I’ve written a short piece on it including a Python port of some of your Apache Rules:
http://notnotmobile.appspot.com
Cheers,
John
Hey John,
excellent work…I’ll have a good look through your python code and let you know if we have any feedback 8)
I’d also be interested to see some stats on your X-WAP-PROFILE usage and how that relates to what’s in WURFL too?
We’ve been doing similar analysis for a few specific features and will feed these back into WURFL to fill in some holes.
Thanks for the contribution…
roBman
[…] browsing the page and decides whether it’s a mobile or desktop browser using a basic “Not Device” detection […]
I have published the new version of Apache Mobile Filter, now the filter is give to you the information of capabilities as apache environment.
Now you can develope in any language (php,jsp, ruby etc.) and have the information of mobile capability.
Read more info here: http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html
The new Apache Mobile Filter looks great Idel…we’ll definitely test that out.
Thanks for the update.
Thanks for sharing this clean and efficient approach. -Eric