MIDP Style Guide for the Java 2 Platform, Micro Edition

2.4 Implications of the MIDP Environment

Usability studies on consumer products have repeatedly shown that predictability (having the product "do the right thing" on the device) is far more important than consistency or efficiency. Forcing consistency across radically different products often makes the products unusable.

2.4.1 Device-Specific MIDP Implementations

With many programming languages, making applications predictable across multiple devices requires porting the application from device to device, with each version of the application using different user-interface code. This would be especially difficult for mobile information devices because of the many types of device displays and input-output solutions. With MIDP, applications do not control the details of focus, traversal, scrolling, and so on. Those device-specific details are handled by the MIDP implementation. As a result, well-designed MIDP applications can run on multiple devices without code changes, which saves time.

Giving MIDP implementors the responsibility of creating and laying out MIDP user-interface components for their devices also enables applications to look and act like device-native applications on multiple devices without code changes. When a MIDP application looks and acts like a device-native application, it is predictable. Predictable applications are easier to learn and use.

MIDP Implementors

Strongly Recommend: Create and lay out MIDP user-interface components in a way that enables MIDlets to look as much like native applications as possible. For example, assume that a device has a particular way to present a list to the consumer. The MIDP implementor should ensure that the MIDP implementation presents lists in the same way (within the bounds of the MIDP specification).

Consider, for example, an address book on a mobile phone with a 100-by-128, four-level grayscale display and an ITU-T phone keypad. The application could have a vertical layout with two soft buttons on the bottom of the screen. Now, move the address book to a device that has a stylus, touch screen, and 240-by-100 pixel, 256-color display. If the application were responsible for the details of the UI, the vertical layout would be awkward and inappropriate. Instead, assuming that the MIDlet has both color and grayscale graphics, it could look and behave as if it were created for the second device, without code changes. Figure 2.1 shows a mock-up of the application on the two devices.

In addition to making the screens look like those of native applications, MIDP implementors can also make MIDP user-interface components behave in ways that are similar to native applications.

MIDP Implementors

Strongly Recommend: If your device supports touch input, incorporate it into your MIDP screens in a way that is consistent with the capabilities of native applications. For example, you could allow a user to choose an element of a list by tapping it.

Strongly Recommend: If your device has keys or gestures dedicated to certain tasks, such as selection, use the same keys for MIDP tasks.

2.4.2 Device-Independent Application Design

Application Developers

Recommend: Ensure your applications are predictable. For example, always have your unstructured screens support key presses, a standard input mechanism. In addition, add touch input capabilities if the device supports them. See Chapter 10 for more information.

2.4.3 Network-Sensitive Application Design

Application Developers

Recommend: Always consider cost and latency for networked applications. Consumers might pay for airtime by the minute or packet. Requiring a constant network connection could make your application costly to run. In addition, in current mobile phone networks a round trip to and from a server could take two seconds or longer. High latencies affect responsiveness. For example, a fast-paced two-player game would be unusable under these circumstances.