You were very polite but methodical in your analysis of a document that obviously needs a lot of review.

Thanks for the update.

Read more info here: http://www.idelfuschini.it/it/apache-mobile-filter-v2x.html

excellent work…I’ll have a good look through your python code and let you know if we have any feedback
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

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

for help on setting up php on your server you should check the standard installation guides.

http://php.net/manual/en/install.php

Then, once you’ve got that working just update your httpd.conf file using the example we provide as a guide and then restart your server.

http://smartmobtoolkit.wordpress.com/2009/01/25/not-device-detection-example-code/

Or alternatively just install the php function in the top of your index.php script and use it to decide which page content to output or which URL to redirect to.

http://smartmobtoolkit.wordpress.com/2009/01/26/not-device-detection-javascript-perl-and-php-code/

I hope that helps…

I’ve been doing quite a bit of searching to find ways to detect the presence of a mobile device requesting my website and automagically redirecting them to a more mobile-friendly version that I’ve already created…ok, it still needs some work, but it’s a start. It didn’t take me too long to figure out that this is an issue with a number of different solutions – I’ve also followed your discussion with James over at mobiforge.com.

Here’s what I still need some help with:

I’ve already set my host up to field a subdomain of mobile.mysite.com and directed it to a directory called /public_html/mobile which contains the index.html and all other pages of the mobile version of my site, including reduced sized images, etc. The only way I can get to the mobile site is to type the full address into the location bar of my browser. I’d like people to be able to got to http://www.mysite.com and get the correct version, based on which browser they’re using, but still be able to switch between the versions by following a link.

I just don’t know how to implement the codes that you (or anybody else, for that matter) have written. How do I “turn on” php on my host? What files do I need to have in the root directory to make the code work, and what lines do they need to contain? Basically, I believe that I have all the pieces of the puzzle – I just don’t know how to make them work with each other.

I welcome your response via this forum, or via email if you’d like more specific information or access to the host server to point me in the direction of what I’m doing wrong.

Thanks for your time,
Mark Scureman

that’s a nice efficient summary of the algorithm…yes

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…

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!

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.

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.

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.

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?

har…I think we established your love of WURFL during our discussion on your blog earlier

I also still stand by my comments that WURFL is a great tool for general device capability research – but a terrible tool for doing live profiling if you try to use it to cater for too many different capabilities.
http://beradrian.wordpress.com/2008/10/10/mobile-device-recognition/#comment-199

Either you create a design nightmare or you use automatic size and format transcoding and lose control over image quality and design integrity. You also drive up complexity.

I have yet to see a good business case that justifies a site supporting hundreds if not thousands of different individual device profiles. I believe they should only support somewhere between 3 and 10 depending upon your business model and target audience.

Don’t get me wrong…I LOVE WURFL too…I just think we have really different views on how to use it.

following up from our email discussion I’ve posted some GPL’d code in javascript, perl and php – see http://smartmobtoolkit.wordpress.com/2009/01/26/not-device-detection-javascript-perl-and-php-code/

Hope you find this useful.

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.

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