Solving Device Diversity

This article originally appeared on BEA's dev2dev

developer portal. Visit dev2dev for

more articles on this topic.

by Garret Molloy

This is the fourth article in a set of six explaining how to use the MobileAware technologies to develop web applications for mobile devices.

Article 1 explained how to "mobilize" an existing web application using BEA WebLogic Workshop and the MobileAware palette. Article 2 introduced the Mobilized BEA Portal. Article 3 showed how to provide a more pleasing presentation while working within the limitations of a handheld device's form factor.

This article will explain how to design your multi-channel web application from the start to overcome device diversity issues. The important point to gain from this article is that developing a multi-channel web application

with MobileAware uses the same skills and methodology for developing HTML with minimum extra effort to achieve delivery to multi-channel.

MobileAware's mobility solutions, including sample applications, portals, and documentation, can be downloaded from MobileAware's developer web site.

The Device Diversity Headache

First, let's briefly examine the device diversity problem. Delivery to multiple devices means overcoming differences in device capabilities and requirements, including:

• Markup Language - HTML, WML, XHTML MP, CHTML
• Media Capabilities - images, flash, audio
• Memory Restrictions - size of content a device can receive
• Screen Size - a device's available display area

We could simplify the range of devices we have to deliver to by organizing broadly similar devices into device classes, for example, PC Browsers, PDA, and Mobile Phones. Creating content for these three classes would be quite manageable. However, the Mobile Phones device class will encompass devices that require a range of markup languages: WML 1.x, WML 2.x, XHTML MP, CHTML, and HTML 3.2. So extra device classes have to be created to cater to the different markup languages. In addition, content has to be created for each device class we have identified.

To complicate the device classification problem further, even within these many device classes, each device will have differences in attributes such as display capabilities. These differences affect our content delivery, such as which media type to deliver, gif or jpeg, and how to tailor the content for the device's screen size or memory size.

Figure 1. The device diversity headache

There are several solutions to the problems associated with delivering content to multiple devices. Any solution must address the different device classes as described above.

One method is to have multiple sources of content, one for each of the different device classes we have defined. Another method is to use XSL stylesheets. This method requires us to define the initial content in an XML format

and use a separate stylesheet to describe the transformation for each of the different device classes.

Both of these methods require multiple files, one for each device class. Then, as individual devices have slightly different requirements and capabilities, we are required to modify our files to cater to these differences. This requires adding more intelligence in the method of transformation and/or adding extra sources of content, which in turn adds a significant maintenance overhead and headache!

Regardless of the transformation method, if we do not want to build separate content files for each device, we need a datastore containing all the device capability information. On top of this, we need to correctly identify the device requesting the content in the first place.

The MobileAware Solution

MobileAware eliminates the device diversity headache for the author by adding a few simple steps to the preexisting content development process. Instead of having to learn new tools and languages, the author uses familiar tools such as BEA WebLogic Workshop and familiar markup languages such as HTML and JSP.

MobileAware provides a comprehensive device database containing more than 500 devices and device classes. This store contains information about each of the different device capabilities and their unique content requirements. MobileAware's mobility platform, Mobile Interaction Server (MIS), uses this repository of information both to identify the user's device (or nearest matching class) and to intelligently tailor the content.

Standards-Based Authoring

MobileAware uses HTML/XHTML as the basis for defining the presentation of content. This is the W3C standard for defining web content and is familiar to many web developers.

MIS has an intelligent transformation engine that automatically transforms the HTML/XHTML for each of the different device classes into the required markup language, such as XHTML MP, HTML 3.2, CHTML, and WML. This transformation engine also performs device tailoring, modifying the output to address the slight modifications required by different devices in a device class (images capability, table support, and so on).

These capabilities mean that MIS can work with a single source of content as the basis for delivery to all these diverse device channels.

MIS is deployed as a J2EE servlet filter in your J2EE web application, coexisting in the same server tier. See Figure 2.

Figure 2. MobileAware's MIS architecture

Laying Foundations

Where to start? Authoring with MIS extends the existing process so similar to how you might design any piece of web content, you start by considering the layout of a page you are going to deliver. First, you decide on the layout of your navigation menus, header/banner images, and main content locations. Then, you define the look and feel, preferred colors, and necessary images.

The next step is to create the HTML framework in which to position and display the components of this design.

MobileAware extends these steps by asking the developer/designer to consider the channels they are developing for. Our guide is that there are three main device classes: PC, PDA, and Mobile Phones. These three device classes are the only channels the developer needs to design for. Within MIS, these device classes are described as "FullBrowser," "PDA," and "MenuDriven," respectively.

We will take the example of the "MenuDriven" device class. Consider this class an abstract grouping of all mobile phones, encompassing all the different markup languages required by these myriad devices. This simplifies the potential headache of designing for the different markup languages and the subtly different device requirements, leaving it to MIS to handle all these complexities.

The mobilization process is categorized into two main stages: grouping and presenting content. Step 1 is to logically group the sections of the page. Step 2 is to define how to present this content for the device classes.

During the normal web design process, the designer has already considered the broad grouping of content to be delivered to the PC. MobileAware extends this thinking to consider the page in terms of which groups (or indeed, subgroups) of content we want presented on each device class.

In some cases the application may be only for a subset of the PC, PDA, and MenuDriven device classes, for example, a mobile phone-only site. In these instances, it is only necessary to think of this device class, and this further simplifies the design role.

Figure 3. Designing for the three device classes

In Figure 3, we can see a design view of a PC page, broken into its logical groups. This is followed by the design view of how these groups are displayed on the mobile devices. As stated earlier, as a designer we are only concerned with three device classes and not with the differences in markup languages, image capabilities, and so on.

After the design phase, the page is marked up using HTML/XHTML. MobileAware has extended XHTML to include extra mobility tags. At the very simplest, you only need to add three mobility tags to make your HTML/XHTML page transform and be delivered to any handheld device.

Pagination is the splitting of large pages into multiple smaller pages suitable for delivery to devices with limited content capacity.

In addition to this initial transformation, extra tags can be added to fine tune the content for a specific device class or to handle images, for example. For additional information about mobilizing content (adding mobility tags to HTML/XHTML content), see Article 1, which explains how to add these mobility tags using BEA WebLogic Workshop and the MobileAware palette. Article 3 looks in more detail at mobilizing pages for handheld devices and enhancing the end-user experience.

MIS will automatically convert HTML content to the correct markup language for the requesting device as well as perform automatic intelligent pagination if required.

Mobilization Recap

To recap, the original page is written in HTML/XHTML following the normal authoring process. This is the content that is delivered to PC browsers. Then, we define the groups. Next, we add some presentation information for how we want the groups delivered to MenuDriven devices as described above and also to PDAs in a similar manner. MIS will transform the author-selected content into the correct markup language for the requesting device.

The web developer only needs to focus on the content and does not need to worry about the device diversity headache! MIS will automatically present the best possible content to the device. For example, if a device supports color images, these will be sent to the device. If the device supports only black and white images, however, then a WBMP (black and white wireless bitmap) will be sent. The following listing shows a typical marked up page. The additional markup does not have an impact on the netui:tags and uses the existing HTML that developers are familiar with. The resultant content from MIS will be HTML, WML, and so on, depending on the device's markup requirement.

<%@ taglib uri="netui-tags-html.tld" prefix="netui"%>
<%@ taglib uri="mmJSPtaglib" prefix="mm"%>


  
    
  
  
   
  
  
     



        This is Today's News brought to you by
         MobileAware and BEA!
        

        
        



        


Address:

            
            


Name:

            
            



        


        
        
        



    
   
 

Figure 3 also shows how some presentation ideas for pagination have been considered. For the PDA device we have considerable flexibility in how we present the content to the user. In the illustration we have decided to display only one of three groups on a page at a time, giving the user a more manageable subset of the information to work with.

MIS will display one of these groups in full on the page and automatically add a navigation menu allowing access to the pages containing the other groups. Header, Menu, and Footer groups are displayed on all pages. So from the one original PC page we now have a set of three PDA pages, with a navigation menu to link between them, all created automatically.

Looking at the MenuDriven design, the author has decided that the header and footer groups will be displayed on the main page with Group A, Group B, and Group C displayed as a menu of links. Clicking one of these links will bring the user to the complete content of the selected group. Automatic breadcrumb-like navigation links are added to direct the

user back to the original page.

As mentioned earlier, if the content is too large for the memory capacity of the device, the content is split over various "decks," with automatic navigation links directing the user through the complete content. See Figure 4.

Figure 4. Automatically paginated content for a device with a limited decksize

As you can see, Deck 1 splits just before hitting the maximum page content size for this WML device. This pagination will be performed for any mobile device, WML, XHTML MP, or i-Mode, where the device supports a limited amount of content and the content supplied is too large for that available space. Once again, the author does not have to be aware of these limitations or the markup language that is required.

Where desired, the author is free to indicate within the content the best (or worst) locations for any automatic pagination to occur.

Multi-Channel Output

The next example uses a similar design phase to that shown in Figure 3.

Figure 5. Output for the device class FullBrowser or PC

Figure 5 shows the PC output, demonstrating the complete content being delivered to the PC device class.

For the PDA, the author has initially designed a layout displaying all the groups on the pages; see Figure 6. Of course, with the design options discussed previously, the author could have designed the page to display only one group at a time with a repeating header, footer, and menu; see Figure 7. The styling of this navigation menu is discussed further in Article 3.

Figure 6. PDA output

Figure 7. PDA paginated output

Figure 8 and Figure 9 show the output to two different MenuDriven devices, each with different capabilities. The author has only had to design for the generic MenuDriven device class. MIS handles the transformation for displaying the content, ensuring the correct image types are delivered and the correct markup language is used. Therefore, the web developer need not be concerned about what markup language is used for Figure 8 (XHTML MP) or Figure 9 (WML) or that the second device does not support color images. The content rendered is always the best from the content they have authored. In addition, the developer doesn't need to worry about the amount of content being sent to the device as this will also be handled automatically by MIS.

Figure 8. MenuDriven output (XHTML MP)

Figure 9. MenuDriven output (WML 1.1)

Summary

Using MobileAware's technology, the web developer can let MIS handle the transformation and the complexity of device requirements and can therefore design pages at a higher level without worrying about these issues. The overhead of using the additional tags in the HTML page is negligible; the web developer has a single source of content for delivery to all devices and is using a familiar technology, HTML. The result is a simple but powerful mechanism for creating multi-channel applications using BEA WebLogic Workshop.

Resources

• An evaluation copy of the MobileAware Mobility Extension for BEA WebLogic Workshop
• MobileAware Mobility Extension for BEA WebLogic Workshop 8.1: Mobilizing the Sample Project (1.2 MB, requires Adobe Acrobat Reader)
• Mobilizing a Sample Workshop Application - The first article in this series
• The Multi-Channel Portal - The second article in this series
• Chase Away the Handheld Web Browsing Blues - The third article in this series

Garret Molloy is a Solution Architect at MobileAware. He has over 4 years experience of architecting and implementing multi channel delivery plaform solutions, and works directly with customers in all aspects of system architecture and system development delivering complex integration solutions and providing mobility strategies for mobile/telco operators.

This article is copyright 2005 and is reprinted with the written

permission of dev2dev