Home :: Data

WURFL to Perl Data

Basic Philosophy

Our basic philosophy is to use the WURFL Project Data as a last 'best guess' and to ensure certain minimum capabilities for mobile device access to a website. Only pages in xHTML format will be served up by MobileSiteOS™ software, so WAP devices need not apply. Also, screen sizes smaller than 170px are not accommodated either. And these capability minimums might increase in over time, to reflect the increased capabilities of newer devices. In the future, a minimum of 220 - 240px may become the norm. The idea is to provide a working website for as many devices as possibile. This concept, also known as the "One Web", has the advantage of allowing site access to the same content from one set of scripts and urls.

First JavaScript

Device detection starts with JavaScript and the user's browser telling us what display size to select. So normally, we won't even use WURFL which is computationally intensive. If JavaScript is turned off or not available (many mobile devices), we give WURFL a try. For our WURFL to Perl conversion we decided that the raw WURFL XML Data size was too larger to use directly, (10+ Mb at this writting). Employing Perl, we select only WURFL groups of infomation we want and we massage that data into Perl hashes of less than 1Mb total size (currently 750 Kb). Not great, but much more manageable. Again, the idea is to use WURFL only when the user's browser won't give us the info directly and only when a new user enters the site. Return users (with cookies enabled), will be presented pages as before.

User Agent vs Device Id's

We also decided to do away with "device id's" in favor of using an encoded version of the "user agent" string. By comparing the incoming user agent string to our encoded Perl hash of user agent strings, we get the same WURFL Project Data 'fall back' process, while also being able to make a 'partial match' for currently unknown devices (user agent strings). An important step was to shrink down our encoded Perl hash of ua's to just the 'unique' component. The premise is, most unknown user agent strings will have a common base to something already in the WURFL data. Thus, we get to make a 'best guess' in all cases. It also meant a great reduction in database size.

WURFL Data for MobileSiteOS™

Now for a more detailed review. The WURFL groups we selected for use are 'ajax', 'display', 'image_format' and 'markup'. These compare to those available as listed on the WURFL Help page. In the MobileSiteOS™ Basic Demo here, we really only use the group 'display' for it's resolution width value. Our WURFL to Perl conversion starts by setting minimum values for certain data points such as display resolution (170px) and xhtml markup level (1). If a device misses the minimum, it's info (capabilities data) is discarded. Again, we only care about devices which meet our minimums. Next we encode WURFL user agent strings, do some fancy Perl comparisons and produce shortened 'unique' encoded user agent based hash keys. From these Perl hash keys, we seek a 'best match' to the incoming user agent of the current user. This all works reasonably well because we use a combination of brute force searches (Regex) and textual data comparison, but only when new users enter the website. From this point on, our process works the same as WURFL. We roll up the capabilities by combining each successive 'fall back' user agent (device id in WURFL terms) and provide a best guess of current browser capabilities in Perl hash form.

MobileSiteOS™ Demo

Features

Reference