 |
|
   |
|
|
 |
While the ambition of WML and XHTML MP was to standardize the mark-up for wireless development, things are not quite as smooth in reality. If you want your applications to be more than simply a proof-of-concept, you will need to optimize usability for end users and make maximum use of the capabilities of each device your application is supposed to run on. This turns out to be a non-simple problem to solve, since differences in device capabilities and in WAP browsers make it impossible for a single application to exploit the advanced features of one device without breaking the application for other devices.
As an aside, this problem also exists for plain web development, but the HTML subset understood by all web browsers is expressive enough for most uses. One solution to the problem is to build multiple applications, one for each device or family of devices. While the business logic would be the same for all the application, this approach is certainly expensive to develop and to maintain over the long term. Another solution, which is what we will discuss in this appendix, is to exploit utilities or fully-fledged frameworks to let an application dynamically deliver different mark-up to different devices. Before we describe the tools, we need to understand the nature of the difference among devices. Navigation vs. Resourcification Wireless devices can differ in two ways. Similar devices may ship with browsers from different manufacturers. The browsers support different interaction models that force you to tweak the mark-up for the different browsers. For example, some browsers support softkeys and numbered menus, while other browsers do not. This is what we refer to as differences in 'navigation'. The other way to differ is to support different resolutions, have different display sizes, support extra graphical formats, different number of colors and so on. Devices with browsers from the same manufacturer may have widely different feature and capabilities. The browser is the same, but you may want to adjust your graphics, the size of your menus and other things for some of the devices you need to support. In a way, you need a large resource file or something to figure out the capabilities of each device programmatically and serve content accordingly. This is what we call 'resourcification'. This classification has some interesting aspects: Navigation deals with issues caused by differences in how mark-ups are displayed. Resourcification doesn't. All WAP applications should try to manage navigation issues. Only between 10% and 30% of applications need to deal with resourcification. These definitions will be useful later. Building Multiple Applications One obvious way to optimize applications for families of devices is to build multiple applications. Understandably enough, this approach is not particularly popular among developers. As the system evolves and new features are introduced, the burden of having to maintain all of those services may become unwieldy. One valid reason to multi-serve WAP application may be introduced by XHTML MP itself. While those new color WAP 2.0 devices hit the market, most of the phones out there only support WAP 1.X and WML. For this reason, the easiest way to support all the phones, while exploiting the advanced capabilities of the coolest WAP 2 devices is to create two versions of the same application: one based on WML and one based on XHTML. Of course, one may want to optimize to a much finer level of granularity also inside of each of the two mark-ups in order to take advantage of the capabilities of each device. The OUI and WURFL projects presented here might prove a useful tool for your needs. WURFL (The Wireless Universal Resource FiLe) URL:wurfl.sourceforge.net [0-9] With reference to the Navigation/Resourcification dichotomy, WURFL is all about the latter. If, totally hypothetically, for a single moment, we were to ignore development costs, building multiple applications would be the best solution by far for end users. One could make sure that each single aspect of an application matched the device capabilities. Some of the aspects that could be optimized are, for example:
Some developers are aware of the problem. In an attempt to squeeze the last drop of usability out of the different devices, they look at the user agent and fork their code here and there locally to optimize for some devices. This approach produces good results in the very beginning, but has a few rather serious shortcomings:
WURFL is about modeling the capabilities of all known devices (firmware subversions included). The WURFL capability database is an XML file. This makes the WURFL pretty portable. The size of the file is much smaller than you might fear. Less than 300 Kb. While much of the project value is the database itself, the WURFL project also provides a bunch of nice open source software libraries for popular platforms (particularly Java and PHP at the time of this writing, but also Perl and ASP). The software lets you programmatically (and efficiently) query the WURFL and take local decisions based on the capability of the device making the HTTP request. While the user-agent string is actually used behind the scenes to match the device with its capabilities, programmers do not need to think about that anymore. They can think in terms of device capabilities. For example, "if the current device has a built-in or pluggable digital camera, then offer a link to the page with the operator-sponsored competition ". Should a new device with a digital camera become available after the application is launched, you just need to update the WURFL (either manually or by downloading a newer version of the WURFL website) and the application will perform optimally for those devices too. The following example should clarify how things work. Imagine you have an operator WAP portal that links to all of the cool wireless services offered by that carrier. Available services include WAP Push, Download Fun, MMS, Java games and so on. Operators (particularly those in GSM regions) are supposed to manage tens or hundreds of different devices. Of course, those devices have different capabilities. Offering MMS or J2ME services to the owner of, say, a Nokia 7110 phone does not make much sense. Yet, building several versions of the portal for different devices is highly unpractical too. This is where WURFL comes handy. With WURFL you can build a single version of the portal that renders differently depending on the capabilities of the device (the example shows the WURFL JSP tag-library in action):
As different devices request this page, the actual page will change dynamically depending on the capabilities of the device:
How accurate is the WURFL? Because of the open-source nature of the project, there are two major implications on the accuracy of the information contained in the WURFL: There is no guarantee that the data in the WURFL is accurate. As soon as some WURFL developer realizes that the information in the database is inaccurate for some devices, they can (in addition to fixing their own version right away) tell the maintainer of the WURFL about their findings. This ensures that the future versions of the WURFL are more and more accurate. Of course, it is up to you to decide if WURFL is good enough for your requirements. Wurfl Website: wurfl.sourceforge.net WURFL: wurfl.sourceforge.net/wurfl.xml OUI (Open Usability Interface) Url: oui.sourceforge.net Open Usability Interface (OUI) is a server-side programming library that allows developers to employ a uniform application user interface (UI) model that abstracts from the underlying platform implementation details. In practice, developers code to the best of the capabilities that each WAP 1.X mobile device/network offers. Because of WAP 2.0 mandatory support for WML 1.X, OUI applies to WAP 2 devices too. OUI insures the best possible user experience is delivered by adapting the application UI for the particular device requesting the service. In particular, OUI optimizes for Openwave and Nokia browsers. With regard to the Navigation/Resourcification definition, we can say that OUI is all about Navigation, i.e. making sure that end-users can move around and operate your application in the most efficient and intuitive way possible. Openwave has contributed OUI to the open source developer community through SourceForge.net under a Mozilla Public License (MPL 1.1). One example is worth one thousand words Showing an example of OUI in action is probably more instructive than talking about it abstractedly. Explaining how menus are created and rendered with OUI is probably the clearest example. In a way, menus are the most obvious OUI abstraction. The Nokia WML model forces developers to use lists of hyperlinks. Openwave phones are better served by the <select>/<option> WML construct, because it provides users with numbered lists and numeric key accelerators. In addition, the Openwave Mobile Browser is the only widely deployed WAP browser that allows in-line icons on menus. This last feature is typically left unexploited in Europe for the sake of interoperability across different phones. OUI menus make it possible for you to write applications with advanced features, and the library makes sure that your applications degrade gracefully on devices that do not fully support those features.
 The sample code is rendered like this for the Nokia browser Openwave phones, though, have a different way to render menus: numbered lists.  Openwave Textual Browser  Openwave GUI Browser (note nice in-line icons) Of course, OUI is much more than menus. You can refer to this URL for more info: oui.sourceforge.net/overview.php Commercial Products for Multi-serving Multi-serving has such paramount importance that several companies are offering commercial frameworks for multi-serving and other tools connected to development and testing of wireless applications for different devices. We will mention their names and URLs here. This list is by no means meant to be exhaustive: Arkdom: www.arkdom.com/arkdom/index.html Volantis: www.volantis.com/index.jsp Argogroup: www.argogroup.com/index.shtml XHTML-MP Style Guide Chapters XHTML-MP Style Guide Index 1. History of XHTML Mobile Profile 2. XHTML MP in practice 3. Menus in XHTML Mobile profile 1.0 4. Text-flow 5. Forms: Collecting User Data 6. Images and Objects 7. Testing Your Applications Appendix A Appendix B |
