 |
|
   |
|
|
 |
By Andrea Trasattii
To take advantage of WURFL it is important to understand the logic behind the capabilities and how to use them. In this article, we will take a look at a first set of capabilities. Capabilities started from a small set originally targeted at WML 1.x browsing, and slowly grew as the needs changed. Nowadays WURFL lists capabilities for almost any aspect of a mobile device, ranging from the markups to the MMS to J2ME and more. We are going to try to describe the capabilities so that it will help you use them in your projects. While there are several capability groups, this month we're going to dig into the capabilities in the browsing environment. WURFL Browsing Capabilities From the beginning, WURFL was designed for simple and easy implementation by software and this was achieved trying to always list Boolean values for each capability. Many capabilities could have been grouped and readability would have been much better, but use inside an application would have been more complex. It is much easier to verify if a certain variable is true rather than evaluate the value of a string. Also, because WURFL was born as a simple XML file, and there were no libraries available, the aim was to make it really easy to develop in any language. The wide number of libraries available today demonstrates how everyone picks his or her own preferred language. WURFL lists information about many aspects of a mobile device, but browsing is still the main focus. If you are going to develop a site that is supposed to support more than one markup, the first thing you will want to know is a list of the supported ones. The WURFL capabilities surrounding markup languages are:
As a rule of thumb, each capability has the name of the markup (wml) and the version (1.0) separated with underscores. Markup languages that are related to HTML such as compact HTML or iHTML (for i-mode devices) have the "html_wi_" prefix that reminds you that it's an "HTML for wireless devices". We also list "html_web" 3.2 and 4.0 for browsers that also support these markups. "multipart_support" will tell you if you can generate a multipart MIME package and send it to browsers in the mobile device. This is useful if you want to have a single HTTP transaction and send the page and the images all together. (There are a number of articles in Jack's Hacks on the Openwave Developer Site about how to build multipart responses.) Device Compatibility Now what if you support more than one markup language in your site, and you want to provide the best one to the device? Many devices support more than one markup, especially the new devices supporting xHTML or the imode devices sold in Europe (which support both iHTML, WML and the most recent also iXHTML). To make everyone's life easier the capability "preferred_markup" was introduced. As an exception to the rule, this capability is a string and tells you the name of the markup that is known to be rendered best on the device. This is a subjective interpretation and might change from person to person, but in general we have seen that some devices work very badly with some markups and so we try to set the preferred markup to the one that looks the best. You are free to apply your own preferences with a "patch file" or by simply ignoring of this capability. Consider it a kind suggestion. The "preferred_markup" capability is the first step to start developing a service that supports many different devices and markups. The next step is to analyze the single markup and use the tags that make the user experience better. When devices supporting WML first came to market, they were promoted as bringing the web to the cellular phones. We all know that it was a bit oversold, and unfortunately many features were supposed to be there but in fact were not. This is why the capability group "wml_ui" was created, and also why it lists so many capabilities. Most of these capabilities are defined for families of devices. You will rarely find these capabilities defined for a single device, but you will find them in "virtual devices" that group families of devices, such as Openwave version 5, or Nokia series 20 and so on. Table Support and Images Tables are not always supported, for this reason there's an ad hoc capability called "table_support". It's a Boolean capability and tells you if a device (decently) supports tables. It is important to know that most WML devices have a small screen and you will hardly see a table as expected because of the width (WML devices show about 10-15 characters on a row). While many devices will accept markup that defines a table, they will simply choose to ignore the tags and generate a single column. It's not very useful?. The WML markup language does not dictate the presentation of any given element, and as a result manufacturers each made their own decisions in the hopes of making the user experience better. This sometimes breaks the intentions of developers' code and results in sites that are optimally usable on one device and completely useless on another. An example is the automatic new line after an image introduced by some browsers. This means that the image can't have text next to it. There is a capability to handle this situation: "wml_can_display_images_and_text_on_same_line". Another capability in the image placement category is the ability to use an image as a link, identified by "image_as_link_support". Images were really a problem early on and some manufacturers thought that having the image always centered would have looked better, so we also have the "wml_displays_image_in_center." Unfortunately when the image is centered by default you will not be able to align it to any other position. Building Menus Building menus of navigation links is one of the core use cases on the mobile web. The "list of links" is seen on just about every site anywhere in the world. However, even doing this optimally became complicated due to some lack of specificity in the WML specifications. On some devices, the <select> element can be used to efficiently and automatically generate a list of numbered links with associated access keys (e.g. the '2' key on the keypad selects the 2nd link). To accomplish the same functionality on other devices, the developer must explicitly declare the link, the associated access key and the number to be displayed on the screen. To identify capabilities about lists and links we have, for example, "numbered_menus" that tells you if, in case of a list of links, the browser associates a key (1,2,3) to each link to avoid scrolling and clicking. If you want to build a menu and let the user pick from a list of a options you will want to check "menu_with_select_element_recommended" and "menu_with_list_of_links_recommended" so that you can build the menu for the best usability. What if you wanted to use a little icon next to each link? You should check the "icons_on_menu_items_support". When using lists of links you should not forget the capability that will tell you if you should add a break after each link or if the new line is automatic. This is defined in "break_list_of_links_with_br_elements_recommended" since some devices will automatically insert a line break after a link, while others will not. Imagine a service to read your email from your WAP device. You will want to ask for the login and password. Of course, after entering the data, every user will want to click on the "submit" link. WML devices have the ability to configure the soft keys for special actions, but not all devices supported this feature. To know if your device supports it, check "softkey_support" and to go back to the previous page, check if you should assign the action to one of the soft keys or if the device has a key automatically assigned (built_in_back_button_support). Advanced Features A couple advanced features are also defined in WURFL. You might want to give more relevance to a word or a sentence in your WML page. You can do this using "proportional_font", thus making part of the text bigger (or smaller). To save bandwidth but still offer a nice look you might want to use the built-in icons in Openwave browsers. Check the "opwv_wml_extensions_support" (also check the WML 1.3 Reference Guide for a list of the the icons). The same philosophy was later applied for imode devices and xHTML. We have two new groups called "xhtml_ui" and "chtml_ui". The imode devices are much more standardized so the list of capabilities is very short. While tables are not a requirement (and are not suggested by DoCoMo), some devices support them. You can verify this using "chtml_table_support"; the name says it all. The only thing you should really mind is emoji. Emoji are little icons stored in the device's memory. Just like the Openwave icons, you may show an emoji using a keyword. For some strange reason emoji codes are different in Japan, Europe, Asia and the Americas. For this reason we have a capability called "imode_region" that can be "none" if emoji are not supported or any of the follwing: ja, eu,us and as. Also make sure to check if emoji is supported with the capability "emoji". Most of the capabilities for xHTML refer to the support of styles or how you are allowed to use colors. For example, we have two nice capabilities that will suggest two good background colors (to make lists more readable, for example) that will render well on devices. Most devices will not let you change the color of links for readability reasons. Using a good background color is important. Use "xhtml_readable_background_color1" and "xhtml_readable_background_color2" (default value is #FFFFFF). Also make sure that the device actually supports background colors. We have the "xhtml_honors_bgcolor" for this. A Few Final Tips A pair of capabilities that use in about every site I ever developed is:
For this reason we have "xhtml_preferred_mime_type", which is a suggestion of a content type that is supposed to be rendered the right way. If you want to be strict, provide the proper content type for the markup you chose. "wml_make_phone_call_string", "xhtml_make_phone_call_string" and "chtml_make_phone_call_string" are strings (not Boolean) that will suggest you the string to use to make the phone start a call. If none is supported the keyword "none" is used here. If you have questions for Andrea, you can contact him via our feedback form |