Designing J2ME MIDP Navigation

Tags: Design,  Design Tips,  Java ME
June 23, 2006 by Barbara
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.


«« Linux alliance challenges  |  Mobile widgets: toy now, tool later »»

4 Comments

  1. “Sun recognized that at any given moment”

    MIDP was developed by the JCP - many companies and individuals, not Sun alone…

    ceo

    Comment by C. Enrique Ortiz — June 24, 2006 @ 12:28 am

  2. Absolutely.

    Comment by Barbara — June 24, 2006 @ 7:43 am

  3. You are of course right to critize this behavior of J2ME Polish, but please take into account that the current version has resolved this: http://www.j2mepolish.org/downloads/j2mepolish-1.3-beta4.jar

    Now the menu is placed depending on vendor’s default settings, e.g. it is named “Menu” on Sony Ericsson and placed on the right side. However, some of our customers have disabled this, because they want to have a common UI (and only one manual) for all devices. Since we know whether the target device has a native “return” key (as most Sony Ericsson do have), we can also map any “back” command to that key. There are several more possible improvements in that area, but we are moving in the right direction, I guess.

    Apart from that you have realized that you can use J2ME Polish with native commands as well. In that respect you have all the functionality and mappings like using only native widgets. So depending on the specific use case, that might also be an option.

    All the best,
    Robert

    Comment by Robert Virkus — June 27, 2006 @ 6:45 am

  4. Agree with the view… I liked the intial spirit of the LCDUI toolkit, and the good level of abstraction. However, most of the implementation failed to use this at their advantage: instead of mapping the Java UI component to phone UI components, they used the ugly Sun RI implementation, and that’s why most of the app looked so bad. This forced many developers to use alternate solution

    Things are a little bit better now, but it’s probably too late….

    Comment by Thomas Landspurg — June 29, 2006 @ 6:22 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.