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.

Device-Specific MIDP Implementations

With many coding languages, making apps predictable across multiple devices requires porting the app from device to device, with each version of the app 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, apps 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 apps 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 apps to look and act like device-native apps on multiple devices without code changes. When a MIDP app looks and acts like a device-native app, it is predictable. Predictable apps 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 apps 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 tutorial on a mobile phone with a 100-by-128, four-level grayscale display and an ITU-T phone keypad. The app could have a vertical layout with two soft buttons on the bottom of the screen. Now, move the address tutorial to a device that has a stylus, touch screen, and 240-by-100 pixel, 256-color display. If the app 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. Screenshot shows a mock-up of the app on the two devices.

Screenshot Alternate, Device-Dependant Layouts for an app

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

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 apps. 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.

Device-Independent app Design

app Developers

Recommend: Ensure your apps 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 for more information.

Network-Sensitive app Design

app Developers

Recommend: Always consider cost and latency for networked apps. Consumers might pay for airtime by the minute or packet. Requiring a constant network connection could make your app 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.