Last month, we started an Introduction to WALL; we demonstrated how a WALL JSP page can render simple text on any device. In this article, we will look at the main mechanism that operates a WAP or iMode service: menus.
The only pre-requisite before we delve into menus are hyperlinks (anchor 'a' tag). Hyperlinks (otherwise known as links) are the same across any known mark-up. For this reason, WALL hyperlinks will look familiar to everyone:
<wall:a href="/home.jsp">Home</wall:a>
Most developers expect this WALL tag to turn into a hyperlink when rendering into WML, XHTML or CHTML. This is what happens in most cases, but not all. In some cases, hyperlinks are better rendered in other ways. To find out what I mean, read on.
Menus
"A menu is a graphical user interface element which allows the user to select one among several, presumably related, choices..." from WikiPedia, the free encyclopedia
Minimizing user data input is a priority in a wireless application. A good wireless programmer should be creative and use menus. There are many scenarios in web programming where a text field would make sense, but where mobile devices are better served with a set of choices, that is a menu.
If you have built WAP applications before, you know that menus are not easy to implement in a cross-browser way. This is particularly true if you also want to support keyboard accelerators—that is, program your menus so that hitting the "3" key will activate the third choice in your menu.
This is where WALL comes handy. Not only are WALL menus guaranteed to work on any device, but they will also show up with keyboard accelerators, if you wish and the device allows it. Two Kinds of Menus
WALL offers two kinds of menus:
Plain menus ('wall:menu' tag) work on all devices, load fast and their usability is optimized.
Cool menus ('wall:cool_menu' tag) are graphically rich menus, look really good on color WAP devices and still work on older devices.
As we stated in Part 1, the first priority in WALL is to create a universal mark-up. This is the basic notion that led to the creation of menus. Plain menus are quick to render and reliable. This is what you should use when you want users to have a rapid, consistent way to operate choices in your application.
Do developers want more? Of course they do.
Vodafone and their good "Vodafone Live!" portal have made this totally clear. In the rest of the article we will look at plain menus. Cool menus will be covered in Part 3 next month. Plain Menus
I chose the first page of a wireless newspaper site as an example:
1 Last Hour
2 First Page
3 Soccer
4 Weather
5 Sign in
6 Register
7 Conditions
8 Contacts
First, a few notes about usability:
Select Top Content: wireless sites are not websites. A newspaper web site typically contains tons of info: new articles, old articles, banners, thematic areas and other stuff. Having all of this does not make sense for a wireless service. The device screen is just too small to accommodate so much information. And even if we did, people would not get there anyway.
Select Content That Makes Sense for a Mobile User: for a newspaper, this translates to giving users access to the latest news. In addition, you should make the most popular choices be the first ones in your menus.
Keyboard Accelerators: recurring users will figure out that, for example, the 2-4-3 key sequence will bring them to the economy page. This is an extra reason for them to come back to the service even when they just have a couple of minutes to kill.
Assuming you are comfortable designing for usability, the problems begin when you want your menus to work the same on all devices. That is when WALL comes handy:
Line 6 is important. In spite of the fact that plain menus are built for solidity, this does not mean that advanced WAP 2.0 devices cannot use a bit of coloring and formatting, if one wishes. This is achieved by using CSS for XHTML devices. 'wall:menu_css' will give you those CSS without need to care about details.
Line 10 is where the fun begins. We are telling WALL that we want a menu. 'autonumber' instructs WALL to create keyboard accelerators for us. 'colorize' is a directive to make the menu as fanciful as possible (compatibly with device capabilities). If you compare this example to the one in part 1, you'll see that the 'menu' tag replaces the 'block' tag in the 'hello.jsp' example. This is because blocks, menus, forms and cool menus are supposed to be at the same level, i.e. you can't nest one inside the other or your app may fail unexpectedly for certain devices which interpret XHTML MP syntactic rules very strictly.
Lines 11 to 18 are the menu items. Each item looks like a hyperlink, and it will render as a hyperlink in many cases. Don't be fooled though. WALL 'overloads' the 'wall:a' tag in order to perform some magic behind the scenes: add keyboard accelerator and improve usability. We'll see this in more details shortly.
Let's see what mark-up different classes of devices get when accessing this page. Not all WMLs are created equal.
WALL supports three mark-ups, XHTML MP, CHTML and WML. This does not prevent it from doing some 'intra-markup' optimization for usability's sake. Menus are a great example of this, since each and every mark-up is further optimized according to device capabilities other than 'preferred_markup'.
Let's start with WML. A Nokia 7110 (very first 7110 device I came across in 1999) would be better served with a menu like this:
There is no keyboard accelerator for the 7110. The reason is simple. The 7110 does not support them and any attempt to provide them would break your application. WALL does the only sensible thing and sends the only kind of menu that works on that device.
The relevant WURFL capability for access keys is 'access_key_support' ('wml_ui' group), but it's not the only one. WALL also makes some checks on the gateway, since some gateways won't consider the presence of the 'accesskey' attribute legal and will abort the HTTP response.
There is another optimization happening behind the scenes. The 7110 and other legacy Nokia WML devices require the use of the 'template' tag to correctly enable backward navigation. This is important, or users would be 'trapped' and unable to move back. WALL makes sure that the 'template' tag is there for devices that require that. The relevant WURFL capability is 'built_in_back_button_support' ('wml_ui' group).
Figure 1: Menu.jsp Rendered on a Nokia 7110
At this point, you may be wondering how different WML can get from this. Listing 3 shows how the page will be rendered on the UP.Browser 4, which powers a lot of legacy Siemens, Panasonic, Motorola, Alcatel and other devices.
The 'template' tag is not necessary for UP.Browser 4 (compare to WML for 7110) since devices running UP.Browser 4 always have a physical button mapped to 'back' at all times.
Even more important than that, though, is that menu items are implemented in a totally different way, i.e. using the 'select/option/onpick' tags and attribute. This construct produces way more usable menus for UP.Browser 4, because of the introduction of shortcuts and a nicer visual layout. For example, highlighted items scroll horizontally when selected, in case the display is not big enough to show it in its entirety. This is a feature of the UP.Browser called 'Times Square mode'.
Please note how, in this case, hyperlinks are automagically turned into something different behind the scenes. The 'wall:a' tag is overloaded. It can recognize when it's being used as a menu item and turn itself into something totally different for sake of usability.
Figure 2: Menu.jsp Rendered on a Siemens SL45 (Up.Browser 4)
WALL "beginners" do not need to understand all these details to get started. It's all handled automatically. The relevant capability here is 'menu_with_select_element_recommended'. It should be clear by now that you can do a great deal of application configuration simply by adding and modifying WURFL devices and capabilities (possibly through the patch file).
All of these capabilities are listed in the WALL documentation (see references). XHTML MP, Two Flavors
When XHTML-MP was introduced, OMA participants realized that there was a chance that different manufacturer would come up with different ways to create an optimal menu.
Just to give you an idea, some where suggesting that a number, say 4, would be automatically added when 'accesskey="4"' was used. Others would leave the creation of the number to the developer. This would have meant, in practice, that we would see WAP services with no numbers and services with two numbers, depending on which developer website the service developer had learned XHTML on.
Fortunately, they agreed in the last minute that the following code (Listing 4) was supposed to work the same on all devices with the accesskey number displayed once and only once.
--------------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC
"-//WAPFORUM//DTD XHTML Mobile 1.0//EN"
"http://www.wapforum.org/DTD/xhtml-mobile10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Daily News</title>
</head>require that the creation of the
<body>
<ol>
<li><a accesskey="1" href="http://url1" title="Latest">Last Hour</a></li>
<li><a accesskey="2" href="http://url1" title="First">First Page</a></li>
<li><a accesskey="3" href="http://url1" title="Soccer">Soccer</a></li>
<li><a accesskey="4" href="http://url1" title="Weather">Weather</a></li>
<li><a accesskey="5" href="http://url1" title="Sign in">Sign in</a></li>
<li><a accesskey="6" href="http://url1" title="Register">Register</a></li>
<li><a accesskey="7" href="http://url1" title="Conditions">Conditions</a></li>
<li><a accesskey="8" href="http://url1" title="Contacts">Contacts</a></li>
</ol>
</body>
</html>
--------------------------------------------------------------------
Listing 4: Standard XHTML-MP Menu
On all XHTML-MP device this will work nicely (and if it doesn't, I would love
to hear about it). This is how the page will look on a SonyEricsson T610 device:
Figure 3: Menu.jsp Rendered on a SonyEricsson T610 Device
Some developers will not have a problem with this rendering, while others will be disappointed. XHTML-MP was introduced concurrently with the arrival of XHTML devices on the market. Much of the hype around XHTML was based on pictures of colorful (and cheerful) screenshots. Admittedly, though, the screenshot in figure 3 does not look very exciting.
Its only property is that it works ok across all WAP 2.0 devices. This is not little, but WALL lets us legitimately aspire for more for those devices that support CSS and tables decently: colorize="true" (Listing 1, line 10) is telling WALL to do what it can to make the menu look fancy on devices that are good enough (relevant WURFL capabilities: 'xhtml_supports_table_for_layout' and 'xhtml_supports_css_cell_table_coloring'). The XHTML code generated for those devices, while still XHTML MP, is slightly more sophisticated than the one in listing 4:
Figure 4: Menu.jsp Rendered on a Sharp GX 10 Device I-Mode (CHTML)
Last but not least, WALL will also generate CHTML for iMode devices. While CHTML tends to be better behaved than XHTML when it comes to rendering on different devices, it can also use a little help from WURFL. CHTML needs 'emoji' to generate the number glyphs for menu items. Unfortunately, the set of emojis for European and Japanese i-Mode devices are different. WALL fixes this by looking at the WURFL 'imode_region' property and generating the right emoji entity for you and your users.
Figure 5: Menu.jsp Rendered on an i-Mode Device. Conclusions
That's it for this month. We have seen how WALL plain menus can be used to deliver optimal user experience on very different devices. Next month, we will look at a different kind of menus, ones that may require more clicking, but are way cooler to view. References Introducing WALL: the Wireless Abstraction Library (Part 1)
