On the advantages of, and needed XML-standards changes behind, flexible UI definition languages

The Why and How of UI Specification

Jack Hakim & Tom Spitzer

Articles in this column so far have steadily focused on platforms for e-business. This issue, we’d like to change gears by discussing some ongoing innovations in the design and delivery of user interfaces (UIs) on intelligent devices. We use the term “delivery” intentionally; some of the UIs that we will examine are not displays in the traditional sense, but may consist of a series of voice- and even gesture-based interactions.

We focus in detail on efforts underway to develop systems where the UI is defined by one of several nonprocedural interface definition languages. All the languages we discuss here are based on extensible markup language (XML). By letting you define sets of domain-specific tags, XML facilitates the creation of new vocabularies that describe domain-specific content and context, organized into hierarchical information structures. As everybody knows by now, XML has become the official meta-language of the Internet and is now accepted as the standard for languages that represent all manner of structured documents and information. As we review the business challenges and advantages of using some of the XML derivatives, you will get some insight into why there is a proliferation of languages being created with XML.

XML is considered a meta-language because you can use it to define languages that are relevant to various application domains. You can add validation to a language expressed in XML by specifying a document type definition (DTD). The DTD lets you define what are the valid language concepts, their allowable types, structures, and default values for the domain language specified in XML.

Think of the presentation portion of a UI as a content tree that describes relationships between the components that populate a window, page, or another presentation context appropriate for some device besides a computer. This characterization conforms to the internal organizing structure for XML, its document object model (DOM). The DOM’s key feature is that it was designed to create a common API for accessing and manipulating XML and HTML in browsers, editors, and other programming tools. Although the analogy between UI and DOM provides some insight into the efficacy of XML for defining an interface specification, it does not address the issue of behavior. Expressing in a declarative language, such as HTML or XML, the rich level of interactivity normally expressible in a procedural language is challenging. For now, assume you can ultimately overcome this weakness by adding event and rules capabilities to the presentation language or to an accompanying process definition language.

Defining UIs with a specification-based (declarative) meta-language provides several advantages over using a procedural one. Declarative languages are usually easier to learn and have had great success both in the paper world and on the Web (HTML, for example). Specification languages tend to be text based, making them both human- and machine-readable, as well as easy to manipulate by virtually any programming language.

We are all familiar with procedural models, such as C++ or Java, that use a binary encoding of the structure and content of the UI that gets executed in a runtime environment on a target platform. In contrast, HTML describes application content and its UI to a user agent (such as a Web browser) that progressively interprets the markup instructions and renders the UI accordingly. XML was designed to allow complete separation of content from structure. This model is desirable because it lets you evolutionarily develop the form, content, and business logic independently of each other.

Separation of responsibilities allows different people (perhaps even specialists in each field) to take responsibility for each area, and apply best practices in the area without having to make significant accommodations for the actions of their counterparts. Of course, the degree to which different languages achieve these benefits depends on their specific implementations and extensions!

Why Are We Here?

By now you might be wondering why a discussion of UI definition languages found its way into the E-Business Developer column. We think it’s an important topic for organizations building e-business services, because it’s common to present these services with some type of UI. We believe that the UI’s quality is critical to the success of such services. To the extent that a UI definition language can support a development process that emphasizes quality, it can significantly affect business results.

Decoupling structure from content also allows us to build more dynamic presentations based on user groups and business rules, increasing customer satisfaction and retention. Also crucial to success is how quickly companies can adapt their offerings for alternative platforms. Because this is the year for the explosive growth of noncomputing devices gaining Internet access, it has become essential to develop a strategy for delivering e-business services to such devices. The extent to which this kind of strategy exploits existing infrastructure and applications will directly influence time-to-market. Using an interface specification language that separates out deployment responsibilities can provide you a foundation for quickly repurposing applications to wireless devices, telephones, and appliances, and can leverage the same development processes that are being developed to deliver high-quality interfaces to computing devices.

From another perspective, the likelihood that your services are already using XML-based representations of transaction data, process specifications, or information content is rapidly increasing. Building e-business services with interfaces defined in XML-based languages provides another level of architectural consistency to such services. Because XML-based languages are extensible, incorporating content from one such language into documents created primarily with another is a straightforward task. As a result, using an XML-based interface description language to present XML-based data is a natural and simple operation. Taking this approach to development advantageously uses the expertise of the information architects who are responsible for adapting and extending XML-based languages and the programmers who are already working with XML parsers and APIs.

In 1998, we started developing our own XML-based languages that describe UIs and support our company’s portfolio of design and usability optimization services. About six months ago, we started analyzing other UI definition language development efforts at various levels of consideration by standards bodies. Our primary motivation was a desire to avoid continuing the development and maintenance of our XML-based UI definition language; we thought we should be able to adopt one that was in development elsewhere. Doing so would enhance our interoperability story and let us focus development resources on our core service package.

Lay of the Land

What we have found has been an interesting mix of application- or platform-specific languages on the one hand, alongside a couple of attempts to create a general-purpose approach to the problem of UI definition on the other. To impart a sense of these efforts’ breadth, we will take you on a high-altitude flyover.

Starting with domain-focused UI description initiatives, the Mozilla community has developed an “extensible UI language” (XUL) to specify the structure and contents of the Mozilla UI. (Mozilla is an Netscape-supported, open-source effort that is developing a Web client expected to be in at least beta form under the Netscape brand name by the time you read this.)

Also with a relatively narrow focus, Bluestone Software Inc.’s XwingML lets developers using Java’s Swing UI controls define the UI with an XML-based tag language.

We know of a few initiatives under way to support definition of platform-specific UIs. The Wireless Application Protocol (WAP) Forum has approved a specification for wireless markup language, which developers can use to specify the UIs and content of applications targeted to narrowband devices, such as cell phones and pagers. The industry consortium working on moving voice and phone applications to the Internet, the VoiceXML Forum, released a preliminary specification in August 1999 for a language that describes voice interfaces.

The World Wide Web Consortium (W3C) has been working on a variety of related fronts, taking a somewhat broader perspective. Of course, the W3C is the organization that sponsored XML’s development. The W3C’s extensible stylesheet language (XSL) Working Group released a working draft of XSL in January 2000, following release of the recommended XSL transformations (XSLT) standard in October 1999. XML, XSL, and XSLT provide much of the foundation work required for the development of effective UI definition languages.

Of potentially greater significance was the January 2000 approval of the extensible HTML (XHTML) specification and the “road map” that the W3C’s HTML working group has adopted. It certainly appears that the W3C intends for XHTML to be capable of defining UIs for a wide range of devices. Over time, W3C will modularize XHTML, resulting the language’s decomposition into sets of related elements that can be combined and extended by document authors, document type architects, other XML standards specifications, and application and product designers. We plan to perform an in-depth analysis of how well a modular XHTML would meet our objectives for a general-purpose UI definition language.

Another initiative with what we consider a high-level perspective spawned the release of version 2.0 of UI markup language (UIML). Its developers are involved with a company called Universal Interface Technologies in Blacksburg, Va., and were previously associated with the computer science department at Virginia Tech University. These folks have developed a language that allows developers to describe a UI in a relatively abstract manner, which facilitates mapping common UI components to implementations specific to different devices or user groups.

In the coming weeks we need to make a decision regarding the future of our own interface description languages. We’ll therefore need to establish some decision criteria from which we can analyze promising alternatives. The crucial issues for us are deciding how to map the needed interactivity between components and incorporating business rules in a declarative extension of XML. It’s clear that any extension must continue to support the separation of UI description from content as we discussed earlier. In addition, we are going to be seriously concerned about the language’s support for describing interfaces that we can deliver to multiple devices and population groups. We will need to consider whether using a transformation mechanism such as XSLT to map to platform-specific definition languages looks like a viable strategy.

Finally, the strategy we adopt needs to address event management and task flow in a rich and flexible manner. Fortunately, a number of groups are devoting a substantial amount of mental energy to the problem, which improves our chances of finding a satisfactory solution.

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.

RESOURCES Bluestone: www.bluestone.com Mozilla: www.mozilla.org UIML: www.uiml.org VoiceXML: Forum voicexmlforum.org W3C: www.w3c.org WAP Forum: www.wapforum.org