Redefining user interfaces for the 21st century

Anatomy of an XML UI Description

Jack Hakim and Tom Spitzer

Most e-business services have some type of user interface (UI). with the web eliminating many barriers to competition, usability will increasingly drive the success or failure of such services. A development process that emphasizes the creation of quality UIs can have a significant impact on business results. At the same time, businesses need to deliver capabilities like order entry, trading, and management updates to a variety of platforms (for example, wireless devices, telephones, and appliances).

Ideally, these innovations would leverage the same development processes that are being developed to deliver high-quality interfaces to computing devices. In our work, we’ve been looking at the future of UI description languages to ensure that any design or development tools we build can integrate seamlessly with the tools that Web designers and developers will be using. In our April 28 column, we discussed some of the advantages of using an extensible markup language (XML)-based language for describing UIs, and we identified some of the capabilities that such a language should have. For example, it should support the separation of UI description from content, provide a way to specify how UI components should interact, and spell out the rules that define interaction behavior. It should also support rules to apportion responsibilities among different pages, forms, and dialogs. In addition, we require an abstraction level sufficient to adapt the UI to a particular device or set of user capabilities. With these features in mind, we’ll discuss three languages that have emerged over the past 18 months.

First XML-Based UI Language

Members of the Mozilla open-source community designed an XML-based UI language (XUL) to define the UI of the open-source Mozilla Web browser, which is slated to become the basis for the next-generation Netscape browser software. Incorporating references to several Internet standards—HTML 4.0, cascading style sheets (CSSs), resource description framework (RDF), and ECMAScript—XUL provides a model for integrating and extending multiple Web-programming languages to create a system capable of supporting a rich UI that is portable to multiple operating platforms. By leveraging standardized technologies, this initiative will facilitate the creation of cross-platform corporate or community-based applications that extend the functionality of the core Web browser. These applications will be relatively inexpensive to implement, because they can use services exposed within the core programming libraries but won’t require high degrees of programming skill to implement.

It is important to understand the distinction between describing a UI and implementing UI components. A XUL document describes a UI. Each XUL file defines a window and the widgets that populate the window. XUL has language constructs for all of the typical dialog controls, as well as for widgets such as toolbars, trees, progress bars, and menus. The XUL specifies the relative location of widgets, their interactions with each other, and optionally, some of their configuration parameters.

The image and behavior of each individual widget is defined in a code library that is part of Mozilla’s cross-platform toolkit (XPToolkit). Displaying a window and its widgets when somebody opens the window is the responsibility of the layout engine. When the application loads, it reads the XUL specification file for the application’s main window; the layout engine interprets the XUL and creates a set of widgets, applies the specified formatting, and establishes a set of event listeners required to respond to the events described in the XUL interface description.

Markup Language for Wireless Applications

Another organization providing significant innovation has been the Wireless Application Protocol (WAP) Forum. Early this year, WAP Forum members Nokia, Alcatel, and Motorola announced a series of new partnerships and product introductions that will expand and standardize the data management and communications capabilities of their cellular offerings. The services that these partnerships will offer include specialized portals designed for the mobile community, cellular Web access, direct access to financial services, retail commerce, and phone-based personal organizers that included networked diary, calendar, and contact-management applications. These announcements represent the first fruit of WAP’s work on developing the Wireless Application Environment as a standard platform for delivering interactive applications to narrow-band mobile devices such as cellular phones and pagers.

The WAP Forum has based its application development and data management specifications on the Web model, building on XML and ECMAScript. Wireless markup language (WML) is an XML-based markup language that describes both content and an interactive UI. WMLScript is based on core ECMAScript, and provides additional event and behavioral capabilities. WML emphasizes application semantics and relies on device developers to implement the components that provide the UI building blocks required to define an application.

WML addresses four aspects of UI specification:

•Presentation and layout of text and images, including a variety of formatting and layout commands.

•Organization of applications into coherent units. In WML parlance, a deck represents a coherent activity and is the unit of content transmission. Within a deck, cards specify discrete interactions, such as delivery of information on a single subject, solicitation of a user entry into a text field, or presentation of a choice menu. The user navigates the cards that form a deck by responding to the prompts each card contains.

•Creation of a navigation model that supports navigation both within and between decks, jumps to anchored links, and captures specified events that can trigger navigation or script execution.

•Articulation of a state model based on the declaration of string parameters that are replaced by values at run time. The WAP Forum’s special concern over constrained bandwidth resulted in this particular innovation over HTML-style architectures.

WML presupposes that the purpose of an application is to facilitate user activity. To provide a rich interaction palette, WML defines several elements that support event handling and navigation. These include elements that enable the application to update the value of a field or local variable as well as elements that specify a navigational result of an event, such as “go,” “prev,” and “refresh.” The “do” element provides a general mechanism for acting on the current card. Its UI representation depends on the implementation of the specific device. The application developer can only assume that the device will provide a unique widget with which the user can interact. In addition to actions specified within scripts, cards can generate events when they are entered, options generate an event when one is selected, and timers generate an event when they expire. Developers can associate actions with each of these events.

General-Purpose UI Markup Language

The people who designed UI Markup Language (UIML) had a different focus from those who developed XUL or WML. Rather than specifying a UI definition language for a specific target platform, they set out to create a language that developers could use to describe a UI one time and use on any platform, including XUL or WML. UIML views a UI as a set of interface elements with which the end user interacts; each interface element is distinctly a “part.” The parts may be arranged for different categories of end users and various families of devices. Each part has content that communicates some information to the end user, but the content is described separately from the part and assigned to it by a reference to the content descriptor. Optionally, parts can also receive information from the end user, using interface artifacts (for example, radio buttons or a selection list) provided by the underlying device.

UIML’s behavior element defines events for the UI and associates them with parts defined for the interface. The behavior element contains rules, each of which consists of a condition (typically the firing of an event) and a consequent action. An action may result in a change in a property value, or it may invoke a function or method in a scripting language or in an underlying application library. Simple rules are supported in a straightforward fashion. Business rules are often complex. Complex rules can be built by carefully creating a list of simple rules that interact, but it creates a dependency on your rule ordering, which can make rule maintenance difficult. Naming the complex rules would have been better than trying to circumvent the issue by using a very powerful template model.

Because the availability of specific UI widgets varies from device to device, the actual mapping between a part and an associated widget is performed by a style specification. The style mechanism provides a level of abstraction over the connection between parts and the controls on the target device that implement the parts. This abstraction level allows for the creation of multiple presentations to be defined for a single device.

Within a style specification, the rendering property plays a key role in enabling platform independence. This property maps a particular UIML part, event, or call to a widget, event, or method in a particular UI toolkit. Thus a developer can define generic (or functional) event names in UIML and map them to specific control-based events such as menu choices, button clicks, or voice commands in the target UI toolkit.

To complete the connection requires the articulation of a vocabulary of UI components specific to a particular application platform (which UIML refers to as a UI toolkit), with mappings from UIML-style properties to the components defined for the target UI toolkit. For instance, to target WML, you would reference a vocabulary consisting of tag names such as “card,” “select,” and “input.” In practice, you will define vocabularies externally for common UI toolkits and incorporate them into UIML specifications by reference to a URL. This architecture enables ongoing creation of mappings between parts defined in UIML documents and additional UI toolkits that may become available. The only shortcoming to this model is that it fails to provide an explicit mechanism for creating anything more complex than a simple one-to-one mapping from parts to components in the target toolkit.

What Have We Learned?

Examining these languages has been interesting because they all solve different problems and emphasize different sets of capabilities. We appreciate that Mozilla has blazed a trail toward decoupling UI development from core application development and providing a mechanism for facilitating extensions to what promises to become a widely adopted browser platform. WML impressed us with its emphasis on specifying the interactive aspects of an application and by demonstrating how a device-focused language can describe an interface without mapping to specific components in the target platform. Both of these languages have a strong focus on solving problems in a single application domain,and look like they will do so effectively. UIML is a very ambitious undertaking, and we were hoping that it would provide a depth to match its ambition. To an extent, it does that, especially in the areas of creating higher-order named abstractions. However, it lacks the ability to specify complex rules because it lacks a direct approach for handling complex mappings, such as many-to-one or one-to-many mappings, from developer-defined components to widgets available in the target platform. You can partially mitigate these issues by using their templates. UIML’s designers are aware of these issues and expect to address them as the specification evolves.

Jack Hakim (jhakim@ecwise.com) is the CEO and chief architect at EC Wise Inc. Lately, his work has focused on incorporating usability practices into the process of developing and enhancing Web-based services.

Tom Spitzer (tspitzer@ecwise.com) is vice president of product management at EC Wise, and was a long-time columnist for DBMS magazine.