Selecting the Most Effective Set of Interfaces

While the two methods described above reduce the load on the XSL generator at runtime, the number of different user interfaces and the development of various XSLs becomes problematic as the number of devices to be supported by the application increase. Therefore, we need to limit the number of possible XSLs by generalizing the user interfaces available to the devices—in other words, assign one set of user interfaces to a group of devices instead of to a single device.

To do this, we need a method to compare and evaluate the various user interfaces. In a way, what we are attempting to do is compress the information content of the user interface, both in data display and interaction and in intra-display navigation. This compression—as with any other compression method—can be lossy or lossless. Because loss is introduced in "generalizations," and because we will be generalizing groups of devices into categories or families of devices, our content compression of the user interface will be lossy. (What this means is that any differentiating information about these devices is lost—thrown out, basically—by the compression.) Sidebar An Encoding Technique: Huffman Coding One of the easiest forms of data compression, Huffman Coding compression is a simple method of assigning numbers according to the possibility of an occurrence of each element in a system.

For example, take a system where all the content is composed of letters {A, B, C, D}. Assume that the possibility of the occurrence of each of these letters is, respectively, {0.1, 0.5, 0.3, 0.2}. Using zeroes and ones, the most compressed representation of the data would be {01, 0, 1, 10} and/or {10, 0, 1, 01}, assuming variable-length bytes. (We will not discuss how the bytes are constructed here, because compression for variable-length content is complicated.) Shortest Huffman Coding lengths are, in order: B, C, D, A and/or B, C, A, D (depending on negative or positive logic). Therefore, we first need to quantify the set that describes our content, and then we need to compress it. [End of sidebar]

Using the Huffman Coding method, we introduce a set of independent (orthogonal) variables that describe how the machine and the user communicate. Next we introduce a grading system that can be used to determine the degree of loss in compressing the information exchanged between the user and the device. Our grading system allows us to quantify the user-friendliness of each set of user interfaces. Note that our grading system uses variables {P₁, P₂, ..., P_n} so that we can dynamically change the grading system based on the family of devices. For example, we might assign the grades to be {1, 2, 0, 5, ..., 10} for cell phones and {2, 5, 9, 10, ..., 15} for PDAs.

As previously mentioned ("Identifying Display and Input Elements"), we are concerned with two client interaction problems: display/input of data and navigation. These problems encapsulate the variables in our set. The set we have defined here is only a subset of a superset that might include other user interactions with the device, such as voice, touch movements, and so on.

Here's how we define our subset for user interaction content components.

Scrolling
Scrolling up and down (or sideways if the device allows) is cumbersome. Scrolling more than one page, in addition to the viewable page (for a total of two pages), causes even more trouble for the user. For our grading system, we will assign P₁ points every time the user has to scroll and P₂ points every time the user has to scroll more than one page. Therefore, if the screen has four lines and there are eight lines of content, we add P₁ points to the point total of that screen. If the screen has nine lines of content, we add P₁+P₂ points to the point total of that screen.

Text Entry
There are various types of text that the user can input into a device. Here's how we rate the different types of text entry:

• Repeating Keys (P₃ , P₄): Certain text, such as letters "s" and "k," require multiple pushes from the same button. This is cumbersome because you must be speedy in pushing the same button multiple times to get the desired letter (for example, three quick pushes on the number 5 produce the letter "l"). We will assign a grade of P₃ any time a multiple push character is required and a multiplier of P₄ as a coefficient for the number of times that button must be pushed (twice, three times, and so on).
  
  
• Alpha Entry (P₅): Depending on the device, certain characters such as "(" or "$" might require navigation to a different screen. Most of the time, this is indicated by a prompt allowing the user to navigate to an area marked "ALPHA." Such characters cause extra confusion and force the user to do extra navigation. We will assign P₅ to any character that requires navigation to another screen.
  
  
• Numeric Entry (P₆): Numeric data entry, on most devices, is different than text entry. For example, a particular environment for a cell phone might allow for overriding the text associated with each key and allow for using the keys for numeric entry (this can be done using input masks and WMLScript in WAP). We need to also consider those devices that might allow only numeric entry. We will assign P₆ to any numeric character.
  
  
• Stabbing (P₇): In devices, such as the Palm, a pen (stylus in case of the Palm) is provided to "stab" certain buttons on a touch screen. This pen is used for data entry, as well as stabbing different buttons on the screen (the touch-screen aspect and the provided stylus are actually independent, but for our discussion here, we will assume that the functionality is combined). We will assign P₇ to any singular use of the pen (or any stylus type device) for interaction with a device.

Inter-Page Navigation
There are various ways that the user can navigate among pages. Here's how we rate the different types of inter-page navigation:

• Forward Navigation Using Device Buttons (P₈): It is possible to use various buttons (such as the left-top button on Nokia phones used as OK) for navigation. Various devices map the available keys to different navigation rules. We will assign P₈ to use any device-specific navigation.
  
  
• Forward/Backward Navigation Using Device Buttons (P₉): Because of the display limitations (for example, on cell phones), the user might be required to go into a submenu first, enter or view some data, and then return to the parent menu. We refer to that as forward/backward navigation. This is particularly annoying because it causes confusion for the user. We will assign P₉ to forward/backward navigation using custom buttons on the device.
  
  
• Forward Navigation Using Menus (P₁₀): This is the same type of navigation suggested in the section on P₈, except that the device buttons are not used. This refers to navigation using a menu system with radial buttons and/or selecting a menu item on the screen. We will assign P₁₀ to forward navigation.
  
  
• Forward/Backward Navigation Using Menus (P₁₁): This is the same type of navigation suggested in the section on P₉, except that the device buttons are not used. It refers to forward/backward navigation with radial buttons and/or selecting a menu item on the screen. We will assign P₁₁ to forward/backward navigation.

It is obvious that our quick analysis here was biased toward cell phones. It's important to remember that what we have defined here is a methodology and a general approach. By no means do we intend to define all independent variables for all devices. Doing so is a task that remains application-specific. There are many device families that display information and interact with users in different ways. So long as you follow the methodology per device family and clearly define a set for each, the methodology remains valid and applies.

Defining a family of devices is really up to the user. You can say that all WAP phones are in the same family, or that all Nokia WAP phones are in one family and all Ericsson WAP phones are in another. Here's how it depends on your user base. If all of your users are in Japan, you know you must have more families for i-Mode (to give you better accuracy) than for WAP. The reverse would be true for Europe. Other device families could include Palm PDAs, Windows CE PDAs, Voice User Interface (VUI) devices (various types of phones, PCs, etc.), dumb terminals for mainframes, etc.

Here's the subset that we have defined for our application:
{P₁, P₂, P₃, P₄, P₅, P₆, P₇, P₈, P₉, P₁₀, P₁₁}

We can also select multipliers that allow a different "weight" for each independent variable. This allows us to model the fact that not all actions are equally as easy or difficult. For example, using the stylus on the Palm platform to stab an icon on the touch-sensitive screen can be deemed easier than pushing a physical button on the Palm. Both account for one action, but their cost is different.

Beginning the Initial Design

How the Use Cases Add Up

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