XML FOR UI There are many approaches to using XML to describe a user interface (UI). In fact, XML grew out of HTML--the popular Web-oriented UI. With XML, there are a handful of simple techniques that you can use to create useful and usable user interfaces. INPUT Handling input within the user interface is far from a trivial matter. Like layout and formatting, it's wise to approach the user input with an abstraction layer if you are developing for multiple devices. Beyond the abstraction though, there are some additional issues. TYPES OF INPUT There are various types of user input. One type is a multiple-choice selection. You know the kind--"Select A for this, Select B for that". Then, there's the multiselect multiple choice, which allows the user to select multiple items from a multiple-choice selection. There is also text input and validated input. Some of the user input is related to layout as well. For example, a selection of radio buttons and a drop-down combo box perform the same function. However, the radio buttons take up more space on a visual interface than the combo box. SEGMENTED ARCHITECTURE Good application architecture minimizes the number of steps a user needs to go through to achieve a desired goal. It will also keep the business logic and the user interface logic segmented. In other words, it's a bad idea to call a database directly from the user interface because it tightly couples one to the other and limits future enhancements. You can, however, use the business logic to create the abstract XML that will become the specific layout language for your application's device audience. RELY ON THE APPLICATION Many business applications have the ability not only to push and pull data via APIs but also to provide the type and range of allowed values. If you knew these at the time you rendered your user interface, you could eliminate the need to display an error message when the user entered invalid information. Additionally, you don't want to re-create the validation in the user interface because you will then have to change the allowed values or ranges in two places when you need to update them. If the business application can provide this information, then it makes sense to encode it in the abstract XML. In other words, if you are going to specify that a particular field is a multiple-choice box with six choices, then you might also want to specify that in the current state only four of the choices are valid. For example, imagine a scenario with a trouble ticket system. There is a field called status that has valid values of new, open, closed, resolved, and canceled. When the ticket is first created, it can only have a new status. Once opened, you cannot set the status back to new. A canceled ticket cannot be set to open or resolved. All of these options are part of the business logic and not the user interface. By providing these options in the abstract XML, you can then render an appropriate user interface that will eliminate potential user error. EXAMPLE Let's look at an example that applies this principle. We'll keep things simple by showing a ticket case number, a status code, and a description of the problem. We also want the end user to be able to modify the status code to a new value. Our basic ticket looks like this: 1239940 2 BGP service failed on Cisco 3600 router at IP 10.0.0.2 We want to render this ticket for viewing in a Web browser. Here's what the ticket might look like using the above XML and rendered with a basic layout: Ticket #1239940
Case number: 1239940
Status: 2
Description: BGP service failed on Cisco 3600 router at IP 10.0.0.2
There are two shortcomings to this HTML both of which relate to the status field. First, a status code of 2 doesn't mean much to the end user. Second, we want the end user to be able to update the status code to a new, valid value. Assuming our business application can provide this data, our new XML might look like this: 1239940 Status 2 2 Open 3 Close 4 Canceled BGP service failed on Cisco 3600 router at IP 10.0.0.2 Now, we can take this XML and render it in HTML to become the following: Ticket #1239940
Case number: 1239940
Status:
Description: BGP service failed on Cisco 3600 router at IP 10.0.0.2
---------------------------------------- Brian Schaffner is a senior consultant for Fujitsu Consulting. He provides architecture, design, and development support for Fujitsu's Telcom360 group. ----------------------------------------