Luigi's Pizza On The Run mobile shop is working well now. And he wants to adapt it to different mobile devices. Let's look at the following:

• Understanding the Lowest Common Denominator method
• Finding and comparing features of different mobile devices
• Deciding to adapt or not
• Adapting and progressively enhancing POTR application using Wireless Abstraction Library
• Detecting device capabilities
• Evaluating tools that can aid in adaptation
• Moving your blog to the mobile web

By the end of this article, you will have a strong foundation in adapting to different devices.

What is Adaptation?

Adaptation, sometimes called multiserving, means delivering content as per each user device's capabilities. If the visiting device is an old phone supporting only WML, you will show a WML page with Wireless Bitmap (wbmp) images. If it is a newer XHTML MP-compliant device, you will deliver an XHTML MP version, customized according to the screen size of the device. If the user is on iMode in Japan, you will show a Compact HTML (cHTML) version that's more forgiving than XHTML. This way, users get the best experience possible on their device.

Do I Need Adaptation?

I am sure most of you are wondering why you would want to create somany different versions of your mobile site? Isn't following the XHTML MPstandard enough?

On the Web, you could make sure that you followed XHTML and the site will work in all browsers. The browser-specific quirks are limited and fixes are easy. However, in the mobile world, you have thousands of devices using hundreds of different browsers.

You need adaptation precisely for that reason! If you want to serve all users well, you need to worry about adaptation. WML devices will give up if they encounter a <b> tag within an <a> tag. Some XHTML MP browsers will not be able to process a form if it is within a table. But a table within a form will work just fine. If your target audience is limited, and you know that they are going to use a limited range of browsers, you can live without adaptation.

Can't I just Use Common Capabilities and Ignore the Rest?

You can. Finding the Lowest Common Denominator (LCD) of the capabilities of target devices, you can design a site that will work reasonably well in all devices. Devices with better capabilities than LCD will see a version that may not be very beautiful but things will work just as well.

How to Determine the LCD?

If you are looking for something more than the W3C DDC guidelines, you may be interested in finding out the capabilities of different devices to decide on your own what features you want to use in your application. There is a nice tool that allows you to search on device capabilities and compare them side by side. Take a look at the following screenshot showing mDevInf (http://mdevinf.sourceforge.net/) in action, showing image formats supported on a generic iMode device.

OK, So How do I Adapt?

You have three options to adapt:

1. Design alternative CSS: this will control the display of elements and images. This is the easiest method. You can detect the device and link an appropriate CSS file.
2. Create multiple versions of pages: redirect the user to a device-specific version. This is called "alteration". This way you get the most control over what is shown to each device.
3. Automatic Adaptation: create content in one format and use a tool to generate device-specific versions. This is the most elegant method.

Let us rebuild the pizza selection page on POTR to learn how we can detect the device and implement automatic adaptation.

Fancy Pizza Selection

Luigi has been asking to put up photographs of his delicious pizzas on the mobile site, but we didn't do that so far to save bandwidth for users. Let us now go ahead and add images to the pizza selection page. We want to show larger images to devices that can support them.

Review the code shown below. It's an abridged version of the actual code.

<?php
include_once("wall_prepend.php");
?>
<wall:document><wall:xmlpidtd />
<wall:head>
<wall:title>Pizza On The Run</wall:title>
<link href="assets/mobile.css" type="text/css" rel="stylesheet" />
</wall:head>
<wall:body>
<?php
echo '<wall:h2>Customize Your Pizza #'.$currentPizza.':</wall:h2>
<wall:form enable_wml="false" action="index.php" method="POST">
<fieldset>
<wall:input type="hidden" name="action" value="order" />';
// If we did not get the total number of pizzas to order,
// let the user select
if ($_REQUEST["numPizza"] == -1)
{
echo 'Pizzas to Order: <wall:select name="numPizza">';
for($i=1; $i<=9; $i++)
{
echo '<wall:option value="'.$i.'">'.$i.'</wall:option>';
}
echo '</wall:select><wall:br/>';
}
else
{
echo '<wall:input type="hidden" name="numPizza" 
value="'.$_REQUEST["numPizza"].'" />';
}
echo '<wall:h3>Select the pizza</wall:h3>';
// Select the pizza
$checked = 'checked="checked"';
foreach($products as $product)
{
// Show a product image based on the device size
echo '<wall:img src="assets/pizza_'.$product[
"id"].'_120x80.jpg" alt="'.$product["name"].'">
<wall:alternate_img src="assets/pizza_'.$product[
"id"].'_300x200.jpg" test="'.($wall->getCapa(
'resolution_width') >= 200).'" />
<wall:alternate_img nopicture="true" test="'.(
!$wall->getCapa('jpg')).'" />
</wall:img><wall:br />';
echo '<wall:input type="radio" name="pizza[
'.$currentPizza.']" value="'.$product["id"].'" '.$checked.'/>';
echo '<strong>'.$product["name"].' ($'.$product[
"price"].')</strong> - ';
echo $product["description"].'<wall:br/>';
$checked = '';
}
echo '<wall:input type="submit" class="button" name=
"option" value="Next" />
</fieldset></wall:form>';
?>
<p><wall:a href="?action=home">Home</wall:a> - 
<wall:caller tel="+18007687669">
+1-800-POTRNOW</wall:caller></p>
</wall:body>
</wall:html>

What are Those <wall:*> Tags?

All those <wall:*> tags are at the heart of adaptation. Wireless Abstraction Library (WALL) is an open-source tag library that transforms the WALL tags into WML, XHTML, or cHTML code. E.g. iMode devices use <br> tag and simply ignore <br />. WALL will ensure that cHTML devices get a <br> tag and XHTML devices get a <br /> tag. You can find a very good tutorial and extensive reference material on WALL from: http://wurfl.sourceforge.net/java/wall.php. You can download WALL and many other tools too from that site.

WALL4PHP—a PHP port of WALL is available from http://wall.laacz.lv/. That's what we are using for POTR.

Let's Make Sense of This Code!

What are the critical elements of this code? Most of it is very similar to standard XHTML MP. The biggest difference is that tags have a "wall:" prefix. Let us look at some important pieces:

• The wall_prepend.php file at the beginning loads the WALL class, detects the user's browser, and loads its capabilities. You can use the $wall object in your code later to check device capabilities etc.
• <wall:document> tells the WALL parser to start the document code. <wall:xmlpidtd /> will insert the XHTML/WML/CHTML prolog as required. This solves part of the headache in adaptation.
• The next few lines define the page title and meta tags. Code that is not in <wall:*> tags is sent to the browser as is.
• The heading tag will render as a bold text on a WML device. You can use many standard tags with WALL. Just prefix them with "wall:".
• We do not want to enable WML support in the form. It requires a few more changes in the document structure, and we don't want it to get complex for this example! If you want to support forms on WML devices, you can enable it in the <wall:form> tag.
• The img and alternate_img tags are a cool feature of WALL. You can specify the default image in the img tag, and then specify alternative images based on any condition you like. One of these images will be picked up at run time. WALL can even skip displaying the image all together if the nopicture test evaluates to true. In our code, we show a 120x100 pixels images by default, and show a larger image if the device resolution is more than 200 pixels. As the image is a JPG, we skip showing the image if the device cannot support JPG images. The alternate_img tag also supports showing some icons available natively on the phone. You can refer to the WALL reference for more on this.
• Adapting the phone call link is dead simple. Just use the <wall:caller> tag. Specify the number to call in the tel attribute, and you are done. You can also specify what to display if the phone does not support phone links in alt attribute.

Can I Use All XHTML Tags?

WALL supports many XHTML tags. It has some additional tags to ease menu display and invoke phone calls. You can use <wall:block> instead of code <p> or <div> tags because it will degrade well, and yet allow you to specify CSS class and id. WALL does not have tags for tables, though it can use tables to generate menus. Here's a list of WALL tags you can use:

a, alternate_img, b, block, body, br, caller, cell, cool_menu, cool_menu_css, document, font, form, h1, h2, h3, h4, h5, h6, head, hr, i, img, input, load_capabilities, marquee, menu, menu_css, option, select, title, wurfl_device_id, xmlpidtd.

Complete listings of the attributes available with each tag, and their meanings are available from: http://wurfl.sourceforge.net/java/refguide.php.

Complete listings of the attributes available with each tag, and their meanings are available from: http://wurfl.sourceforge.net/java/refguide.php.

Will This Work Well for WML?

WALL can generate WML. WML itself has limited capabilities so you will be restricted in the markup that you can use. You have to enclose content in <wall:block> tags and test rigorously to ensure full WML support. WML handles user input in a different way and we can't use radio buttons or checkboxes in forms. A workaround is to change radio buttons to a menu and pass values using the GET method. Another is to convert them to a select drop down. We are not building WML capability in POTR yet.

WALL is still useful for us as it can support cHTML devices and will automatically take care of XHTML implementation variations in different browsers. It can even generate some cool menus for us! Take a look at the following screenshot.