Tuesday, December 27, 2005

A Mobile User Interface Paradigm

The iPod has popularized a user interface style: side scrolling navigation of a hierarchy. But is it more than a style? Does the iPod point to a paradigm for small-screen user interface the way that Macintosh popularized and formalized (through Apple’s fascistic insistence on user interface standards) the desktop metaphor?

The iPod interface is not original, and the USPTO has thus far ruled it isn’t novel. Creative Labs and Microsoft both hold related patents, and a hierarchical user interface is fundamentally unoriginal. But, as with Macintosh, taking a good idea more seriously than one’s competitors has given Apple the leading position in establishing the iPod user interface as the best example of a new paradigm.

That new paradigm can be summed up as “node by node visualization of taxonomy browsing.” Evidently I won’t go down in history as coining a new moniker as succinct as “desktop metaphor,” but the concept of taxonomy browsing on a small screen deserves almost as much exposition as the desktop metaphor in order to explore what it can do for small-device user interface.

On the iPod, the taxonomy is composed by iTunes and downloaded into the iPod. The iPod user browses the taxonomy node by node. That is, only one node of one taxonomy is viewable at any one time. That sounds rather unattractive, for a couple reasons: First, it comes off as limiting. Who would not want to see more information if they could? Second, “hierarchy” has become a bad word. Search-based file browsers on PCs are happily burying one of the worst user interface ideas ever created in computing – the file hierarchy.

And yet, the iPod is clearly a brilliant user interface. How does Apple turn limitations and what seems to be an out-of-style idea like hierarchy into user interface gold? With two broad approaches: First, accept limitations. Do not strain to deny them. Second, work to create the best user interface within the limitations. Much the same could be said about the difference between Lisa and Macintosh. Lisa did not accept limitations. Consequently, it was slow, and it highlighted the limitations of the Lisa platform. Macintosh accepted tighter hardware limitations than Lisa, and did what was needed to provide an excellent user experience within those limitations. Apple, in the person of Steve Jobs, and institutionally, clearly remembers those lessons.

In the iPod, limitations are ameliorated by the perfect interplay of the physical user interface and the “trail of crumbs” browsing interface. It enables the user to access one branch of a taxonomy so easily that the one-node-at-a-time limitation of the view into the taxonomy is no burden. In fact, compared to more-conventional taxonomy browsing interface of iTunes, it is a model of clarity.

Is this really a paradigm? Is it applicable to domains outside of music taxonomies? With specific examples thin on the ground one has to drill into the paradigm to come up with an answer. Here, I will state that answer in the form of how iPod-like taxonomy browsing fits the model-view-controller architecture for user interfaces: If the model is static, or nearly so, and if the model can be created from some interaction outside the hierarchical view system, such as the iTunes database, or some other database query, and if the results of that query form one or more taxonomies of categories, with nodes of manageable size, then taxonomy browsing iPod-style is a valid paradigm. Speculating on what kinds of applications fit this description, one can think of social networks, heterarchies like semantic networks (such as the CNet semantic network of news stories), and even first party call control interfaces, which I have seen implemented as a menu hierarchy attached to a tray icon.

I think this is enough to define a taxonomy browsing user interface paradigm, and test that node-by-node visualization and trail-of-crumbs forward/backward linking are a good visualization of that paradigm. I did not delve into physical UI and controller design, and it may be that the iPod wheel is key, but I will assert it is not, and that the mobile handset dpad is sufficient (perhaps this will emerge as a single-button versus multi-button mouse theosophical topic).

Now how about some iPod phone rumors!

Saturday, December 03, 2005

Why Mobile Java Has Not Converged on Compatibility

The number of mobile handset users has surpassed 2 billion. About 650 million new mobile phones will be sold in 2005. With the rate of Java-capable phones as a percentage of new phone sales climbing toward 70%, far more mobile Java platforms are sold each year than PCs . Yet the state of non-game mobile applications is primitive, sparse, impoverished in user interface, and lacking in broad handset compatibility.

Mobile games are flourishing. Mobile games are modified – ported – dozens of times in order to run on dozens of handsets. That’s no way to make enterprise software, and the mobile game industry can support this practice only because most mobile games have no life cycle – they are not maintained or updated once they are released for a specific handset. If every time an update was released for a product the porting process would start all over, such products would never be economical or manageable.

It isn’t for lack of effort: Current J2ME standards show considerable progress over the MIDP 1.0 API standards. MIDP 2.0 provides easy standardized access to multimedia capabilities, an elegant and consistent connectivity model that spans connection-based networking, HTTP, and store-and-forward connectivity, and a form-based user interface system that enables custom UI widgets within a framework that abstracts display and input method differences.

Still, the mobile application environment has nothing like the application compatibility provided by PCs.

There are two main reasons for this:

  1. The J2ME standards are correct without being right. They are lawyerly in their concision. They can be defended as providing all the necessary definition – the contract the implementers must fulfill – and, yet, demonstrably they do not deliver a consistent target environment in practice.
  2. There is no body of applications to help identify slovenly interpretations of the MIDP 2.0 spec. The makers of compatible PCs had to show practical compatibility. The makers of J2ME implementations only have to smuggle their cruddy TextField and CustomItem implementations past a validation suite that cares nothing about the quality of presentation to the user.

Perversely, the lack of a practical compatibility test prevents the growth of a corpus of applications that would form that test. IBM’s PC attracted hundreds of applications that were being expanded and updated with an expectation of compatibility across IBM’s PC product line and new models before the first compatible clone appeared. These applications formed the basis of a practical test for compatibility. Mobile application compatibility has neither chicken nor egg.

Mobile search is one of the first areas where a mass-market application has to overcome the compatibility limitations of J2ME. Mobile search client applications will have a lifecycle. They will be updated. They will be released into a environment where it will be impossible to exhaustively test on every new handset. In short, they have to make the leap from the J2ME environment that is barely tenable for games, all the way to making it work for a mass-market product.

This won’t be easy, and many mobile search developers have concluded that J2ME is not ready to support such an ambitious application. They have stayed with presenting a user interface through the WAP browser, or they have started with smartphone platforms like Symbian and Windows Mobile as a basis for mobile search applications.

One problem with the latter approach is that Symbian and Windows Mobile phones constitute a narrow sliver of the market. There is also no great support among network operators and manufacturers to push smartphones. There is no distribution channel for large smartphone applications that must be installed from a memory card. Customers don’t know what benefit smartphones bring, and all the popular features like cameras, video, and mp3 music are available on inexpensive phones that do not tout themselves as “smart.”

The opportunity is in the billion or so Java-enabled phones that will be in the installed base by 2008 – within the next two or three product cycles for application development. If any mainstream phone will be “smart” by current standards, it will be mainly due to the price of hardware declining to the point where, for example, Nokia Series 60 phones become cheap enough they can come free of charge with a postpaid contract of a year or two.

So, can you just hang back and wait for the mobile application situation to fix itself? Only if it is satisfactory to see a billion people running around for several years not using your software. With numbers as big as they are, you have to try. So, what can you do?

You can:

  • Use the available tools. As imperfect as the MIDP 2.0 UI tools are, they are better than rolling your own, which cuts you off from platform-specific input methods, like voice input, that are accessible only through the built-in UI widgets. MIDP 2.0 forms enable custom UI widgets with convenient interfaces to keypad and stylus inputs, focus management, and repaint management. Add custom widgets to your application to create powerful and distinctive user interfaces within the MIDP UI framework.
  • Build tools where appropriate: While CLDC and MIDP 2.0 handle UI adequately well, and networking and multimedia quite well, they fail to address many practical issues in creating serious applications. Script-driven testing, logging, and update management are areas where you are on your own. Take the time to design these capabilities in harmony with the basic capabilities of J2ME.
  • Write once, test everywhere, fix portability issues as if they are bugs – which they are. Don’t “port.” Compatibility is within reach, although it may not seem that way when first you begin to test an application across multiple KVMs. The numerous issues you will discover will make you want to give up the pursuit of compatibility and adopt the game publishers’ approach of creating a “port” for every handset. If you persevere past your first handful of handsets, compatibility on subsequent platforms will come easy, and by the time you are done with testing on 15-20 handsets, you will have achieved compatibility on dozens of handsets.
  • Test everywhere, and use the update tools you built to keep your handset compatibility footprint growing. You will perpetually find new issues. But if you successfully fit the solutions to these issues into a single widely compatible build, you will have the ability to update your applications quickly and with minimal pain. This is the payoff: When you achieve wide compatibility, your next major application rev will ship with accessibility to the most customers, with the least support burden, and it will ship more quickly than your competitors’ applications. If you succumb to the port-per-handset approach, your rev 2 launch will suffocate under the load of porting, testing, and release management.

There is a reward for the first developers to cross the compatibility threshold in mobile Java applications. First-mover advantage in complex mobile Java applications is available, but hidden behind layers of challenges. If it was easy, everyone would be doing it.