OUI Overview

by Luca Passani, luca.passani@openwave.com

This document provides information about the main OUI abstractions, along with some examples using the WML tag library (and in one case, the XHTML tag library). It should help you start experimenting with OUI.

The abstractions will be illustrated through some simple JSP tag-lib examples and the pictures that show how such examples actually render on different classes of devices.

Important Note: the code examples in this document use the JSP tag-libs. Anyway, the same results are possible on any of the supported platforms (Servlets, ASP/COM, PHP and .Net)

Menus

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.
This looks like (please note those nice in-line icons):

Openwave Textual Browser

Openwave GUI Browser

Please observe that in-line icons are not just a fancy add-on: they improve end-users’ interactive experience. For example, you could use them on the very first page of a calendar application to visualize that an appointment is taking place within 16 hours. Which end-user would resist the temptation to hit your application at least once per day?

Forms and Primary Paths

Forms are a bunch of widgets that collect user input. Nokia phones, Openwave textual-phones and Openwave GUI phones have different ways to support forms (ref. Elective forms vs. Wizards on the Openwave Usability Guidelines).

The Form object helps. Just put your input elements and picker object there. You can regard a picker object as a <select> construct with the only purpose of picking an item out of a list.

If you know WML, the above should make sense: a form with three form elements. The only part that may be unclear is the primary path. According to the Openwave usability guidelines, a primary path is the activity that most users are likely to perform when accessing a certain card. On the Openwave browser, primary paths should be associated with the main softkey (aka Accept key) through the <do type=”accept”> WML construct. On browsers without soft key support, primary paths are often more usable if implemented with a hyperlink. As a consequence, there is no generic WML best practice that guarantees satisfactory results for all phones.

OUI fixes this by letting a developer specify the intended main activity for each card. This abstraction has been conveniently called “primary_path”.

Note: a primary path can contain either an URL or a more complex task (as in the example above). On top of that, developers can specify two labels, a long and a short one. The short one is used for soft keys; the long one is used for hyperlinks.

Please observe how primary paths are rendered on different classes of devices:

XHTML Tag-lib

While this document won’t dig too deep into the details of the XHTML tag-lib, here is how the from in the previous example is implemented with XHTML:

Of course, the actual WAP devices will still get WML, but this doesn’t prevent you from playing around with a technology which we are bound to encounter sooner or later.

Secondary Paths and Side Paths

We have mentioned primary paths. You should always code your apps so that there is only one primary path. Of course, in many cases you will need users to have multiple choices readily available. Secondary paths serve this purpose. In general, a secondary path is an activity that many users perform now.

You can code as many secondary path as you want in each card. Even none. If you are coding more than 4 or 5 secondary paths for a single card, though, you should start wondering if the structure of your applications is the best possible: clogging the interface of a mobile applications is a very bad idea.

Here is an example of use of a secondary path:

And here is the result for the different browsers:

TaskMenus

The new Openwave GUI browser has a new graphical widget that increases usability, the so called task menu. A task menu is a bit like the windows Start button in the bottom left corner of the screen. Increased usability is given by the fact that the end user does not loose the context of the card they are operating, since the content of the card is only partially covered by the menu. A task menu is an excellent way to group together a bunch of secondary paths in case you have many. When you use a task menu control, you will get the advanced behaviour for the GUI browser. Textual browser will show the menu in a separate card. Access to that card is implemented as a secondary path for the card with the menu.

Note: OUI does not let you implement a secondary path and a task menu for the same card. Here is an example of task menu usage:

And here is the result for the different browsers:

ComboMenus

Another nice feature of the new GUI browser is the possibility to put multiple widgets in the same card. One commonly used configuration is a Menu followed by another bit of WML code or user-input constructs. Unfortunately, the WML code to achieve this effect on the GUI browser does not degrade gracefully on text-based browser.

OUI offers a solution in the form of a ComboMenu object. A ComboMenu requires two components:

• A Menu
• An Appendix, i.e. some UI controls (or just a bit of WML code) conveniently wrapped into an object called Appendix.

When rendering, GUI browsers will receive the fully-fledged composite GUI (see picture). Textual browsers will receive a card with a menu and a card with the controls in the appendix. A new menu item is conveniently added as the lat one of the menu to point to the new card for the textual phone (see picture).

This example:

The Openwave textual browsers are given a new card. The last menu item points to it.

Nokia browsers support elective forms, so they do not need a new card.

Publishing Large Chunks of Text: BodyPager

Maximum deck size in Europe is about 1.3 Kylobytes. Unfortunately, determining the amount of text that ends up in our decks is not always simple. OUI offers a solution though the BodyPager object. In the presence of large amounts of text, the BodyPager will split the content in conveniently sized pages and make sure that navigation across different pages is supported automatically. To give you an example, here is an example out of Alice’s Adventures in Wonderland (Lewis Caroll).

Also observe the possibility to add header and footer information (<bp_header> and <bp_footer> tags). Such info will be displayed at the top and bottom of each automatically generated page:

Here is how different browser visualise the BodyPager.

Nokia: The lack of soft key support on Nokia devices forces users to scroll to the bottom of the page to find navigation.

It should be noted that Openwave browsers introduce the optimisation of pre-loading the first page whenever the gateway allows this extensions to pass through.

Making Phone Calls: Caller (and rendering directives)

The lack of WTAI support in many phones has prevented developers from deploying this useful WAP feature in the past. The OUI library offers an abstraction called Caller. A Caller will resolve into a WTAI call for browser that support it. Other browsers will receive a new card containing the telephone number on a page of its own. This allows users of non-WTAI compliant devices to start a phone call through proprietary mechanisms (notably, the ‘use-number’ feature on Nokia phones).

Another OUI feature that you’ll find handy are rendering directives. You can think of a directive like an option to a compiler. Basically they are used to tell OUI to divert from its default behaviour in some specific cases. In the code above, you see an example of the ‘enforce_title’ directive. Some telephones honor the value of the ‘title’ attribute on each card. Some don’t. There are cases when you want the title to be displayed anyway. Putting the title in the body of the card is not the best solution, since you will see the title repeated on devices that support the title. The rendering directive delegates the problem to OUI. In practice, when using the rendering directive, each browser will display the title once (and only once).

WML Tables on all browsers: Table

Some devices do not properly support WML tables. This has prevented developers from using this valuable feature. OUI supports tables. WML tables are produced for devices that support the feature. Other devices are presented the same information using a convenient lay-out that does not require the feature tags. Example:

Old Nokia devices do not support tables.

Reducing Perceived Latency: Mobile-Originated Prefetch

Mobile-originated prefetch is basically the capability some browsers have to pre-load one or more decks, under the assumption that users are likely to navigate there soon anyway. This optimisation goes a long way into improving the application latency as perceived by the end user. Unfortunately, some devices (and gateways) break on this extension. OUI offers a solution by making sure that this feature is automatically discarded for device/gateway combinations that would break on it.

There are no significative screendumps to explain the concept further. A video might so the job ;)

Application–level Optimization: Conditional Tags

As you see, OUI performs a lot of optimisation behind the scenes. We refer to this feature as core usability support. If you want to use OUI to optimise usability even more, you can do it at the application level. OUI offers great support for this through so-called conditional tags: <oui:if>,<oui:condition> and <oui:condition_list>. Let’s look at the example:

this was the simple case. A more complex use of the conditional tags is:

Conditions can be depend on:

• gateway vendor name
• user agent string
• class of device
• version of the browser

Raw mode: when all else fails

Ideally, OUI will contain all you need to build good wireless applications. There may be cases, though, were a developer needs to hack bits of mark-up in ways that are not natively supported by the library. In all of those cases, it is possible to recur to the so-called raw mode. For example:

Only for UPText, this time: