How the Use Cases Add Up

Let's evaluate the sets for our use cases. Here we only give you the step-by-step evaluation for Nokia 7110 of Use Case 1. You can extrapolate the results for yourself for the other use case and for other devices. We use "sditlinger" as the username and "rrichards" as the password.

Here are the key sequences:

1. Press Option (P₁₀).
   
   
2. Select Edit (P₈).
   
   
3. "s" requires four key presses, "d" requires one key press, etc. Total key presses for "sditlinger" is 23 (P₃).
   
   
4. "s", "i", "l", and some other letters require multiple key presses on the same key. This happens seven times (P₄).
   
   
5. Once the user name is entered, press OK. This causes navigation to a previous screen (P₉).
   
   
6. Select Edit (P₁₀).
   
   
7. Press Clear (P₉) five times to clear the user name that was put in previously.
   
   
8. Total key presses for "rrichards" is 23 (P₃).
   
   
9. Multiple key presses happens seven times (P₄).
   
   
10. Press OK. This causes navigation to a previous screen (P₉).
    
    
11. Press Options (P₈).
    
    
12. Press Down-Arrow once (P₈).
    
    
13. Select OK (P₉).

For this particular test case, we assumed that the username and password are both strictly letters and numbers (no characters such as $ or # allowed). There is no scrolling because the devices we selected have large enough screens to display four lines of text. There is no stylus stabbing, either, because the Palm was not included in the device families we decided to support.

Therefore, P₁, P₂, P₅, and P₆ are 0. Although one can represent the final result as a combination of different functions of the independent variables, we assume that the "weight" of each instance of each independent variable is the same for the final result. In other words, pressing the OK button has the same cost whether it occurs during the first step or the last step of navigation. Though this assumption is not necessarily true, it will give us a very close, linear approximation to what might be true.

Based on the above, we obtain the following for Permutation 1 of our code for Nokia 7110:
{P₁, P₂, P₃, P₄, P₅, P₆, P₇, P₈, P₉, P₁₀, P₁₁} resolves to {0, 0, 46, 14, 0, 0, 0, 8, 3, 2, 0}

This lets us come up with an average length that is the sum of the value of all variables divided by the number of variables. The average length for our example is 6.36 for permutation 1 for Nokia 7110 (total score is 73 and there are 11 independent variables, yielding an average length of 6.36). See Table 1 for the use case scores on the devices we tested. The lower the number, the better. These numbers basically represent the "user impedance." In other words, they show how difficult it was for the user to use the user interface. The reason to do this whole thing is so that we find out which navigation tree is the most user-friendly one for a given family of devices.

Obviously, if we're supporting a large number of devices within each family, this process needs to be automated programmatically. The tool can be used to reveal the flexibility of the methodology to the user interface designers, as well as the quality assurance engineers.

It is also important to remember that the amount of code (number of characters) written in WML—as well as the number of calls to WMLScript—needs to be taken into account in the final score. Minimizing code is crucial for maximizing use of the device, because device memory is limited and you never know if there's enough memory for the code you put on a page or not. There many variations among devices. For example, there are several variations of the Samsung SCH-850 with a variety of memory sizes. The more memory and CPU is used, the slower the interactions with the device and the faster the battery is used up. Code efficiency considerations can be treated as other independent variables in our model or can be considered separately. We decided not to include code size in our final analysis.

Quantifying the interaction between a user and a device is most applicable to devices that have limited capabilities, such as today's wireless and mobile devices. Once our problem was defined, we approached the solution by looking at the interaction between the user and the device as content that could be represented as a composition of a set of orthogonal and independent atomic interactions, such as entering text. First, we saw that we could use XSL, scripting languages (such as JSP), and good design decisions as a path to a better system. Later we formalized a methodology to select the best set of screens based on this information.

It is important to remember that business requirements must be considered carefully in the original design of the set of user interfaces. If business requirements of the application make no sense (for example, accessing e-mail via a purchase ordering menu) then the business process flow is disrupted. Business logic and flow must be considered before you can select the first set of user interfaces and before you can implement the selection process suggested in this article.

Here are the steps toward application development and quality assurance:

1. Define the application requirements, use cases, and so on (the typical software development requirements gathering process).
   
   
2. Define the device families to be supported for the application.
   
   
3. Define the device sets within each device family to be supported for the application.
   
   
4. Define an independent set of variables that describes the interactions of the user with the device families.
   
   
5. Design the first set of user interfaces based on the business rules.
   
   
6. Create a grading system for the variable set.
   
   
7. Use a grading system to evaluate the various possible permutations of the user interface per device family.
   
   
8. Create a set of XSLs for each device family. Custom XSLs might be created for specific devices whose use is inordinately higher than other devices (at least one order of magnitude).

Choosing the most efficient way for users to interact with an interface will speed up the user interaction with the system and produce a more pleasant experience.