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.
You can search for devices and compare them, and then come to a conclusion about features you want to use.
This is all good. But when you want to cater to wider mobile audience, you must consider adaptation. You don't want to fight with browser quirks and silly compatibility issues. You want to focus on delivering a good solution. Adaptation can help you there.
OK, So How do I Adapt?
You have three options to adapt:
- 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.
- 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.
- 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.
<wall:title>Pizza On The Run</wall:title>
<link href="assets/mobile.css" type="text/css" rel="stylesheet" />
echo '<wall:h2>Customize Your Pizza #'.$currentPizza.':</wall:h2>
<wall:form enable_wml="false" action="index.php" method="POST">
<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:input type="hidden" name="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[
'resolution_width') >= 200).'" />
<wall:alternate_img nopicture="true" test="'.(
echo '<wall:input type="radio" name="pizza[
'.$currentPizza.']" value="'.$product["id"].'" '.$checked.'/>';
echo '<strong>'.$product["name"].' ($'.$product[
"price"].')</strong> - ';
$checked = '';
echo '<wall:input type="submit" class="button" name=
"option" value="Next" />
<p><wall:a href="?action=home">Home</wall:a> -
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.
When you load the URL in your browser, WALL will do all the heavy liftingand show a mouth-watering pizza—a larger mouth-watering pizza if you have a large screen!
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.
Device Detection and Capabilities
We looked at what WALL can do and how easy it is to implement it. But how does it do that? WALL, and many other open-source (and commercial) tools use WURFL—Wireless Universal Resource File. The mDevInf tool that we saw earlier in this chapter is entirely based on WURFL. WURFL is a massive XML file, listing capabilities of all known mobile devices (almost!). It is actively maintainedand also derives information from UAProf—another standard for managingdevice capabilities.
At the heart of any device detection is the User Agent header sent by the browser. All device detection techniques check the User Agent ($_SERVER['HTTP_USER_AGENT'] variable for PHP) and look up their database to find the characteristics of that device.
Here are some of the things WURFL can tell you about a device:
- Screen size of the device
- Supported image, audio, video, ringtone, wallpaper, and screensaver formats
- Whether the device supports Unicode
- Is it a wireless device? What markup does it support?
- What XHTML MP/WML/cHTML features does it support? Does it work with tables? Can it work with standard HTML?
- Does it have a pointing device? Can it use CSS?
- Does it have Flash Lite/J2ME support? What features?
- Can images be used as links on this device? Can it display image and text on the same line?
- If this is an iMode phone, what region is it from? Japan? US? Europe?
- Does the device auto-expand a select drop down? Does it have inline input for text fields?
- What SMS/MMS features are supported?
The list goes on. But you can make some intelligent decisions in your application based on the device now. You can even conditionally print <wall> tags. E.g. show a download link only if the device has download support.
WURFL API is available in many programming languages, including Java, PHP, .Net, Ruby, and Python. You can download it from: http://wurfl.sourceforge.net/.
XML Processing can Bog Down My Server, is There Something Easier?
Yes! The WURFL XML fi le is above 4MB, and despite many structural optimizations, processing it on every request will certainly slow down your server. Many APIs provide caching to speed things up. But having this available in a database will be best. Tera-WURFL is a PHP package that uses MySQL to store WURFL data. It bundles WALL and an admin panel—making it the top choice for mobile web adaptation.
Setting up Tera WURFL involves downloading the latest package from http://www.tera-wurfl.com/, extracting the files and entering the database connection information in the configuration file. It will load up the device data to the database and can start serving WALL pages.
What About W3C's DIAL?
W3C 's DIAL (Device Independent Authoring Language) is a combination of XHTML 2, XForms, and DISelect. DIAL (http://www.w3.org/TR/dial/) was created to develop a language that will allow consistent delivery across devices and contexts. Though the language is new, it's getting a good response and is something to keep track of!
Other Useful Tools for Adaptation
Adapting a site for different devices goes beyond markup generation. Commercial tools such as Changing Worlds, Dynetic, and Volantis do a good comprehensive job in adaptation. Let us look at some more interesting open-source tools in this area.
Dynamically Resizing Images
If we can generate markup code dynamically, we might as well resize images dynamically! Maybe we can detect the screen size using WURFL and write logic that will resize a large image to fit the device screen. This will increase the load on the server a little bit as we resize the image, but we can save the image to disk for later usage and manage the additional load. This will cut down on the chore of resizing images for different resolutions every time we add one.
There are a few ready libraries that work with WURFL and can resize images and even change their format.
GAIA Image Transcoder (http://wurfl.sourceforge.net/utilities/gaia.php) is one such tool in Java. It even lets you define regions of interest to help in preview and place on the image.
PHP Image Rendering Library (http://wurfl.sourceforge.net/utilities/phpimagerendering.php) is another implementation in PHP.
Image Server (http://wurfl.sourceforge.net/utilities/imageserver.php) can work as a filter for your Java server, optimizing images without a trace of what's happening to the user!
Quick and Easy Way to Make Your Blog Mobile
If the job at hand is to make a mobile web version of a blog, you can do it in a matter of minutes! FeedBurner (http://www.feedburner.com) and Feed2Mobile (http://feed2mobile.kaywa.com/) take the RSS feed from your blog and show it in a mobile-friendly manner. Users just point to the new URL and they can access your mobile blog!
If you want full control, and want to set up something on your blog itself, head for Mobile Web Toolkit (http://www.beeweb.com). MWT's WordPress plug-in can get your blog mobile within 10 minutes. MWT allows you to customize what widgets show up to users of different browsers in a friendly AJAX editor. Plug-ins for other content management systems are on their way. MWT is a very interesting concept and advocates delivering a rich experience to mobile users, rather than restricting them with some lowest common denominator design.
On the other hand, many content management systems have now started supporting versions adapted to mobile devices. By the time this book goes to print, all major CMS will have mobile web support.
MyMobileWeb: Going the Semantic Way
MyMobileWeb (http://forge.morfeo-project.org/) is a Java-based open-source tool to build .mobi-compliant websites. It is a comprehensive framework that uses declarative XML to build the presentation layer (very similar to WALL) and an MVC architecture for handling various events.
MyMobileWeb is an ambitious project. The team is working on semantic mobile web, context awareness and mobile AJAX. Some of the features that may interest you:
- It does not do markup transcoding at run time, but generates device-specific pages at publish time. This gives better performance.
- The visual controls are defined through a declarative language and can interoperate with JSTL for dynamism. They are also rendered based on the context or rules that we can specify.
- The framework comes with ready visual controls for layouts, date control, RSS etc. It can even do binding of visual controls with data, and can generate a grid to display data and paginate.
- You get control over the visual aspects—CSS, alternatine content, hiding pages based on device, etc.
- It has a validation framework that can work on both client side and server side depending on scripting support at the client.
- Comes with an Eclipse plug-in!
HAWHAW: As Simple as a Laugh?
HAWHAW (http://www.hawhaw.de/) has a funny acronym, but is a great idea. It stands for HTML And WML Hybrid Adapted Webserver. HAWHAW is an open-source script written in PHP. You can create HAWHAW pages via PHP or XML. But the interesting thing about it is that it can even generate VoiceXML output. So not only can you build your standard and mobile website with it, you can even have people call in a number and do a complete interactive voice response system. You can even get some ideas from the HAWHAW implementation and build something of your own.
In this article, we learned when to adapt and how to adapt our mobile site to different devices. Specifically:We learned about the Lowest Common Denominator method, finding and comparing features of different mobile devices and deciding to adapt or not.We extended the Pizza On The Run application to adaptively display content using Wireless Abstraction Library.We saw how adaptation works in different browsers.We learned about WURFL and how it can be used to adapt based onbrowser capabilities.We reviewed tools that can aid in adaptation—Tera WURFL, MyMobileWeb, Mobile Web Toolkit, Image Server, GAIA Image Transcoder, and HAWHAW.One note of caution! Do not over-constrain the content. Users expect the same kind of experience on the mobile that they have on the Web. As mobile web developers, we must strive to bridge the gap, not widen it.