Beginning the Initial Design

Before you begin the actual human interface, it is important to set some boundaries on development and prepare some tools for the development and quality assurance process:

1. Select the primary set of devices that the application intends to support, especially because devices and platforms vary greatly in CPU size and data entry mechanisms. (PDAs use a stylus and touch-screen as an input mechanism, while WAP-compliant cell phones support telephony functions through WTA 1.2, etc.)
   
   
2. Specify a device manufacturer and, perhaps, even a model number. For example, you can narrow your support to Palm PDAs and Nokia cell phones as platforms. Further, you can specify that the application supports Palm VIIx and Nokia 7110 cell phones.
   
   
3. Obtain emulators for the selected devices. (Both the designers and the quality control engineers can do this.) The first step of unit testing and quality assurance testing is by using emulators. For our example, we can use Palm emulators that are available from the Palm Web site. Nokia also has a WAP development toolkit (you have to register first) that has a full-blown IDE for WAP, including an emulator, which allows support for multiple Nokia cell phones and PDAs. (See the Openwave site, formerly Phone.com, for more links to emulators.)

Designing the First Set of Interfaces

Once you've identified the devices to be supported by the application and you've gathered the emulators for those devices, it's time to start the design process. Because the user's first point of contact with a system is typically the user interface, it's critical to develop the UI with the user in mind. UI requirements are typically driven by the user's specifications of what is desired to be seen on the graphical UI or heard on the voice UI.

The user is not just an abstract entity. Be sure to take your clients' business requirements into account. For example, if IBM hands out a particular type of cell phone to its sales force, then the final UI design must be optimal for those particular phones if you're designing an application for IBM.

Subsequent to the development of your use cases, it is time to begin designing the first set of user interfaces. Let's use a ticket purchasing application as an example.

Identifying the Display and Input Elements

Your biggest concern in designing the application is the limited user interface. Clearly define what should be the displayed elements and the input elements for each step of each use case.

Figure 1. UML Diagram for Use Case 1 (Click to enlarge)

These two use cases in our example (as the subset of all use cases for the application) describe the basic functionality of logging in and viewing a main menu:

• Use Case 1, User Login: display a user name and password to the user (see Figure 1).
  
  • Data elements: User Name, Password
    
  • Action controls: Cancel, OK
  
  
• Use Case 2, Main Menu: display a main menu that allows the user to perform basic navigation to the other parts of the wireless application.
  • Data elements: Menu Items (include Search for Events, Purchase Tickets, Reserve Tickets, My Events Calendar, and Log Out)
    
  • Action controls: Cancel, OK, and Back
    
  • Navigation controls: Scrolling using Select Arrows

The three types of basic elements that support this simple functionality are as follows:

• Data elements display data or ask the user for some text input to the device
  
  
• Action controls are keys (or buttons on the screen to be stabbed, or else as might be applicable to the device) that cause navigation to a different display screen (in WAP, this is a WML card; in i-Mode, it's a different cHTML file)
  
  
• Navigation controls allow the user to scroll up and down and/or navigate within the same display screen (in WAP, this is a WML card; for i-Mode, it's a different cHTML file)

Creating XML Content Based on the Display and Input Elements

Because the content has been displayed in many different ways, the next step is to create all content in XML. (See Reza's article, "Next Generation Ethernet: The 'Fourth Tier' Is Born," about XML's role in the future of content.) To support a variety of devices, the best architecture is one that uses XSLT to transform raw XML content to formatted XML content usable by a given device based on the characteristics of the device. Listing 1 and Listing 2 show the raw content for Use Case 1 and Use Case 2, respectively. This XML code merely represents the data and some generalized representation of the behavior of the user interface. There is no client-specific information (browser or micro-browser related) about where a text element should be placed or how it should be presented.

Creating Formatted XML for the Supported Devices

Once the XML content has been developed, you need to create a mechanism that creates different types of content for different types of clients (cell phones, PDAs, browsers, micro-browsers, and so on). For example, you might need to create a variety of HTML pages for different browser types, or produce a series of WML pages for different devices. This translation from XML to other formats is done by creating an XSL for every variation of the transformed XML. However, it quickly becomes clear that the permutations of the XSL increase exponentially to support more and more devices. Dynamic generation of such content does not scale well.

Three possible solutions to rendering XML are discussed in the next sections:

1. Pregenerate all static content. ("Content Pregeneration")
   
   
2. Use scripting languages, such as JSP, to process the XML instead of using XSLT. ("Generating XML Using Server-Side Scripting")
   
   
3. Generalize some of the possible permutations of the user interface, per device family. This means that if we have 200 devices, we want to put them into 20 families. ("Selecting the Most Effective Set of Interfaces")
   

After the initial phase of the design, you have a set of possible permutations for the user interface. Listing 3 shows how two such permutations for Use Case 1 might look in WML.

Figure 2. Navigation Tree of Use Case 1 (Click to enlarge)

As you can see, although there is very limited input and only one screen here, we have already started down two different branches on the navigation tree (see Figure 2). This navigation tree will be very large for those applications supporting a large set of client types (device types and browsers). And they grow by factorials every time there is a new XML file (in our case a WML file).

Therefore, we need to deal with the problem of scaling in two fronts: development of XSL files and runtime content generation. Developing new XSLs for every device is impractical, as development cost is prohibitive. Also, as the number of XSLs grows and the rules on each XSL become more complicated, the XSLT compiler becomes slower.

Content Pregeneration

You may be wondering whether the content needs to be generated in real time, even if it is dynamic. One of the solutions to the problem of formatting XML is to "pregenerate" the transformed XML on a batch mode. Based on some event triggered by a change in the original XML content, or using some period, we can generate new content for each device based on the various XSLs. This option does solve the latency caused by the XSLT to generate transformed XML. However, selecting which transformed XML should be served to which device remains a problem, which we address next in "Selecting the Most Effective Set of Interfaces."

Generating XML Using Server-Side Scripting

To reduce the load on the XSLT when generating the XSL, it is possible to put the complex logic in a scripting language that wraps XML. This can be done with ASP, JSP, or XSP—depending on the application—before or after XSLT processing. This allows any complex logic involving selection of the rules for XSL templates to move into a server-side scripting language, such as JSP, thereby making the process more efficient.

Back to the Beginning

Selecting the Most Effective Interface

In this Article
Introduction	Selecting the Most Effective Interface
Beginning the Initial Design	How the Use Cases Add Up