Java ME on Symbian OS : Handling Diversity - Using Adaptive Code and Flexible Design to Handle Diversity

Not all diversity issues are as obvious as unsupported JSRs or media support fragmentation. The differences may be small yet their impact on the user can be significant.

There is more than one way to handle those subtle differences. You could choose to apply a technical solution and write more adaptable code that produces satisfactory results on all the different devices. Alternatively, you could change the usage and design of the application. In some cases, you need to apply both techniques.

A central area of Symbian OS customization is the UI. Phone manufacturers are required to customize the Symbian OS UI and to implement their own look and feel. To ensure the user experience remains identical between Java applications and native applications, Symbian OS native customization of the UI applies to the Java ME subsystem as well. This is why similar LCDUI code, when run on Symbian smartphones from different manufacturers, might produce subtle differences that can nevertheless significantly change the usage of the application.

In this example, we consider how commands map to softkeys on two different UI platforms. Let us consider the following snippet of code:

private Command dismiss = new Command("Dismiss", Command.OK, 0);
private Command back = new Command("Back", Command.BACK, 0);
private Command exit = new Command("Exit", Command.EXIT, 0);
private Command reply = new Command("Reply", Command.SCREEN, 0);
private Form form;
public SoftButtonsExamplet0(){
  form = new Form("Command Examplet 0");
  form.addCommand(dismiss);
  form.addCommand(reply);
  form.addCommand(back);
  form.addCommand(exit);
  form.setCommandListener(this);
}

The example uses four command types: OK, BACK, EXIT and SCREEN to specify the intent of the commands. The four commands are mapped to softkeys according to the device's native layout. Figure 1 illustrates the differences in how the same application would appear on our reference devices. As you can see, the Nokia N95 has two softkeys and the Sony Ericsson W960i has three softkeys.

Now that we have seen the code and the differences, let us think about how such a small difference can have a significant impact on the user. For example, consider a usability case which defines that when an SMS message is received, the user should see the message and respond or dismiss it with only a single click. Bob uses the application to send an SMS message from his Sony Ericsson W960i to his colleague Alice, who uses Nokia N95. Alice should be able to respond to the message or dismiss it, with only a single click. At the moment, neither Bob nor Alice can do those actions with a single click.

Although we cannot change the restrictions imposed by LCDUI or by the softkey layout of the UI platform, there are a few options we can think of. First, there is the option of two different code bases, one for each UI platform, and deploying different JARs according to the target device. The implications are increased maintenance, possible application fragmentation, increased costs, needing to sign the application for each code base, and so on. Multiple JAR files is not a scalable solution when you have an installed base of more than just a few target devices.

Figure 1. Layout of softkeys on a) Nokia N95 and b) Sony Ericsson W960i

Another possible solution involves extra effort and a radical change to application usage: the application UI could use a screen menu instead of softkeys. The screen menu could be a flashy SVG UI or a simple LCDUI List. However, we can first try to find a simpler solution which does not require us to reimplement our code base.

Let's see if the screen actions and sequence of the current application can be improved. There are four options for the user: Reply, Dismiss, Back and Exit. It seems that users would very rarely use Back or Exit when an incoming message is displayed, so we can remove those actions from this screen. Of course, we must give the user an option to exit from other screens, which are more suitable to the Exit action.

private Command dismiss = new Command("Dismiss", Command.OK, 0);
private Command reply = new Command("Reply", Command.SCREEN, 0);
private Form form;

public SoftButtonsExamplet1(){
  form = new Form("Command Examplet 1");
  form.addCommand(dismiss);
  form.addCommand(reply);
  form.setCommandListener(this);
}

As you can see in Figure 2, the user still cannot respond with a single click. The Nokia N95 user has to select the Reply and Dismiss actions from the Options menu and the Sony Ericsson W960i user has to open the More menu to choose the Reply option.

Figure 2. Reduced button layout on a) Nokia N95 and b) Sony Ericsson W960i

We can change the command type of one of the commands to map to a different softkey. The following code changes the Dismiss action to be of command type CANCEL.

private Command dismiss = new Command("Dismiss", Command.CANCEL, 0);
private Command reply = new Command("Reply", Command.OK, 0);

The MIDP specification says this about command type CANCEL:

As you can see in Figure 3, that produces the correct result on the Nokia N95 (as Dismiss is mapped to the Back button, the only remaining option, Reply, is mapped to the other softkey). On the Sony Ericsson W960i, the Dismiss command has been mapped to the system button at the top right of the screen.

That is probably the right thing to do as it respects the native platform usage policy. In some cases, you may prefer both Sony Ericsson W960i and Nokia N95 users to see a softkey with a Dismiss label. Let's change the Dismiss command to be of type BACK and see what happens:

private Command dismiss = new Command("Dismiss", Command.BACK, 0);
private Command reply = new Command("Reply", Command.OK, 0);

Figure 3. Dismiss command mapped to Cancel softkey on a) Nokia N95 and b) Sony Ericsson W960i

Figure 4. Dismiss command mapped to Back softkey on a) Nokia N95 and b) Sony Ericsson W960i

Figure 4 shows that both labels are visible and users of both UI platforms can perform the actions with a single click.

Is it a cheat to change the Dismiss type to BACK? Take a look at the MIDP specification definition of the BACK command type:

So this is not a cheat but a legitimate change that can be regarded as making our code adaptable to various Symbian OS UI platforms.

I hope that this example demonstrates how a simple rethink of the application usage and some minor changes in the code to make it more adaptable would give the same user experience on different Symbian OS UI platforms.

In general, Symbian OS is customized by phone manufacturers; therefore, there could be subtle differences which impact the usability of your application. Plan the UI to ensure that users on different UI platforms can use the application as intended. A rethink of the application usage and more adaptive code are proven techniques that you can apply before resorting to more radical changes.