Recent Blog Posts

J2ME designers have three basic choices in creating their applications:

1. Use high-level user interface widgets. These are pretty ugly, but usable.
2. Use the low-level user interface widgets, like Canvas. This immediately generates a slew of cross-device incompatibilities.
3. Use a third party UI library, such as J2ME Polish.

Unfortunately, most people, including designers, developers, and business folks, look only at the "ugly" and immediately jump to options 2 or 3. The smarter ones then look at "cross device incompatibility" and jump to item 3 alone.

Don't get me wrong, J2ME Polish is great. But it has a major blind spot: navigation, particularly the treatment of abstract commands. That's reasonable given how few people are even aware of their existence. I've spoken with many developers who assert that the commands are "broken" because they behaved differently on different devices. Well, that's how they are supposed to work.

Abstract Commands

Sun recognized that at any given moment, any of a variety of things might be useful for the application to do. Backwards navigation, exiting, selecting an item, returning to the home screen, acting on a list item, and so forth are all crucial parts of application design. Even the rather simple browsers on phones have back, select a list item, and return to the home page.

The trick was that different devices have different sets of buttons, and different user interface conventions. Nokia phones tend to use the right softkey as "Back" or "Cancel", whereas Sprint phones (across vendors) have separate Back buttons. Some Nokia phones have a select key whereas others relegate it to an item in the Options menu.

Instead of restricting application developers to only listening for specific button types, J2ME also listens for abstract commands. The device figures out where to put them based on a combination of their category and their priority within the category.

Devices with a hardware Back button usually take the highest priority command in the "Back" category and map it to the Back button, whereas a Nokia device will map it to the right softkey. A Palm will display two or three commands as buttons on the screen, and relegate the remaining to two menus. Many softkey phones place the highest level "Item" or "Screen" command on the left softkey, and put the remaining in a right softkey labeled "Menu". Some Samsung phones, with their OK/Menu buttons, put all commands into the right softkey menu.

Oh, and one major challenge with this: many device manufacturers are largely ignorant of abstract commands, and they may leave the command mapping to the KVM provider, who may or may not understand user interface design. One of my manufacturer clients had a user experience person in charge of J2ME, but this person did not know about abstract commands at all.

J2ME Polish Softkeys

As best I can tell, J2ME Polish mistreats these abstract commands. If supported at all (and you have to turn the menu bar on in the code to do it), all commands are mapped into the left softkey, labeled "Options". The right softkey, if present, is labeled "Cancel".

Yes, that's right: all phones now have a Nokia user interface with J2ME Polish applications!

I can understand this decision, but it results in a number of pretty - but very hard to use - applications. A RAZR user suddenly faced with an Options menu to select a radio button will be very confused.

Designing Softkeys

Designers who recognize the problem can solve it in three ways:

1. largely ignoring it and mapping the softkeys however they desire, probably ignoring supplemental buttons like "Back"
2. using native widgets, with all their challenges, and taking advantage of abstract commands
3. carefully categorizing devices by their button capabilities and native handling of softkeys, and replicate that handling in the J2ME code.

The last item is a lot of work, and introduces extra portability issues. The device description repositories do not provide enough information do make the categorization automatically. The native widgets are either ugly or too much work. So most people ignore the problem, which adds an extra barrier to use for many users.

There is hope: device description repositories are getting better, and Little Springs Design is developing a device hierarchy that will make the third item much less work. Until then, you're on your own.

A number of industry notables, including NTT DoCoMo, Samsung, Vodafone, NEC, and Motorola, have announced their intent to provide a open-source Linux mobile phone software platform. I hope it works, but this may be much ado about nothing.

I've had folks around me adopting Linux on their PCs with various degrees of success. One of the key challenges is getting drivers and similar to work with arbitrary hardware: putting Linux on a Dell laptop is likely to eliminate the ability to use the DVD player. Or whatever. This problem should be addressed by the fact that the manufacturer would (we hope!) make the software work on the device.

The second problem is the dearth of user experience innovation in Linux. Despite being on a different core data structure, the GUI generally replicates whatever the Windows version does. Modifying the user interface is quite challenging, and is normally restricted to so-called "look and feel". That is, fonts and maybe graphics. (example: look at the differences between NeoOffice and OpenOffice - it's a lot of work just to get the same software to look right on the Mac)

So what this alliance needs to do is to decide - NOW - what the core user experience for the devices might be. This means working on what classes of devices might be (feature phone, entertainment device, "smart phone", etc.), and then planning the user experience for core applications for each device class. This needs to be done obviously with an eye towards manufacturer differentiation - but differentiation should be restricted to adding peripheral features and colors/fonts/layout.

One key source of efficiency in development and user experience is keeping data structures the same across devices. This will make synchronization and data backup easy (SyncML is a good start, this would go further).

Sadly, the consortia I've seen end up mired in politics, with features defined by the engineers and executives, not those focused on the user.

I'm worried that this agreement will result in yet another "design by committee" design, and Linux phones will have the same sort of second-class status that Linux desktop software does.