Server-side capability detection for mobile devices part 2

By Brian Suda

Increasing the user experience

This is part 2; If you haven't already read part 1, do so here.

Now we'll look at some tips to increase the user experience. Let's first look at an example of effectively detecting screen size and serving appropriate content. You thought it was hard to design for 800 x 600 and 1024 x 768? Think again!

Luckily with the help of WURFL we can detect the type of device and check the screen size. Once you have the screen width, you can serve the appropriate size image. My phone is a Nokia 6600, which has screen dimensions of 208x176. The iPhone has a screen size of 320x480. Using the following code, I can check the screen size of the device accessing my site, and serve either a 180 pixel wide image to phones like mine, or a 320px wide image to the iPhone.

if ($width==320){ 
<img src="/images/logos/320.gif" /> 
} else { 
<img src="/images/logo/170.gif" /> 
}

By serving the correct size image, we avoid the need for the mobile browser to shrink the image, making it pixelated and unreadable. It can also minimize the amount of data sent to the phone, keeping data costs down for those who pay by the megabyte. Some of the other capabilities we can check on phones are:

• Support for the tel: protocol
• If it supports access keys on anchors
• If you can use CSS to color backgrounds
• If the device can handle animated gifs
• If the device supports HTTPS
• If the device supports downloadable video and what kinds of video encodings
• If the device supports Flash Lite

Many of these capabilities are booleans (true/false,) allowing us to customize the HTML output before sending the result back to the device. Instead of designing for the lowest common denominator only, we can design a base site and progressively enhance the experience based on phone capabilities. Libraries like WURFL allow you to create a database of these capabilities. When a device visits your site, you can cross-reference the database and get an array of this device's features. There is already an open source WURFL PHP library to do this. If PHP is not your thing, then there are libraries in just about every popular language to suit your needs.

This is some pretty simple PHP code. First, we include the libraries needed for WURFL. The next step is to create a new object - $myDevice - and get the capabilities based on the User_Agent String from the browser. This populates the $myDevice object with all the things it can and can't do. Finally, we check to see if this device recognizes the tel: protocol. If it does, we output HTML with the phone number as a tel: link; If not, we just output it as plain text.

require_once('wurfl_config.php');
require_once(WURFL_CLASS_FILE); // include the main class. This is defined in the configuration file
// creating the WURFL object
$myDevice = new wurfl_class($wurfl, $wurfl_agents);
$myDevice->GetDeviceCapabilitiesFromAgent($_SERVER["HTTP_USER_AGENT"]);
if ( $myDevice->getDeviceCapability('wml_make_phone_call_string') ) {
    echo '<a href="'.$myDevice->getDeviceCapability('wml_make_phone_call_string').'1234567890">click to call me at 123.456.7890</a>'."\n";
  } else {
    echo 'call me at 123.456.7890
\n";
  }

Any detection script will start pretty much in the same manner. All the interesting stuff happens in the if statements. This is where you customize the HTML output for each device. There are many different capabilities you can test for and against, and the full list of capabilities can be found on the WURFL site.

This creates a new instance of the database and references that device's capabilities. To also check to see if the device can support the HTTPS version of the site and redirect or not, I could use this:

if ( $myDevice->getDeviceCapability('https_support') ) {
    header('Location: https://example.org');
  } else {
    header('Location: http://example.org');
  }

This will simply redirect as needed. Another common capability test might be checking the level of CSS support for the device, which can be done like so:

switch($myDevice->getDeviceCapability('xhtml_support_level')){ 
case 0: 
  echo $css_file = 'basic.css'; 
  break; 
case 1: case 2: 
  echo $css_file = 'basic-tables.css'; 
  break; 
case 3: 
  echo $css_file = 'baseline.css'; 
  break; 
default: 
  echo $css_file = 'advanced.css'; 
  break; 
} 
echo '<link rel="stylesheet" href="'.$css_file.'" />';

This allows you to progressively enhance your site to best match the device. I prefer the term "progressive enhancement" over "graceful degradation". Graceful degradation assumes the failure case, which is usually built only after the base-case. The idea of progressive enhancement achieves the same end, but from a different direction, starting with a solid workable base-case. If done correctly, the result is the same - all users are catered for in their experience.

Many of the enhancements discussed within this article are done on the server-side. This makes it more difficult for the client to have a fall-back because the enhancements are written into the HTML before the client receives the data. When dealing with client-side enhancements in the HTML for the browser, things like JavaScript support need to be tested on the client-side - even though the WURFL database says a device supports JavaScript, the user could still turn it off manually.

Summary

If there is only one thing you take away from this article, it should be that the mobile web, despite being a significant part of the one web, will not be the same for every device. This is due to the sheer diversity of hardware in the mobile space (which is not such an issue on the desktop,) and can only be matched by an equivalent diversity of user-experiences. The websites that do not take the time and effort to meet the needs of each customer by enhancing their mobile experience won't be last very long. The best way to make the experience pleasant and successful is to optimize the content for the device with the help of tools like WUFRL (while still making the base line content usable on any device, or course.) This should be less of an issue in the future, as mobile devices should get more powerful, but this is the state of things now.

Brian Suda

Brian Suda works at TM Software http://tm-software.com/ where he tinkers on enterprise websites working in new technologies and streamlining the customer experience.

This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.