Last month we showed how WALL plain menus work. Plain menus are usable and load fast, but they lack one feature: they are not very fancy to look at. We have been hearing about WAP for seven years and those long lists of hyperlinks are no longer very exciting (in fact, some will claim they have never been).
Color graphical devices have been around for some time now. Yet their power has been kept on a leash because of the need to make things work on legacy devices through "common denominator" mark-up.
"Give to Caesar what belongs to Caesar..."
It's time to give praise where praise is due. Back in 2002, Vodafone launched an ambitious wireless portal: Vodafone Live! Vodalive (as some familiarly call it) has raised the bar in terms of mobile site design and awareness, setting the standard by which all mobile portals are judged.
Figure 1: Vodafone Live!
The graphically rich top menus from Vodalive do not load as fast as plain menus (Vodafone does use Multipart behind the scenes to optimize, though - see "References" below), but they really look cool. Of course, creating a cool menu for a certain well-defined high-end color device is one thing. Creating it for an arbitrary device is quite another.
Vodalive is a multi-million dollar project and the technology it relies on is way out of reach for anyone except carriers and a handful of top international content providers. So, is the poor developer doomed to build frugal boring menus for the rest of their life?
WALL to the Rescue
Not so. WALL gives you a powerful abstraction called 'cool menu'. Figure 2 shows how a cool menu will appear on the device of our dreams:
Figure 2: Cool Menu On High-End Device
Large screen, colors and decent support for HTML tables allow the creation of those nice menus a-la Vodalive. But what about devices that have all of the same features but whose screen is not nearly as large? Not a problem for WALL. The matrix will simply be re-arranged on two columns (see Figure 3):
Figure 3: Cool Menu On High-End Device With Small Screen
We can still be happy. Things get trickier when a device has nice colors, but poor (or missing) table support. This is the case for some CHTML and XHTML devices. WALL can figure this out and degrade very gracefully to something like Figure 4 (list format), which is still a great deal.
Figure 4: Cool Menu On Device With Poor (Or Missing) Table Support
Did we forget some devices? Yes, we did. We forgot legacy WAP black&white devices. With those devices, we couldn't do much more than a list of hyperlinks when it came to menus. Well, no miracles here. WALL does not provide anything more, but nothing less either (see Figure 5):
Figure 5: Cool Menu Degrade To A Simple Hyperlink Menu On Legacy WAP Devices
The Code
It's now time to see how this is achieved. As an example, I took inspiration from the Openwave Developer Network site. I resized the graphics and I created a wireless version that looked as cool as possible, but still could work on every device:
Before we delve into the code, a little confession. While the code above achieves what I have described, it is not a coolmenu in its purest form. I used a tiny bit of JSTL programming to dynamically decide the number of columns and to make sure that GIF pictures are only returned to devices that can handle them. Theoretically, the logic for dynamically deciding the number of columns could be hard-wired into the coolmenus themselves.
In practice, this would backfire: coolmenus would be way less flexible for practical use, since it would be impossible for WALL to figure out the text length and the icon dimensions. On the other hand, the application programmer does have this information and can decide what the right number of columns is, even as a function of one or more WURFL capabilities, if they wish. If no number of columns is specified, WALL's default is 2.
- lines 2 and 3 enable the use of JSTL. JSTL will be the subject of a future tutorial. For the purposes of this article, suffice to say that JSTL gives me a way to define some kind of scripting variables and initialize them based on WURFL values.
- lines 7 through 10 set the JSTL 'gridsize' variable, to be used to define the number of columns in the coolmenu. There should be two colors, unless the resolution width (as set in the WURFL) is 160 pixels or more.
- line 11 defines CSS to be used by XHTML devices to correctly position the elements in the menu. The CSS depends on the number of columns, so 'gridsize' has to be passed as a parameter (default is '2').
- line 14 shows how you can use 'text' and 'bgcolor' too. XHTML devices will get the color info in the form of CSS, CHTML gets the attributes by the same name and WML devices get nothing as usual.
- lines 16 and 20 enclose the picture in a block. This is necessary to make sure that XHTML and WML are valid (or the page will break on some devices). 'block','form','menu' and cool_menu' are on the same level: i.e. they cannot be nested and all content must be contained in one of them.
- lines 17, 18 and 19 show a powerful WALL tag in action: 'img'. This is an old friend on steroids. It lets us multi-serve pictures depending on several conditions. In this particular case, this is as simple as 'show the Openwave Logo, unless the device does not support GIFs'. If I was a bit less lazy, I would build a WBMP logo and make WBMP-only devices happy too, but I'm in a hurry to go out and play.
- line 22: our coolmenu starts. 3 colors for devices with 160 pix screen (or larger). 2 columns for other table-capable devices. The WURFL capabilities that influence the bahavior of this tag are:
preferred_markup: WML, XHTML or WML? tables are never attempted for WML. Handling all the complexity of WML tables is not worth given the limited numbers of legacy devices on which it could make sense.
xhtml_table_support: this is a bit of a misnomer. What the capability really represents is "does this device have decent HTML table support?" Some devices support tables in theory, but in practice it's better to avoid using them for the purpose of coolmenus. After all, presenting the menu in 'list form' is still pretty good.
chtml_table_support: same as xhtml_table_support but for CHTML devices.
- lines 23 and 28 define the bundary of a cool menu cell. These tags may turn into 'tr's and 'td's automatically, depending on the WURFL capabilities I just mentioned.
- lines 24 through 26 are identical to the ones I described for the logo. A touch of JSTL in the condition lets you ask the WURFL if the device supports GIFs or not. Using 'wall:img' (rather than a simple 'img') is necessary for a couple of reasons. Not only is a slightly different syntax required by imode devices (no trailing slash to preserve well-formedness), but 'img' is also context sensitive. When used inside a cool menu, it will generate a 'br' tag in the right place to adjust layout.
- line 27 is a hyperlink. No tricks here. You could use a plain non-WALL anchor, unless you want to add 'accesskey' and be protected against devices that do not support it.
The rest of the code just define the cells in the same exact way, so nothing else is left to be explained. Let's look at how this page gets rendered by a bunch of different devices.
Figure 6: Cool Menu On A Bunch Of Different Devices (click for larger picture)
I normally use the good Openwave Mobile SDK for my WAP testing. This time, though, I want to show how coolmenus display on devices that do not run the Openwave Mobile Browser. Rather than launching a whole bunch of SDKs, I used a cool tool that's been around in a long time: The SmartPhone Emulator by Yospace.
The Yospace guys do a great job of analyzing device behavior and getting as close as possible to faithful device emulation. Be warned that their tool is not free, but their evaluation version is. You may want to give it a try. Figure 6 shows how our coolmenu will render on devices with wildly different features: from high-end UMTS devices, through devices with small screen, no table support and all the way down to WAP 1.X oldies.
The only thing left to show is the actual mark-up produced for the different devices:
Things to observe: WML from 1999. Conclusions
Every self-respecting wireless portal cannot stick to WML for their top pages, but multi-serving is expensive. WALL introduced coolmenus to give you an alternative that's good, cheap and fast. Plain menus (shown in the previous issue) should also be used for quick and effective navigation past the top pages. References WALL Tutorial: Menus Leveraging Servlet Filters to Serve Multipart Content Openwave Mobile SDK Yospace
