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.

Sunday, September 25, 2005

Why Everyone Won’t Succeed

Most people in the daily drive to get the job done focus on what it take to succeed. So I was caught off guard when I was recently asked “Why will some efforts at mobile search fail?” Of course, most such efforts will fail. And they will fail despite being funded by VCs that hate to fail and that put a lot of effort into picking a high quality team that hates to fail. That team, in turn, will work very hard to succeed.

There are general answers: there isn’t room in the market for all the ventures that enter it to succeed; some will be undercapitalized, some will fail due to project risk. But those are unsatisfyingly unspecific answers. To provide a really good answer to why most attempts at mobile search will fail, the answer must, at least, carve out a slice of the problem space, and it must say how this kind of answer applies to mobile search, and how it does not apply to startups in general, or search in general. I find that there is a fairly clear and informative answer to why some people – and I aim to make sure this means “other people” will fail: Mobile search is a classic case of interdisciplinary development.

Unified messaging, the focus of a company I started many years ago, was also a case where mastery of two very different disciplines was required. Then, as now, however, the difficulty of integrating across two disciplines where you will seldom find experts in both is hard to measure, and is often not taken into account in measuring the ability of a venture to capture and defend a position in the market. That is, this is both a hidden danger and an underappreciated quality.

It is, of course, easy to enumerate the features of voice mail, and of email, but, as evidenced by the implementations, most attempts failed to integrate the two correctly. Successful implementation of the idea of unified messaging required insight into the direction – not just the current position – of voice processing and messaging systems, mainly in the area of emerging APIs and standard interfaces, and it required integrating this knowledge right through to the business model and business development strategies. Even Active Voice, which is widely regarded as the exemplary case in unified messaging for having the best integration to messaging standards, did not until fairly recently, when media gateway nodes displaced voice processing cards as the interface point, fully abstract hardware from the unified messaging system.

In hindsight is it fairly clear: unless you see where messaging and voice processing are going, you can’t position yourself correctly among your technology providers and channels. There is no obvious choke-point here – no way to deny a competitor who has figured this out access to the same partners and channels, so this isn’t widely seen as a differentiator. But the fact that so few entrants to the unified messaging field got this right means that interdisciplinary integration probably is a significant advantage that some ventures will wield with strong effect against their competitors. Not all ventures share this attribute, so there is probably something to be learned about building a venture where interdisciplinary integration is a requirement for success.

Mobile search is, if anything, a more difficult problem than unified messaging. At least three major distinctive areas of competency have to be integrated into a successful system: Mobile applications development; search; and IN (intelligent network) application development. These areas cannot integrate simply by gathering competent people in each. In fact, you will be hard-pressed to find compatible minds that have deep experience in each area, and that know how to reshape their own areas of expertise to fit with the others and extract the highest potential from the combination.

By “compatible minds” I mean people that can flex to fit the requirements of interdisciplinary innovation. Failure to flex means failure of the whole enterprise: mobile game coders will often fail to find the discipline to create an ambitious mobile application that works reliably. Symbian coders will fail to see that J2ME is an adequate platform, and that broad platform reach can be available through J2ME. Those steeped in search might fail to adapt to the limitations and opportunities of small-format presentation. And IN-experienced engineers can be too much in the telco mindset to integrate with anyone else with a more entrepreneurial world view. If the executive leadership of such an enterprise cannot encompass all that enough to evaluate if it is coming together or not, chances for success are diminished. If the participants reach only a minimal level of compatibility and fail to reach for ambitious goals in every distinct area of competency, the result will be easily matched and exceeded by competitors.

It can all be boiled down to four points:

  • Only a small subset of ventures require innovation and audacity across multiple disciplines, so it isn’t a familiar problem.
  • Apart from recognizing that some of these ventures are execution plays, VCs find the value of interdisciplinary innovation hard to measure.
  • The participants in these ventures have to be inquisitive about each other’s domains of knowledge, and be able to seek innovation near those boundaries. The more dimensions to the problem, the less likely it is this will happen.
  • The leadership, at the stages of founding, funding, and operating the enterprise have to be cognizant of their situation and act to make an interdisciplinary venture work.

But even simplified to this degree, interdisciplinary ventures are more complicated, and therefore more risky, than simpler plays. They are all the rarer in that, even when they are recognized it may only be to avoid them.

Monday, May 16, 2005

Interfaces Again

Early in my career, I wrote a book on Macintosh programming. Having worked on LISP workstations, I had used, and coded, graphical user interface programs, on one of the earliest systems to put a lot of effort into providing the tools to create a visual user interface. I was drawn to the Mac by the fact that a $3,000 computer could do what a $100,000 workstation did, and provide a much nicer look and feel. It was the first instance where I had seen, in depth, the benefits of balancing the effort that went into a GUI toward providing a pleasing user experience. The Mac was also a marvel of design compromise and implementation expediency – if it hadn’t been, it would have cost like a LISP workstation. Few now remember that the Mac was Apple’s second try. The Lisa, uglier and costlier, came first.

“A ‘pleasing’ user experience? And compared to what?” At the time, those were novel questions. The desktop metaphor design pattern and underlying architecture of multiple graphical contexts were solidly in place by then, but Steve Jobs was the first to get it right. The Mac had an interface that was up to standards that could be analogized to professional print layout design, while retaining all the structure of the desktop metaphor and windowing graphics system.

Since that time, the desktop metaphor got deconstructed into something more like the rock and roll magazine metaphor, as Web hypertext interfaces became the dominant area of interface design activity (desktop productivity having been pretty much done to death). Meanwhile, Sun tried to turn Java into a multi-platform GUI system, and, as if to illustrate the difficulty, is only now getting to a satisfactory result with the latest version of Swing, which still has no substantial library of applications.

Today, we are replaying this phase of user interface evolution in miniature. The memory and processor resources of mass-market mobile phones are about the same as the early Mac systems. A cut-down version of Java has evolved, in its MIDP 2.0 form, a usable user interface system for the small-screen medium – something short of a windowing GUI system, but good enough if one takes a more free-form approach to UI presentation.

The commercial and design contexts of mobile user interface creation are very different from the coherent drive to a desktop metaphor productivity suite that propelled early desktop GUI efforts. Mobile handsets have terrible user interfaces. Many mass-market phones don’t even try to have a good UI. Nokia’s Series 60 and Symbian UIQ are in danger of becoming obsolete before they fully evolve, having developed on too-limited platforms, and lacking a modern garbage-collecting implementation language. Windows Mobile is a very credible effort, with a long life ahead of it, but it suffers from Microsoft’s failure to develop momentum for Windows Mobile and of the curious and persistent incompleteness of the .NET Compact Framework to encapsulate all the platform APIs and become the unequivocal choice for UI implementation on the Windows CE platform. BREW, like Symbian-platform UIs, is stuck with C++ and an API that is inferior to the mobile version of Java, but BREW, at least, has been explicitly targeted at providing a customized user experience in Qualcomm’s new UIOne initiative.

Any serious effort to create a widely used GUI on mobile handsets has to encompass Java, BREW, and Symbian, and it has to provide a road map to cover Windows Mobile, Palm, RIM, and Linux-based 3G and VoIP handsets. It has to be designed in the context of present realities in handset hardware content, likely new applications like mobile video, and one-handed operation where the thumb – the least dexterous digit – is made to do all the work.

The Web has influenced UI design again. This time it isn’t by deconstructing the UI into an interactive hypertext Web, but by being the place where user interface has evolved toward search being the starting point of interaction.

So this is the environment into which my current effort at creating an ambitious non-game mobile application is launched. Compared with desktop GUI applications, the evolutionary stage of mobile platforms makes things more challenging: more variation in the platform. More technologies to understand. A necessarily multi-platform implementation. Fewer design rules, and certainly no Steve Jobs and his salutary UI fascism, but in a world with a lot more interactive design sophistication.

Success requires remembering this evolutionary context and using the analogies it provides to navigate the new challenges. Those new challenges, and the solutions, will write a new chapter in UI design.

Wednesday, April 27, 2005

After Games

I am no longer working at a mobile game company. Not because I became disillusioned with mobile games – I’m still advising people and companies in the mobile games arena. But the mobile games train has left the station. The time for startups in mobile games – at least until some fundamental shift occurs – has passed, and acquisitions and consolidation are a big part of mobile game news these days. I look forward to Kayak more-fully realizing the potential of the products the Chasma team created.

Mobile games transformed my view of a new vehicle for applications delivery. And, while mobile games are now a battlefield for larger companies, new areas of non-game mobile applications are opening up. The same low-friction channels and staggering numbers of mobile customers will do for mobile search and rich forms of mobile media what they did for mobile games. In many ways, the landscape is like that of mobile games three years ago: the technologies and delivery vehicles are there, waiting to be adroitly exploited.

Even more exciting than the mobile games business, where m-commerce and billing-on-behalf-of were the keys to making large piles of money from simple products, the business model for new fields like mobile search is still malleable. Stunning breakthroughs is business strategy will unfold alongside what are likely to be the most sophisticated mobile applications ever created.

Mobile search holds the key to a shift in the mobile telephony user’s usage patterns that is far more powerful than features like push-to-talk that, up to now, form the basis for differentiation among mobile service offerings. It is an exciting time in mobile applications that will reverberate through the whole structure of the mobile network.

To take but one example: Mobile video will be used in ways fundamentally different from the way people consume broadcast video. Substantially all of mobile video will be an on-demand, time-shifted, TiVO-like experience. So the grid-like schedule table that is a staple of cable TV user interface will be inadequate for navigating mobile video. In an on-demand world with an infinite content library, search is likely to be the first step every user takes on the way to the video they want to see.

Google’s brilliantly simple user interface has conditioned people to the belief that search is simple, because it is simple to use and delivers the right results so reliably. This is, of course, a misconstruction of what is, in reality, a subtle, deep, and complex system that happens to work very well. Even more than Web search, mobile search will tie together information sources from the mobile network, the Web, and numerous structured, specialized feeds into a product that appears simple, but represents a new level of sophistication in search, as well as breaking new ground in mobile applications.

This is going to be interesting!

Tuesday, January 11, 2005

Content Networking by the Numbers

Google has indexed, as of the moment I write this, 8,058,044,651 pages. Google also indexes about 1 billion images and about 1 billion netnews postings. In a masterful piece of S-1 filing divination, Tristan Louis estimated the size of Google’s computer infrastructure: 719 racks; 63,272 machines; 126,544 CPUs; 253,088 Ghz of processing power; 126,544 Gb of RAM; 5,062 Tb of hard drive space. You can find his research on the topic here: http://www.tnl.net/blog/entry/How_many_Google_machines.

Pretty impressive. Google users evidently think that Google finds what they are looking for. So, not only is Google large, it has successfully found what most users want to find. Google has made meta-search an anachronism. Few now have the resources to catch Google.

Any flaws? Some people complain that Google can be gamed. Others complain that Google censors. But the real issue is that Google indexes only a tiny fraction of the Web. This analysis - http://www.brightplanet.com/technology/deepweb.asp - claims that fraction is somewhere between 1/120th and 1/620th.

An interesting aside in Bright Planet’s analysis is that original deep Web content now outstrips printed content. Yes, the Web is now bigger than the printed word.

Bright Planet’s analysis excludes images from the size measurement of the un-spidered “deep Web.” So where do we look to get a handle on the size of multimedia content in the Internet? In this case, we can look to measures of Internet traffic – specifically P2P traffic.

The numbers are stunning: CacheLogic, a maker of traffic management and network intelligence (deep packet inspection) gear, found that P2P traffic ranges from 55% to 80% of the bits traversing the Internet (http://www.cachelogic.com/research/slide12.php). The Web, which is 120 to 620 times larger than Google has indexed, is only 5% to 20% of Internet traffic. A single movie or TV show can significantly drive traffic levels in an ISP’s network. Boggling, but what does it all mean? Here we can turn to the Eight Fallacies.

Topically, the Eight Fallacies were formulated by Bill Joy, Dave Lyon, Peter Deutsch, and James Gosling – some of the brightest of Sun’s luminaries – as Sun was formulating its approach to the mobile computing market. If you don’t pay attention to the numbers, you can fall into one or more of the Eight Fallacies:

  • The network is reliable
  • Latency is zero
  • Bandwidth is infinite
  • The network is secure
  • There's a single administrator
  • The topology won't change
  • Transport cost is zero
  • The network is homogeneous

It could take a book chapter to fully elucidate the meaning of each of the Eight Fallacies in the context of content networking. But the main point is that content is so big that the Internet will be designed around moving content. The Web is just the literate scum floating on top of an Internet that is rapidly evolving toward the post-literate masses. Never thought you anyone need those monster petabit routers? Think again. Asymmetrical last mile OK? Maybe not. Many other apple carts will be overturned.

What category of application will drive the next big shift in Internet traffic? Content networking will probably be a big part of that next killer app.