Approaching UI Development
As developers, we're used toand often demandthat functionality be available at the click of a button, as a quick key combination, or easily accessible from a list of commands in a menu. In the constrained environment of a mobile device this is often not useful and can, in fact, be overwhelming to a user. Personally, I'm often perplexed at the ergonomic and human interface choices made for interacting with devices, so I take the approach that the fewer commands available, the better. Actions should be possible with as few clicks as possible.
A general guideline to follow when designing the UI is to gently guide users to what they want to do, providing only those actions that are necessary for the current context (or state) of the application. It's useful to understand the environment where you plan to deploy your application and to understand end user's goals. Then you can build the user interface and application flow with this in mind.
To do this you define the goals of the application, how long the user is likely to have access to the network (if the application requires network access), and how much time the user can afford for data entry and data lookup. Basically, you tell yourself a story about how you imagine the application will be used and, budgets willing, find out explicitly how a few of the users will use or currently use the application. This is somewhat like a very loosely defined Use case. See the Related Resources section of this article for a list of recommended readings on user interface development and other useful tools.
The sample application for this article, called mAmazon, makes use of most of the concepts discussed earlier. mAmazon lets you compare the price in a bookstore with the price of the same book on Amazon.com.
If Amazon carries the book, the application shows the title and the price. You can drill down to see more information such as the author, the ranking, and the ISBN number.
You should make a flowchart, like a storyboard, actually drawing the screen as you imagine it would appear in a cell phone. Try to place elements roughly in the order you want them to appear in the final application. Associate the Commands in a separate box, because, as explained earlier, Command placement varies widely from implementation to implementation. You don't want to assume too much about what the user will see.
Because the MIDP interface metaphor is based on the concept of Screens each element of the flowchart represents an individual screen. Don't worry too much about reusing the screens or commands at this time; after you're confident that the model meets the application's usage demands, you can take the time to isolate commands and determine if it would be advantageous to share commands or other resources in the application.
Amazon is perfect for this application because you can request information in XML from an HTTP query to their server. To do that, sign up as an affiliate and you're ready to go. Because the MIDP specification demands that all devices provide some form of HTTP communication capability, you're guaranteed to be able to access the information regardless of the target device. The XML format is convenient because it's nicely formatted and you can use existing libraries like kXML to parse the data. kXML is an easy-to-use and compact XML parser provided by the Lutris Enhydra Group. You can download it from Enhydra.org.
|Figure 8: The user has very few chioceseither search for a term or exit the search.
The network aspects of this application are beyond the scope of this article but you should look at the code and use it in your own applications if you find it useful. Also, the application doesn't take memory constraints into account with respect to data retrieval over the network, but it does page through large data results instead of attempting to display the entire list.