The Motorola Droid is a Turning-point

First, a confession. As a co-author of Android Application Development http://www.amazon.com/Android-Application-Development-Programming-Google/dp/0596521472 and Chief Architect of an IP communications platform based on Android, my main fascination with Android was based on the Android platform being the most exciting thing that ever happened to client Java and embedded user interface, and to open mobile communications platforms. The Android platform has that sense of perfect balance that I recall from when I first wrote software for the original Macintosh. I enjoy writing Android software even more than I did writing Mac software, both applications and extensions to the Android system software, and I hope a lot of other people will like it, too, which is why I enjoyed spreading the Android software development word through a book.

Using an Android handset was, however, something I did to get work done. So far, the only new-generation smartphone platform that made me want to use it on my own time was iPhone, or, rather, iPod Touch. iPhone, as a phone, was just not that compelling. This gap between Android technology and desire is echoed in others' opinions in the form of pronouncements that Android is the “cool, but geeky” platform. That gap has now closed.

I just got a Motorola Droid, and, instead of a conventional review, I'm going to address the reasons why Android is ready not only to play a significant role in mobile devices, but to do that at the same level of play as iPhone. The Motorola Droid is the first Android-based product that needs no excuses when compared to an iPhone. This is the result of a lot of effort at Motorola to produce a very polished product, plus the maturing of the Android platform, plus some critical applications.

First, the maturing of the platform: Droid runs Android 2.0. For most applications, this won't make a critical difference, and most applications will be compatible with Droid, even if they have not been updated since Android 1.5. Android 2.0 mostly matures the underlying bits – how Android works as a phone, and how the other built-in applications work. Android is now a great phone. Android always had the better UI infrastructure in the Android framework. Now this superiority shines through in a way that should be obvious to the non-geek user.

Motorola did a great job building a product around Android 2.0. The CDMA radio and phone audio keep calls clear and connected. The TI OMAP 3430 CPU makes Android lag-free with buttery smooth visual effects. The touchscreen is big, sharp, accurate, and responsive. The speaker is clear enough to listen to podcasts without external speakers. The industrial design is better in person than in the pictures: It looks massive and square, but it's only slightly less rounded at the corners than an iPhone. It's iPhone-thin despite being a slider; the “frameless” keyboard is friendly to my large fingers and has good feedback. It comes with a 16 GB memory card.

Integration with your Google account is effortless. 20 paces out of the Verizon store, all the 4000+ contacts in my address book were synced and ready to use. And if you have 40,000, you won't have to wait for them all to sync before using them. Sync is a background task and contacts appear in the UI as soon as they are in the handset's database.

There are plenty of competent platforms and industrial designs out there. If that was all there is to it, Nokia would have no worries. The real news in Android is that Google has made it an object of desire, and applications are a big part of that. The tipping point was Google Map Navigation, which makes in-car navigation a feature of Google Maps, but that's not all: Google Listen is second to none for podcast management – which is a lot of what iTunes gets used for. YouTube is, of course, slick as can be. Facebook comes pre-installed and is also very polished. Google Sky Map is an augmented-reality planetarium in your pocket. And on and on. Now there is an amazing and desirable Android app for that.

Android is a new system and it is maturing and improving at a faster pace than iPhone, Symbian S60, or Windows Mobile. There is no feel of a legacy tail dragging behind Android. Applications are impressive and numerous. The app store is simple, fast, and clear. And, while Android is an even-better platform for application developers with the release of SDK r3, Android is no longer just interesting technology.

I used to work in the games business, and the thing about games as products is that features and technologies don't matter if the game isn't fun. Similarly, all the architectural virtue in Android doesn't amount to more than replacing Windows Mobile in the market unless customer say: “That's what I really want.” Motorola's Droid is the first product that can be put on a table next to an iPhone and win the decision entirely on the basis of what the customer sees and experiences within minutes of using it.

And that is a turning point.

Smartphones, 4G, IP, and IMS – Part II: Why is this G like no previous G

Making a phone call is an activity that seems almost as natural as walking, or drinking, but it has a history. About 120 years ago the layout of the phone terminal, with transducers for speaking and listening, was a settled matter of design. In another 20 years the matter of dialing phone numbers was settled as automatic electromechanical telephone exchanges were introduced. A phone call is a blend of humans making accommodations to machines and machines being designed for humans, and much of the early outcome of that blending persists today.

If you look at the software in any mobile phone, the key thing that makes it a phone is the call-state management. This is what keeps track of the state of phone calls (and, in 2.5G and 3G, data connections, too). It enables the user interface of the phone to display the correct state visually and play the right call progress tones (the ones that originate in the handset) at the right time. It also hooks into power management to light the LCD backlight at the right times, the switch that detects if a flip phone is closed, the keyboard lock, and performs other operations that create the user experience of a telephone.

The design of all mobile call state management is based on having one bearer channel to a circuit switch, plus SMS and data. The first implementations of mobile call state management had minimalist requirements: Display the on-hook dialed phone number on a numeric display, play call progress tones the user would find familiar from the landline user experience, and enable control over a small set of switch-based functions like call-waiting, where the call on the single radio channel to the phone is switched to a second call. It is familiar enough to be accepted by customers and accommodating enough to the way the network works to be efficiently deployed.

There are some differences between CDMA, GSM, iDEN, etc. but they are close enough to share a lot of the implementation. 2G, 2.5G, and 3G differ in the richness of the circuit switched signaling (but not so much that users are aware of it), and in whether and how much data you have. GSM and UMTS/WCDMA data and HSPA differ from CDMA data in detail, but, again, there's not much user awareness of the differences. Color LCD displays on phones make text messaging nicer, but the impact on the mobile phone call user experience has been limited to presenting a contact list and call log.

4G is the first fundamental break from the roughly 25 year old model of cellular mobile telephony. In 4G, the radio is part of a network interface on an IP network, like a WiFi radio. There are no bearer channels dedicated to voice calls. You either do IP telephony using SIP, in the IMS case, or you simulate circuit switched telephony on top of IP in the VoLGA case. There is no practical limit to the number of voice calls and other kinds of communication sessions a 4G device can juggle. Packets traversing the carrier's network carrying voice to other endpoints are no different from packets flowing between the endpoint and a third party or private gateway/switch with a telephone network interface. Identity, communications services, media (how voice or video is encoded), etc., all become decoupled from the network.

So we are entering a product development phase where the winners will be, in part, determined by how well they can make compelling new communications features and capabilities based on this change without confusing the end-user. What it means to be a phone is now infinitely malleable.

Surely, at the bottom of this a phone call has the same limitations as a face to face conversation plus the further limitations of not being actually face to face. No, even this can be called into question. The ability to redefine the phone call experience is comprehensive and the potential is limitless. And the potential ranges from the obvious – what the user sees on a screen – down to the subtlest microsecond-level manipulation of the human voice.

But will this potential be realized? That is more in doubt than that the potential exists. So far, the modern general purpose pocket-sized telecomputer surfs the Web and plays games. It will take the realization that new communications products can be created, and sold, to motivate reconsideration of how phones enable communication.

The One-page Guide to Google's Plan for Winning at Applications and Operating Systems

Google wants to enable Google applications to run as well as possible as many places as possible. Here is how:

Google applications: Web applications run in browsers, on all kinds of systems. No need to be installed or updated, and hard to block. Anyone with IE, Firefox, Safari, Opera, or, of course, Chrome has access to all the latest applications.

Gears: Web applications run in a sandbox and don't have much access to your system. Gears enables more access. Applications are still in a sandbox, but the Gears-enabled sandbox is bigger, and can persist. This frees Web applications from having to be connected all the time.

GWT: The Google Web Toolkit (GWT) is a radical abstraction of of the browser runtime environment. GWT applications are written in Java and compiled to JavaScript. The GWT library provides fixes for incompatibilities between browsers, as well as a rich UI library.

Chrome: Google's browser. Chrome provides the ideal browser runtime environment for Google applications. Fast JavaScript execution. Separate processes for each Web page.

Chrome Frame: Chrome Frame puts the Chrome browser inside Internet Explorer. This shows the lengths Google will go to in order to give Google applications the best possible runtime environment is as many situations as possible.

Android: Android is a Linux-based OS for mobile handsets and other devices. Android has exploded in popularity among handset manufacturers. This is Google's first win in computing platforms, and Google influences the software “stack” all the way down to the hardware. Android has a Webkit-derived browser.

Chrome OS: Chrome OS is meant for things larger than handsets. Chrome will be Google's attempt to bring a Linux-based OS and Web-based applications to netbooks and PCs.

Google's strategy is comprehensive: Control the software all the way down to the hardware where possible, and, if that isn't possible, be compatible, and maximize capabilities, on every possible platform.

Google's strategy is also technologically coherent: Java, Linux, Webkit, SQLite, Eclipse, and other common components are reused across multiple Google products and platforms. You can expect Google to contribute to and influence the development of these key ingredients. You can also see some design philosophy in common across Google products. For example, Android runs Java applications in multiple tasks, and Chrome runs Web pages/apps in multiple tasks to make these systems resilient to apps that crash.

While Google's applications, like Gmail, are proprietary, Android, Chrome, Gears, GWT and many other components of Google's strategy are open source software, many with permissive licensing that would not preclude competitors from using them. Open source builds confidence in Google's partners and in software developers using Google platforms.

Google's strategy has formed recently and moved quickly. It can be hard to perceive the impact. As fast as Google is implementing this strategy, you can expect a similarly fast emergence of an application ecosystem around Google's strategy. This will be one of the most significant developments in software in the coming years.

Smartphones, 4G, IP, and IMS – Part I: Toward a Fully Mobile Enterprise Communications System

I have not been blogging much lately, and I plan to change that. I am going to do that by writing a series of shorter blog entries.

There are four big forces for change in the mobile market now:

1. Smartphones have broken out of the PIM-oriented business niche
2. 4G networks, WiMAX and LTE, are coming to market
3. IP voice has taken over enterprise telephony
4. The ideas of IMS, if not implementations of IMS, are permeating new communications products

My next several blog entries will look at the interplay between these forces and the opportunities they open up: 4G, with or without full implementations of IMS, mixing IP communication with mobile communication, the way business communication systems are, finally, co-evolving with mobile communication, etc.

The reason I will be focusing on the interaction between these forces is that this is where new opportunities are created, and new entry portals into existing markets with entrenched vendors open up.

For example, most people think of VoIP phones in two distinct ways: VoIP applications for smartphones, which are mainly used for international toll-bypass, and VoIP desk phones for businesses.

What's the problem here? In each case, these products have reached some natural limitations: Mobile VoIP as toll bypass has hit an upper bound on value – it's not much more valuable than a calling card. And VoIP business phones are becoming the second phone – the place where you get cold calls, the thing you leave on do-not-disturb, the back-up.

Can we find a way out of these limitations in the four forces that are driving change? Let's see how each affects a possible solution:

1. The new smartphones and smartphone software platforms enable richer and more integrated mobile VoIP solutions than the crude Java ME (J2ME) applications for mobile VoIP. You can transform the handset into a mobile enterprise phone, and directly replace desk phones.
2. 4G networks enable enterprise communication to become an over-the-top (OTT) service. There is no longer any difference between being on-premises and off-premises.
3. Now that you can extend IP communication to users on the go, there is no longer a need for crude “two stage dialing” to “log in” to a PBX while you are on the go. It's an all-IP world.
4. An IP-PBX being used like an OTT telephone service is IMS-like in many of the features it delivers, but does not depend on IMS in the mobile network.

This is one kind of innovation made possible by the combination of these Four Forces. In future posts, I will explore more basic innovations, and the details of some of these innovations.

Denial is not a river in Russia, but VoLGA is

IMS has made some headway in network infrastructures in part because, if you have an all-IP network, as with cable or WiMAX, for example, IMS provides specs for two key parts of the network architecture:

• A secure carrier-grade signaling architecture based on SIP, an existing, widely used technology

• Interconnection and inter-operation with the worldwide telephone network.

Neither IMS's Vogon ambitions to make charge-able events out of Web site visits, nor the potentially creative aspects of SIP signaling in enabling novel communications features helped IMS. It was purely practical matters that brought implementations of SIP that happened to be IMS capable into the telephone network.

Will IMS therefore win by default?

The answer will emerge from the way LTE (a.k.a. 4G) networks are engineered. LTE is tipped to be the dominant all-IP mobile wireless network technology, and is therefore the big prize for IMS vendors. You can think of LTE (4G) as 3G without the circuit switched telephony. LTE is faster and simpler than 3G.

The question is: Can you build an all-IP LTE network without IMS? Unfortunately for those network infrastructure vendors with a big investment in IMS, the answer appears to be “Yes.”

VoLGA is a spec related to LTE that describes how to do circuit switched voice with an LTE generic access network (GAN), and how to hand off between an LTE VoLGA call and a 3G network and 3G call. By teaching the 3G GAN controller (GANC) node a few things about how VoLGA handsets want to do circuit-switched signaling over IP, and how to set up gateways for VoLGA calls, you do away with the need for a new kind of signaling for IP calls.

That is, VoLGA is a specialized form of IP telephony built to get signaling and payload between an LTE endpoint and a mobile switching center (MSC), which is connected to the conventional telephone network. From that point, the LTE network and the phone calls on it look like a 3G circuit switched mobile network.

VoLGA is, therefore, a dagger at the heart of IMS. A VoLGA handset doesn't need SIP, much less IMS, to make phone calls on an all-IP LTE network. And an LTE network doesn't need to support SIP and IMS to support LTE handsets that support VoLGA.

This is both good and bad:

It's good because it extends the attractive simplicity of LTE: Fewer, simpler nodes make LTE networks cheaper to build and operate and faster to deploy.

It's good because it does not preclude IP communications services in the handset. In fact, it raises the importance of IP in the handset because the network does not take on responsibility for mediating IP communication.

It's bad because it closes the window on operators' ability to create new service products based on IMS capabilities. Cynics might say this is a deservedly unused non-opportunity.

Nevertheless, it does make adding features like, for example, HD voice more challenging in that they will have to be done in the circuit switched signaling domain for LTE voice calls.

For handset makers, VoLGA marks a clear boundary: LTE handsets are mobile Internet nodes, for sure, but they are also endpoints of the conventional PLMN, with 3G signaling. The IP side, with the possible exception of some messaging services, belongs to the Internet. The VoLGA phone calls belong to the telephone network.

Handsets are, therefore, IP communications devices: They are on an IP network, and anything beyond conventional circuit switched calls is going to be IP communication, and it is not going to be mediated by IMS.

Networks will be simpler, leaving more responsibility and opportunity for endpoint devices: Functions depending on multiple IM/VoIM protocols, one-to-many messaging, presence from multiple services, etc. will not have the excuse that “the IMS system will eventually gateway that stuff.” It's up to the endpoint developer to make it happen.

And what do you do if you have already placed a significant bet on IMS? You take the intent of IMS: To make all modes of communication available to the user and inter-operating, and you implement that intent in an endpoint device that takes the new modes of IP communication and makes them first-class citizens of the handset user experience, and does that using not just an IMS service, but using the services the user may want to use on the Internet.

How a Customer's Question Frames the Definition of 'What Does a User Interface Architect Do?'

My title is Chief Architect, and the short description of what I do is that I designed the mCUE user interface and telephony middleware systems.

That's not a very satisfactory description for several reasons:

1. The product named mCUE is difficult to pin down: “Unified communications” and “middleware” are industry terms calculated to form meaning in the eye of the beholder.

2. When people hear “user interface” they think “draws pretty pictures”

3. The term “architect” is also nebulous – what is there to architect in a user interface? It's just presentation.

So, when asked, what can I say about the job I do? Recently, a customer's question brought the description of what I do in focus, and also helped clarify the nature of the product I designed. The question was:

How do you ensure consistency of customer experience from platform to platform?

The question was asked because we showed the customer our product in a very portable implementation that depends only on a reasonable Java VM and a small subset of the Java AWT classes, but they needed our product in an environment that requires use of that platform's UI classes and application framework. Why, in this new implementation, should they expect it to work like what they evaluated and liked?

That question gets right to the heart of what it means to design a mobile user experience, and, indeed, right to the heart of the whole project that I have been working on.

My work here started with discussions I had with D2 Technologies' founder David Wong, who is a pioneer in voice over IP technologies (VoIP) and DSP software, on the proposition that VoIP user interfaces were low-quality compared to mobile user interfaces, and that nobody had really thought about VoIP user interfaces the same way as mobile user interfaces.

That is, nobody had thought of VoIP user interfaces as a really important part of the product. VoIP users were fewer, and had fewer options than mobile users. VoIP users were generally enterprise users, accustomed to ill treatment by user-hostile software. VoIP user interface was immature because the resources applied to it were small, and the stakes in the market were correspondingly small. What if we took it seriously and put more mind-share and resources into it than our competitors? Could we make a breakthrough in VoIP user interface and, perhaps, ride that up the value hierarchy to a place among mobile handset technology providers, especially as they found they needed IMS endpoint technologies?

That is how the project that became the mCUE product started at D2 Technologies. It was about VoIP, but, specifically, about what we hoped would be the logical next step for VoIP endpoints: Instead of desk sets that tried to look like PBX phones, VoIP would logically be moving to mobile handset form factors and use WiFi to connect to VoIP systems.

That VoIP user interface market, however, proved to be too small even for a specialist company like D2: WiFi handsets are, still, a tiny fraction of VoIP endpoint market share, and desk sets are still saddled with crude user interfaces. Nor could we make an immediate jump to providing IMS endpoint technology. Only tier-1 OEMs were active in defining their IMS endpoint architectures, and these were mostly prototype efforts.

Nevertheless, we changed our design goals to aim at the intentions of IMS: To make every mode of communication a first-class citizen in the mobile endpoint. And, beyond that, we realized that IMS is not the be-all/end-all of mobile communication. We also made every service a user might want to use a first-class citizen alongside the mobile network. That is, we made IP communication in all modes and media able to either replace, as in a purely VoIP system, or stand alongside mobile service, without relying on an IMS network implementation to aggregate every conceivable IP communication service.

And that gets to the answer to our customer's question: How do we ensure consistency of customer experience from platform to platform? The answer is: we have to, otherwise we could not implement our goals. We must make a new “world” of communications objects that replaces the call-state management in a conventional mobile handset with a model of communication that encompasses all modes, all services, and all networks. And, if user interaction with this much-expanded communications model is consistent in all implementations, the user experience is consistent, no matter the UI toolkit we use to implement the presentation of the user experience.

So, what does an architect of mobile user interfaces do? He makes a model the user is comfortable manipulating, and presents that model in a consistent way across multiple platforms. This sounds a bit general, but aspects of this task are especially critical in mobile user interfaces: The mobile user interface is inherently a multimedia user interface – it used to be almost entirely presented as audible call progress tones and the billions of users of telephone systems worldwide have a strong expectation that the conventions of a telephony user interface and a mobile user interface will be preserved in an interface that brings in other modes of communication.

The mobile interface itself cannot be pulled in new directions very easily, yet assumptions have to be questioned: What, for example, can be done to enhance the task of starting a conversation? On-hook dialing was invented to keep the user off the precious resources of the mobile network until the last possible moment. Now that always-on data connectivity is inherent in VoIP networks and widely available in mobile networks, the “don't touch resources until you absolutely need to start signaling the network to connect a call” assumption is obsolete.

A mobile user interface designer not only makes the presentation of the user experience, he has to be able to design the model manipulated by the interface, and he has to know about the network, and even the business of operating the network, to make a presentation, a model, and a consistent set of functions that work together. And he has to know it all well enough to know the difference between a rule you have to observe and a rule you have to break in order to innovate.

This seems daunting. It is, at least one of the most interdisciplinary pursuits in software design. It is full of both constraints and opportunities. If you are unaware of the constraints you will make mistakes that make you look amateur. If you are unaware of the opportunities and what it takes to exploit them, you only advance by luck. The reward is that good work in mobile user interface design expands your mind the way few tasks can in the increasingly specialized world of software design.

Does PA Semi make sense now?

About a year has passed since, in 2008, Apple acquired PA Semi, a fabless CPU maker with some success selling a high performance, low power 64-bit PPC CPU in embedded systems, for $289 million.

To put that number in perspective, it is less than half what Intel got for its Xscale product when it sold that to Marvell in order to get out of the ARM CPU business.

Apple immediately withdrew commitment to PA Semi's road map and notified PA Semi's customers they should not consider their supply of chips assured. Apple's investor relations put the acquisition into the category of small-firm acquisitions Apple does not feel obligated to explain in detail. In other words “move along, nothing to see here.”

But, of course, there is plenty to want to see: Sun crippled themselves by keeping a CPU business alive too long. Apple shifted CPUs twice in desktop products, from 68k to PPC and finally accepting that nobody can compete with Intel in the high-stakes game of general-purpose CPUs. So what is this dalliance with CPU designers? Is Apple losing the hard-won focus Jobs fought to restore? Is Apple really going to use three different CPU architectures in its product line?

At the time of the acquisition, Intel's Atom had still not found a market: Too power hungry for mobile handsets. Microsoft's UMPC had flopped. And first attempts at netbooks were not a success. Now, however, both markets and technologies have sorted themselves out, and we can discern if this acquisition makes more sense.

PA Semi is a second act for a serially successful founder, Dan Dobberpuhl. Ex of Digital's Alpha and StrongARM projects and founder of SiByte, which was sold at a handsome price to Broadcom, PA Semi is solidly in the first tier of what is a remarkably vital if not very visible market of CPU vendors based on licensed architectures (and novel ones, too, mainly in the area of multicore systems), mainly sold into embedded systems.

That's an important bit of background because it highlights the fact that Apple did not necessarily buy PA Semi to launch a system with a PPC CPU. Dobberpuhl and his team would be as wizardly at making an ARM, MIPS, or even x86 CPU as they would using the PPC architecture. The likeliest target for Apple is to come up with a variant of the ARM architecture with unique performance advantages.

The market has also evolved: Atom is the basis for the success of netbooks. Apple is locked out of the low-cost netbook market because the price points and margins are even harsher than mainstream PC products. Linux has become slick enough to gain customer acceptance in netbooks. Windows 7 got a bit quicker. Android successfully launched despite lackluster hardware and T-Mobile USA's struggles to get out of the lower tier in the US market. More recently, Android looks likely to go up-market from smartphones into a tablet/netbook form factor.

Everyone is gunning for iPhone, and Web access on-the-go is creating new product categories. Apple needs to be able to create a winning product in the Web-pad/netbook categories, and it looks like the PA Semi acquisition will be part of providing Apple with a truly unique advantage where other players are buying their CPUs from Intel or TI, or from makers of mobile SoCs, like Qualcomm.

This is made plausible by the fact that this low-cost/low-power CPU market cannot be dominated by Intel's unique ability to spend mind-boggling sums on state of the art fabs. The model for this segment has been established and refined by ARM and its biggest licensees, like TI. Apple, therefore, does not risk falling into the same trap that chasing architectural advantage in desktop CPUs led to.

In this case, there is no trap, but an opportunity: There is a seam in the market that runs between Atom performance and ARM power-efficiency. It is a complex seam that isn't just about CPU architecture, but also about compilers, operating systems, peripherals, drivers, user interface and SDKs. And the seam is multidimensional: It is not just between Apple and Atom and Windows 7 on cheap netbooks, but Android and larger-than-smartphone devices as well, and with Linux, in the form of Moblin and Netbook Remix also looking to become a threat.

If Apple can give themselves a unique advantage in hardware, with a uniquely powerful ARM or other CPU architecture, sufficient to overcome the netbook price/margin barrier, Apple is uniquely well-placed to provide a continuum of software, from desktop to smartphone and all points in between. If they fail to do this, Apple will give up the potential to create as much value in the emerging Web-pad and netbook segments as they created with iPhone.

Organizing the Pantheon of Multimedia Communication

Recently I heard Garrison Keillor quote Joseph Campbell, in one of his essays on writing: “A computer is like an Old Testament god, with a lot of rules and no mercy.”

It doesn't help that the rules are rational and sanitary. No stoning. No beheading. Bacon is not a problem. Just cold opprobrium that is made even colder by the certainty that You Did Something Wrong.

Fixing this is the central task of user interface designers.

Clearly, then, it isn't good enough to enshrine the olde thunderbolt-slinger in a fancy temple < cough >smartphone< /cough >. That won't make him any easier to deal with. We have to reform the rules. More, we have to reform the language the rules are written in and the definitions of the nouns.

That is what initiatives like MMTel and RCS require, but, so far, are not getting from user interface designers. Your 2.5G phone is a simple minor deity with simple rules. Everyone understands the propitiations and few are therefore intimidated. But the pantheon is getting crowded with both the bureaucratic jinns of IMS, and the anarchic dryads of the Internet.

Messaging is now multimedia messaging. Email and IM bring two other rites of messaging. IM presence and social network updates make it a group event, along with your push-to-talk circle of initiates. And plain old voice conversations can travel over the righteous roads of the synchronous digital hierarchy or the twisted but beguiling paths of the Internet.

Putting all this in separate little shrines, with separate sets of rules and liturgies is bound to put us at risk of hellfire and damnation, and the use of Strong Language. Consequently, the people are divided into the zealous, who are undeterred by complexity and proudly wear their scourges in a belt pouch, and the agnostic, who are driven to indifference.

The successful interface to IMS-based capabilities will solve this problem. It will put all the media for communication under a single set of simple rules and inside of one interface – not a set of applications, but one unified application for communication, just as using the 2.5G voice network requires just one user interface.

The problem is one of levels of abstraction. How can you take protocols as divergent as SIP, XMPP, a few dozen proprietary IM systems, some with VoIP and/or voice chat, push-to-talk, video calls, email, social network update feeds, and circuit switched telephony and give the user one set of tools, one set of contact information, one history, one set of shortcuts, and one consistent set of verbs and nouns for manipulating these capabilities?

The radio interface layer, and user interface on top of it, that turns your key presses into phone calls in one direction, and state-changes reported from the radio baseband into indications of call progress in the other direction is not enough. But how do you keep it just as simple for the user?

The notion of a conversation has to evolve to encompass the new media of communication. Key objects: people, conversations, connections, addresses, services, identities, status, and presence have to be made simple enough for humans to manipulate through the same 12 keys and handful of other buttons, and their visual manifestations have to fit on screens small enough to keep discreetly in one's pocket.

And this is the hard part: We have to create a new world of communications objects that spans media, networks, and protocols, and we have to make the human customer instantly fluent in the language of these objects. This layer, consisting of many new protocols, access to many new services, and quite a few fundamentally new capabilities has to be inserted between the keypad and the radio without the user noticing that the amount of software in the system has gone from bottle-rocket to space shuttle in one step.

The zealous don't care: They are happy to stuff a computer into a belt-pouch. Multimedia communication is easy if the user is comfortable with multiple applications. But, to give multimedia communication mass appeal, the masses must be appealed to: The result, for them, must be that their phones do more, but don't ask more from them.