Is That a Data Subscription in Your Pocket, Or Are You Just Glad to See Me?

It's the dawning of the era of tablets. It's about 9:30 am for 3G, and daybreak for 4G mobile data connectivity. It's the evening of the era of overpriced WiFi franchises at airports. It's the mid morning of WiFi devices of all kinds, mobile and stationary. And, monthly, it's the arrival of the subscription bill for multiple family members' data subscriptions for multiple mobile data plans on multiple devices.


Multiple data plans are great for the network operators. Users have only one pair of hands, eyes, and ears, so users with multiple data plans are paying a multiple for one person's consumption of data. But, it can't last. Data, in general, is going to get cheaper, or it will stifle the spread of smartphones.

The well equipped mobile worker may have some combination of laptop, tablet, smartphone, game console, and e-book reader in his kit. A traveling family might be using one of each, rolling down the highway. Paying for a mobile data subscription for each device is unsustainable.

Currently, some carriers offer “tethering” plans enabling a smartphone to be used as a mobile data modem for a laptop. It costs extra (or it's a kludge that violates one's terms of servcie), and it does not solve the problem of consolidating one person's mobile data costs and uses across all devices, and under one price.

Mobile hotspots, like MiFi take one right up to the threshold of having this consolidation, with the very large exception of one's smartphone, which still requires its own mobile data subscription.

The ideal solution would put the mobile hotspot inside the smartphone, charging for one mobile data plan. It will be interesting to see just how willing carriers are to forego the revenue from two, or more, data plans a power user can bring.

4G carriers, like Clearwire, may see this problem from the opposite starting point: 4G networks will start out as purely mobile data networks, though there are both standardized and “over the top” (OTT) voice options for 4G carriers and third parties. 4G subscribers will either get “modem” devices for their laptops, or they will get mobile hotspot devices that can support multiple WiFi connected devices.

Voice and text message revenues are an incremental opportunity to these carriers. So, instead of putting the mobile hotspot into the smartphone, 4G carriers may, conceptually, put the phone into the mobile hotspot, creating handset-like smartphone devices that enable an OTT voice service. I say “handset-like” because these phones can do without the ability to make circuit switched calls. Telephony, on these devices, is just an application, not a radio (though they might throw in 2.5G mobile as a fall-back).

Instead of losing revenue through consolidation, 4G carriers pick up a bit of incremental revenue form marketing voice services, that can have advanced features like HD voice and video calls, on their network. The user gains both the true consolidation of data costs, and the convenience of having that packaged in a smartphone form factor that behaves just like a mobile phone for voice calls.

Zigurd's iPad Scorecard

Form factor [8.5]
It's a Web pad that meets expectations for Apple's industrial design reputation. The most notable thing is that, while it isn't the first one, Apple is among the pioneers, and not an aggressive follower. Apple beat all of the major OEMs to this market.

Price [8.5]
Apple priced iPad low enough to remove price as an objection, and even low enough to make potential competitors re-evaluate their Web/media-pad plans. Apple didn't leave a lot of room under their pricing for less-amazing products. Apple took the netbook price challenge seriously and has  a serious response in iPad.

Applications [9.8]
The app store ships about 400 new applications per day. Read that again. Now look at the top selling programming language books on Amazon. iPod Touch has evolved into a game and social media platform, as well as being the continuation of the iPod product line, and iPad inherits all of this. Apple announced two new application/content categories: e-books (and periodicals), and iWork. And it is the best Web pad yet devised.

Software [7.5]
It's a big iPhone. The software appears to be very well executed, and enables iWork and other new key applications. But it isn't a breakthrough. Not even a big “Wow” factor. There was a chance Apple would send Google's Android team back to the labs, but no put-away shots here.

Hardware [9.5]
People who have seen it firsthand all remark on the speed. Apple has entered the ARM CPU business at the front of the class. Success here is crucial to Apple beating netbook economics. However, Apple probably does not dominate this business, and you can bet that would-be competitors are looking at Qualcomm Snapdragon and other fast ARM CPU spec sheets this morning. Apple may find themselves at the front of a very competitive race.

A lot of software effort had to have gone into fully exploiting the GPU, and into other unseen system software, leaving less time for visible UI improvements.

Did Intel make the right move selling off XScale/StrongARM and going with Atom? What will it cost to make Atom competitive and keep it from cannibalizing high-end CPUs?

Ecosystem [10.0]
Apple has created and continues to exploit the best ecosystem in the business. When will Apple's would-be competitors, Nokia and Microsoft among them, learn they cannot succeed by copying a subset of Apple's ecosystem? Google has built their own very powerful ecosystem and can make their own rules. Everyone else needs to take this more seriously or face continued failed market entries. Legacy category dominance is not an ecosystem.

Reviving Windows Mobile: A Bigger Challenge Than Most People Think

Big companies fail at competitive analysis by making the challenges they face fit the framework of a normal project. Reviving Window Mobile is anything but a normal project. iPhone dominates the new generation of smartphones and Android has knocked Windows Mobile aside at many the top tier OEMs. Windows CE is not competitive with Linux as a mobile embedded OS, and the Window Mobile userland is stuck in the C++ era, despite having the C#/NETCF runtime available for years before Android was even an idea.

Colin Gibbs at GigaOm set out to list the ways Windows Mobile could get back in the game: http://gigaom.com/2010/01/13/how-microsoft-can-get-back-in-the-mobile-game/ But, for the reasons I listed above, it's going to take a lot more that . Let's look at the suggestions in the GigaOm article and see just how much more:

Make Windows Mobile free to manufacturers

Right off, we know this isn't enough. Google is giving carriers a slice of search revenue. Bing doesn't have enough revenue to share. Microsoft has to come up with a strategy to bring superior value to the carrier and OEM partners. Gibbs also says “Making WinMo free — but not open source...” But that isn't going to cut it with developers. There is no reason not to make Windows Mobile open source.

Acquire (or adopt) another operating system and ditch WinMo

Like Xerox, Bell Labs, IBM and other companies well-stocked with very smart people, but chronically unable to commercialize their output, Microsoft has more operating systems in their labs than it knows what to do with. More focus, and making the product management side of the business more compatible with the research groups would make some of those operating systems productizable. But if they start today, it will take two years to bring such a product to market. Microsoft better have a plan for the Windows Mobile kernel well under way or they won't have a result in a commercially relevant time.

Build a top-notch app store designed for business users

This will only make a difference if the apps are all C# apps for an upgraded runtime. And even such a remarkable change in the userland won't matter if Microsoft keeps the price of Visual Studio at $799 for mobile application developers. For that kind of money, buying a Mac to make iPhone software no longer seems like such a big hurdle. And the price to get into Android software development is $0.00.

Make Windows Mobile 7.0 a worthy competitor with a focus on the enterprise

That's a good suggestion, but it's a small suggestion. Better to aim at clearly identifiable value for the enterprise user: A secure connection to Office Communications Server, including for IP voice. A VPN in every handset. Data and voice security are serious, high-value issues. Microsoft can, and must in order to demonstrate high and unique value in Windows Mobile, make a big move in mobile data and voice security and in enterprise communications integration.

As Colin Gibbs says in the GigaOm article: “As we’ve said before, it may simply be too late for Windows Mobile to re-emerge as anything but a niche play for a small number of business users.” And that's what will happen if Microsoft views this as a normal project in a normal competitive environment. This isn't a new version of SQL Server. This determines whether Microsoft is in or out of mobile.

In addition to the above, Microsoft should be doing more:

Make the userland pure C#

Ditch the legacy applications. They don't matter. Google and Apple started from zero with applications. You can too. And in the end you will have to.

Use the power of OCS

Office Communications Server is revolutionizing corporate messaging and voice communication. Put it in every mobile handset. Provide a SAAS version for smaller businesses.

Don't let Apple take the handheld games business without a fight

You have in-house titles nobody but Sony can compare with. Why aren't these on your phones? Might I suggest Mobile Halo Wars?

Zune for media

Cannibalize Zune to add value in mobile. Every phone should be as good as Zune at playing media.

Buy Opera

If you can't make a better browser than Opera, buy Opera.

Don't complain about how much it will cost

How much did you spend on Danger? No excuses.

Is the MagicJack Femtocell For Real?

The answer is, probably, yes.

The most interesting announcement I saw in CES coverage was the MagicJack femtocell. It's one of those products that is brilliant technically, and a brilliant and audacious business idea.

What the MagicJack femtocell does is: It enables your mobile phone to connect to the MagicJack VoIP phone service as if it were connecting to your mobile service provider's femotocell. This is far better than using a SIP client application on a smartphone. First, you don't need a smartphone, which is incompatible with the budgets of many of MagicJack's customers. And it just works. Your phone will display a network name indicating you are connected to MagicJack and that's it. No added software in the phone.

Well, that sounds simple enough, but it is enormously disruptive: MagicJack just jacked your mobile carrier's subsidized handset, and a slice of GSM bandwidth, and used them to to connect to their $20 per year VoIP phone service. And it should work as smoothly as using your carrier's femtocell. And it is cheaper than your carrier's femtocell.

How is this all possible? Once you start to look at it, it begins to look unlikely:

1. Femtocells are not cheap. A 3G radio. A GPS receiver. A router. Considerable amounts of software. Integration with your mobile carrier's operating software (so you don't stray into areas where they do not own bandwidth licenses). Etc.
2. Femtocells take big-company resources to develop: Huawei and Alcatel Lucent, to name a couple early entrants to the market, spent tens of millions each on femtocell development. MagicJack's total revenues amount to tens of millions.
3. Femtocells are not easy: How did MagicJack take a femtocell, make all the modifications needed to connect it to their VoIP network, test it, and ship it? MagicJack is a relatively large VoIP operator, but companies like MagicJack, which has been slammed by some for having clunky, adware-filled software for their VoIP dongle don't suddenly become past master at femtocells, ripping out their MSC-connected software guts and replacing them with what can be described as a Very Fine Hack.

And yet, that is what they claim to be demonstrating.

If they are doing this, it has to be made of off-the-shelf parts. Integrating a system like what they claim to have is hard enough. Let's put aside the idea that they did school everyone at what you can do with femotocell firmware and see if there is a path of least resistance to what they claim to have.

First, the femtocell itself: I believe MagicJack must be using a 2G femtocell. This makes sense because they have no need to be your mobile ISP. No requirement for 3G data. This is for VoIP calls, and, if you are home, you, and your smartphone, if you have one, can connect to your WiFi network.

Second, the software: MagicJack's requirements seem unique. Who would make something that would connect a femtocell to a VoIP system? The answer to that question, as with many fine cheap telephony hacks, is in developing markets. Who would substitute an Asterisk server for a proper MSC? A rural telco in the developing world is who. And here is one supplier of just such a system: http://www.go2callsoftware.com In fact, Go2Call Software seems to be a perfect fit for what MagicJack is doing: Femtocell to VoIP.

Does this make it any less amazing? Not really. It is still one of those brilliant and audacious ideas you find you are rooting for. It takes cross-functional thinking – skillful “intellectual trespassing” - to figure out something as, well, devious, as this.

Hardware, check. Software, check. Now for the audacity of it all. Is it kosher, or even remotely legal, to operate a 2G femtocell without a network operator's permission? Is it legal to sell femtocells if you don't own spectrum licenses? This is the part that remains to be seen. But I hope it is. Disruption and change bring opportunity.

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.

Buying a Cow, Just For the Hell of It

Nokia bought Trolltech. Unlike most cases where a Brobdingnagian company buys a much smaller company, there is a reasonable chance this won't become the typical sort of tragedy. Still, you have to ask, how much sense does this make? Nokia, it appears, bought a small cow when they could easily have continued to go to the store for milk.

If you stand back and squint a bit, it sort of makes sense: Nokia is the world's largest vertically integrated hardware and software platform company, but Nokia has had an undistinguished history with development tools. Trolltech's dual-licensed Qt is a key element of application development for KDE, the K Desktop Environment. Qt is also cross-platform, and Trolltech makes most of their money from being the world leader in cross-platform SDKs. Therefore it makes sense.

But there are numerous loose ends: Trolltech has been trying to penetrate the mobile software space with both internal development and acquisitions. While this isn't a large part of Trolltech's revenues, it is a very visible part of Trolltech's strategy prior to being acquired by Nokia.

From Trolltech's point of view, it makes a great deal of sense in terms of their mobile initiatives, or in any terms. Nokia is often referred to as “Tier Zero” of the mobile industry, and having the one company that represents 40% of the mobile market take you out is a win no matter what angle you view it from. Nokia has publicly stated Trolltech will continue to develop their PC oriented products. Trolltechs's customers will continue to buy them without worrying about competitive issues. Nokia isn't a significant player in PC applications, and with the possible exception of the small market segment for desktop sync software, the acquisition will create no competitive issues for PC software developers.

But what about VoIP and mobile handset makers? Trolltech's “Qt everywhere” initiative looks to become “Qt 40% of everywhere instead of the less than 1% of everywhere we were previously able to attain.” A win for Trolltech but decidedly precarious for existing mobile-oriented customers.

There is a minor muddle in MIDs, too, as Maemo will continue to be GTK-based, and other MID platform makers will find Nokia a plausible competitor, but that is all as hypothetical as the MID market itself.

The larger problem is among Trolltech's customers in the mobile handset market, e.g. Motorola, and in the VoIP market. Nokia's close relationship with Cisco puts Nokia's dual mode business handsets in competition with other VoIP endpoint devices, even desk phones, and some of those manufacturers are Trolltech customers. A small, perhaps unnoticeable, and certainly financially insignificant problem for Nokia, but a fairly big deal seen from the other side of the table.

Motorola has already unequivocally stated they will switch to GTK, after using Qtopia in all their Linux-based handsets. But that just addresses embedded graphics, and Trolltech has been trying to do a lot more than embedded graphics: The Greenphone suite, Qtopia Phone Edition, and their recent acquisition of Fonav have all been put in the shade by Nokia, which doesn't really need any of these, nor do they need to enable competitors. The future of these products was omitted from an otherwise upbeat and full-steam-ahead conference call announcing the acquisition. Probably no danger and considerable opportunity for the engineers working on these products, as they and their products get absorbed into the Mother Ship. Customers, not so much.

So, while buying a cow is a minor folly for Nokia, and a boon for customers of Qt for desktop application development, it is a serious competitive issue for anyone using Trolltech products in mobile and VoIP devices, including such highly visible products as Motorola handsets and the Sony Mylo. Trolltech had not yet come close to a combined mobile/VoIP solution, and that now may never happen, with Nokia preferring that S60 lead the way in IMS and dual-mode capabilities.

Annual Report

Lately, I have not been blogging about my work. I have been working on an unannounced product and I would have had to omit too much about my work to make blogging about it worthwhile. Now that the product has been announced, I can say a few things about my work over the past year. And, since I just got back from China, it is fitting I should give a report of my work around the time of the Chinese New Year.

The communications user interface

I have been making a communications user interface for mobile handsets. That's kind of the software equivalent of working on rocket fuel: Lot's of fun, but everyone else who tried has blown themselves to bits.

The art of the possible

In addition to being fun, I think it's possible. Even profitable. Sometimes it didn't look that way, but Google has broken down some barriers with Android. So, if you are careful about how you are doing it, getting a new mobile user interface into the market is possible now.

The discipline of working with a small team at a small company that is massively outweighed in resources by our competitors means you have to focus. Nokia, Microsoft, Qualcomm, or half a dozen others could put 20 times as many engineers and designers on a similar project.

One thing that makes my project viable is that most other makers of handset software think communicating is a solved problem. They have moved on to music, or games, or cameras, or digital TV. Previously they turned the phone into a personal organizer, realized that PDAs are a dead species, and have ever since been fishing around for the next compelling add-on to the task of communicating.

Meanwhile, I set out to make communicating on a mobile device work better. Has the industry gone bonkers and left innovating in the central purpose of a handset to little D2 Technologies by default? Possibly, possibly...

The other reason making handset software is no longer a big-company pursuit is that the whole handset business is undergoing a shift from a vertically integrated model that resembles the old minicomputer and mainframe model in the computer business to one that is made of horizontal layers of interchangeable technology components at the lower layers and software at the upper layers that is portable across the underlying hardware.

How market openings happen

There are two factors that explain how a market opening in communications user interfaces was left to a small company known mainly for high-quality DSP and soft-DSP software: IMS, and dual-mode handsets with WiFi and mobile radios.. IMS was supposed to provide all the answers for how IP communication and mobile communication would work side-by-side. It won't.

IMS does a lot, including bringing IP voice to mobile handsets. The trouble is that it simultaneously does too much and too little: IMS requires a wide-ranging and expensive upgrade of infrastructure nodes. IMS also duplicates a lot of what people are already doing using Web browsers and AJAX applications. But IMS does not cover every way that an end-user wants to communicate, unless the carrier that user subscribes to enables those ways of communicating. The central goal of IMS isn't about choice and capability – it is about control and the ability to put up toll-gates.

And it gets worse. You can't say that IMS is a conspiracy of the telecom industry to control the user. The telecom industry itself is divided about IMS: Network operators suspect it is a conspiracy by equipment makers to sell them an expensive bundle of upgrades. And yet, IMS slowly grinds forward, propelled by the standards-driven way that progress happens in the telecom industry.

So, what will really happen?

If IMS were a failure, it would be irrelevant. IMS will get deployed. Handsets will have to be able to use IMS features, or rather IMS will start to appear in carriers' specifications for new handsets. But the check-box on the requirements won't be the only thing driving IMS capability in handsets. IMS is an important conceptual framework for thinking about what users will want to do with handsets. That is, the best way to think of IMS is to deconstruct it, identify the key use cases and functional requirements of each component, and refactor these components into a user interface that can manipulate IMS functionality, plus all the other useful ways to mix IP and circuit-switched communications.

Users will mix and match communications services to get what they want, whether that is a a mix of in-house PBX and messaging services and the mobile network for enterprise users, or a mix of Yahoo (or MSN, or AOL...) IM, fixed-line replacement VoIP, and SMS, and, no doubt, many other ingredients for consumers. The WiFi radio is the Internet camel under the mobile carriers' tents. IMS was supposed to make the Internet “safe” for mobile carriers, but IMS is late to the game and dual-mode handsets are proliferating and exposing mobile customers to Internet freedom.

IMS could do all the things corporate and consumer users need. But it won't. IMS will not be connected to every corporate messaging system. IMS will not allow consumers to drive around the toll-gates to get to their favorite Web sites, and it won't have gateways to services that have not made a deal with the carrier. The intent of IMS is correct, and the functional requirements it imposes on the communications user interface are correct – just not general enough, and too much in service of the toll booth operator.

A multi-service world

Every service, every mode of communication, with multiple simultaneous sessions, delivered through a “push-to-X” presence-oriented user interface. That's what the multi-service future requires. It is also what IMS requires. Real users will want to make communications “mash-ups” that replace line appearances with presence in PBX call control operations. Or they will want to check your availability on GoogleTalk IM before calling you on a mobile network. The combinations are infinite, and unforeseeable.

Providing a user interface for this kind of communications was an unsolved problem. Current mobile user interfaces rely on the circuit-switched nature of the public land mobile network: One bearer channel to the handset means one real time session and, perhaps, some store and forward messaging events or missed calls the user needs to be notified of. These interfaces may be highly polished over decades of product development. But they are fundamentally insufficient for a communications environment where the user is juggling a couple real time calls on a VoIP network that does not limit the bearer channels to the endpoint, some push-to-talk interactions, upwards of a dozen IM conversations, some Web document-sharing sessions, and making decisions on who they can contact via what medium based on multiple sources of presence and status information

Put another way, nobody has rolled up all the point solutions for presence, IM, push-to-talk, etc. into a unified approach and an interface that operates on all these objects with generic verbs. Or, to take that from the API designer's point of view, nobody has funneled all the call flow state transitions for all the circuit switched and IP protocols through a single middleware layer and single user interface's call state-machine.

A better handset, or a smaller PC?

Personal computers manage this kind of communications environment pretty well: You can install every IM system your friends use, and you can fairly conveniently manage multiple sources of presence information simply by having multiple windows on your screen. That's because a PC is a general-purpose tool. It communicates and plays games and composes documents and, in addition to its general purpose functions, is also the basis of thousands of specialized knowledge-work tools, such as software development, CAD, media production, etc. PCs do a great job of enabling every user to have their preferred mix of tools, communication, and media at hand.

A phone, however, is not like that. The legacy smartphone “shrunken-PC” approach to mobile applications is a dead end. If you want a dozen ways to communicate, you need to build those ways of communicating into the user interface of your communications device. A dozen separate applications, as you might have on a PC, overwhelms the ability of the device to display information, and the user to manage multiple activities. Separate communications applications on a handset are as counterproductive as having a separate spell-checker and graphing applications from your office productivity suite – anachronistic and unfriendly. This is why a new look at the communications user interface is now necessary.

mCUE

And that is what I have been working on. It's called mCUE, for mobile Communications User Experience. mCUE implements IMS requirements for communications interactions for the most commonly used modes of communication. It rides on top of a middleware system, called ISI, which abstracts the differences between communications services and which provides a flow of events from these services and a set of operations on these services that enables mCUE to have a uniform interface to things as diverse as FMI/VCC servers, Internet IM servers, mobile circuit switched services, SIP and h.323 IP PBXs, etc. ISI future-proofs mCUE – you can add new services without modifying the user interface software.

What was the question?

One of the reasons I think I'm doing something more useful than quixotic is that mCUE actually answers a commercially important question: What do you do with dual mode handsets other than surf the Web?

The Nokia E-series of “business-oriented” phones, and many of the N-series phones are already dual mode. The iPhone is dual mode. RIM's Blackberry has added WiFi. Numerous models of phones running Windows Mobile are dual-mode. And yet, nearly all of the bits sent over the WiFi radio are Web bits. The Nokia E-series have SIP and IP voice codecs built in, and God bless you if you can configure them to work with a SIP service.

Ironically, for a communications device, the greatest impact has been on data. Mobile data is now just like data on your PC. Web browsers have killed the concept of “mobile search” as a distinct product category from Internet search. But the conventions of mobile voice and text communication are unaltered and unadapted.

Compelling use cases

The most gratifying aspect of working on a new communications user interface is to see one's theories about use cases come to life. 18 months ago I wrote out a narrative about how communication has escaped the hierarchy that bred the features of the enterprise PBX: Even CEOs answer their own phones. Important calls go directly to mobile phones. Instant messaging is how you ask if someone has time for a call. Voicemail has gone from a convenience to a curse. At CES in January of 2008, I added my personal GoogleTalk account to the demo accounts on my mCUE-powered handset. I IM'ed a friend at his desk in Massachusetts. I asked if he wanted to try talking to me on my new mobile user interface and, a press of the green “call” button later I was speaking to him through his laptop's speaker and mic, clear as a bell. And, had he not been on a service that has real time voice capability, the press of the green button would have chosen his mobile number instead.

The magic of that moment was in the normalcy of my interaction with the handset: In addition to contacts, I saw the presence status of every person with whom I shared an IM service. I could transition from IM'ing to talking so easily that it instantly made calling from a normal phone feel like a shot in the dark, likely to land me in voicemail purgatory. “I really want this!” I thought. Which is a darn sight better than the typical feeling of “I hope the customer puts up with this until compelling use cases emerge and we can fix it in a point release.”

And that is why I feel very fortunate to be working on this stuff. The abstract notion that multi-service communication is useful outside the technology framework of IMS looks to be true. It is, in fact, worthwhile to create a mobile UI that combines all these modes of communication while retaining the obviousness of the best mobile UIs. Communication can be improved without burdening the user with a learning curve.

Yo mama is a PDA

What is a smartphone?

Frequently, the question comes up “What is a smartphone?” Usually, this question is mixed up with other questions like “What makes a good phone UI?” and “Why don't all phones use a smartphone OS like Windows Mobile?”

The confusion comes from the fact there are “good” or “nice” UIs that can be classified as smartphones, like iPhone, and clumsier UIs that are clearly in the smartphone category, but that are hung up on a design legacy that prevents them being competitive with products like iPhone. Are they all smartphones? Do we need more categories? What about the Linux-based 3G phones in Japan? What about Android?

The PDA design legacy

The idea that handheld devices need an operating system emerged long before mobile handsets became the dominant handheld device. It emerged before one could expect all devices to include a wireless network. It emerged before Web browsing and Web applications became central to handheld device use cases. It emerged before we had a choice between a circuit switched voice network and packet switched data networks. It emerged before the disaggregation of communications services and network access.

Handheld device operating systems originated with PDAs. There are several problems that arise from this design legacy: PDAs started out as non-network-connected “sideloading” sync-oriented devices for carrying your contact list and schedule around with you. Was that even a good idea to begin with? Evidence is, no: The worldwide market for PDAs is less than one tenth of one percent of the mobile handset market. But, like some string of selfish DNA with a will to survive, PDA operating systems began to infect mobile phones.

An awkward relationship

This was never a satisfactory combination: PDA phones were heavy, expensive and sucked batteries. Some PDA users were happy with the ability to keep a large contact list and a synchronized schedule with them, but folding up Microsoft Outlook and putting it in your pocket is not a goal for most people.

The smartphone has had a long, slow growth trend in the market. Only three smartphone OS suppliers remain, one of which is on life-support, one of which can afford products that don't turn a profit for many years, and one which has as their almost-sole customer the largest handset maker in the business

The new need for a better phone OS

We are now long-separated from PDA use cases as key drivers of handheld device UI design. Multimedia, the Web, and a diverse combination of IP and mobile communication on multiple networks, using multiple services now drives the requirements for handset user interfaces. This is why old school smartphone OSs are facing new competition: It was easier for Google to make Android than it would have been to turn Palm OS, or Symbian and UIQ, into a platform that meets Google's requirements for a mobile device OS.

The new requirements:

• An OS that is non-exclusive, cheap to license, and adaptable on my schedule, not the OS vendor's.
• An OS that brings the Web front and center in the user experience. The “mobile Web” is a crock. Everyone wants the real Web.
• An OS that is undemanding of the user: Direct manipulation, touch connected to action, no multi-step operations, no “dialog boxes” - communication is not like filling out forms. In other words, it can't be harder to use than a non-smartphone, and it can't be less intuitive than a media player's UI.
• An OS that accommodates new forms of communication while retaining the simplicity of the mobile phone. Access to all of our modes of communication, all of our networks, and all of our services are converging into one device. The next phone UI should not make this a burden on the user, but a benefit to the user.
• An OS that makes presence central to the user experience. The “start page” of your phone should tell you about your contacts' availability.
• An OS that makes non-verbal communication a first-class citizen in the user experience. All forms of messaging should be treated uniformly, and a single interface should organize all messages.

None of these top requirements existed when PDAs were designed. Your to-do-list is not the most important thing for your mobile device to display. Your calendar is important, but it isn't central to communications tasks.

It is also worth noting that no mobile device meets all these requirements, especially not the communications-oriented requirements. The PDA heritage is being discarded, but what will take it's place? This is, as yet, unclear.

The new wave of smart device operating systems

Symbian (plus UIQ or S60), Palm, and Windows Mobile are the old-timers of mobile device operating systems, and the reason they are under attack from a new wave is that they cannot shake off their PDA heritage. Nokia is making the best of it by putting Symbian on some very capable hardware. But if you want to know why Nokia's amazing phones are not challenging the iPod, Symbian and S60 are the prime suspects. You simply can't build a user experience that is competitive with iPod using a platform born from a PDA (Yo mama!).

So what do we call the new arrivals? Android, the newest arrival, puts the question into focus. Android does away with most of the clutter of the PDA-style interface in favor of a friendly application “dock.” Sure, you could build a busy, multi-tab, form-filling-centric application in Android, but that's not what Google has done. Android's map application is full-screen, clutter-free, and all about direct manipulation. So is Android a “smartphone?”

I, for one, welcome our new Android overlords

I would venture to say that Android's creators hope it isn't thought of by end-users as a smartphone OS, even though it is targeted to the same big-screen hardware platforms as Windows Mobile. Android is for everyone who wants to surf and search on the go, not type-A email addicts who need to check their to-do list every time they glance at their phone. If you have the goal of building a better communications tool for everyone, don't look in a businessman's hip-pouch. You won't find it there any more than you would find inspiration for any consumer mass-market product there.

Is Indiana close to Nirvana?

If I can install Debian I can install Solaris

Earlier, I explored what the world would be like if I were the Sun King: In short, Solaris would rival Ubuntu for the role of desktop open software operating system, and Sun would be back in the game in desktop computing.

With Project Indiana, Sun has brought itself within reach of that goal. Project Indiana is what happens when you give the task of creating a Solaris distribution to one of the founders of Debian: A customer-friendly experience with Ubuntu/RHD-like ease of installation and maintenance. Ubuntu still rules the desktop ease of installation rankings, but getting Solaris on your machine is no longer “daunting” - merely not as bulletproof as Ubuntu.

Now that a Sun OS is within the grasp of mere mortals, or merely those who would rather not spend an afternoon screwing with an unfriendly installer, what next?

The boundaries of the Sun King's domain

What does Sun bring to the desktop? What should Sun want to bring to the desktop? A reasonable straw man for Sun's goals can be summed up as “If I intend to do some Java coding, I should want to use Sun's distro for that purpose.” That's not taking over the world, but it's a good start at taking over a large number of the opinion leaders in open source desktop OSs.

What are the ingredients of a killer Java developer's distro? To sum it up: a dose of realism and a dash of Sun's vision:

• It will have to acknowledge that Eclipse and Apache are key elements of many Java projects.

• It should project a vision of Java development that Sun wants to see happen: NetBeans and GlassFish, both of which are very worthy competitors.

• It should provide examples of Java in action: The desktop should be a Java desktop, and applications running on Glassfish should ship with Solaris, along with client applications written in Java/Swing.

• It should show contributions from Java technology to FOSS software development needs, such as using NetBeans to edit and debug mainstream FOSS applications written in C.

What makes a modern desktop

Linux is a rapidly growing choice for the desktop because it is a blank slate: Your choice of Gnome, KDE, Enlightenment, etc. for desktops, and a wide choice of applications in a staggering number of application categories on a system that gets out of your way to let you customize. Sun should aim off to one side of Linux. Solaris should become the OS X of open source distributions: It should be clean, uncluttered, and preconfigured. It should target current-generation desktop PCs to the possible exclusion of low-spec hardware. It should be great looking and more than a little sexy.

Seduction

Sun's near-term goal should be to seduce the opinion leaders in open source software. That will require give and take, and it will require understanding that audience. Sun's own employees should be a good pool of open source opinion leaders, and tapping that resource is largely a matter of Sun taking an unequivocal position on its own goals and intentions in open source.

Another Week in Beijing

Monday

Clear skies and California-like weather make Monday an unusual day in Beijing. Young women carry umbrellas for shade. Beijing is hot in the summer, cold in the winter, but this week starts with sunshine and pleasant temperatures.

The crush of numbers in Beijing is immediately obvious. Millions of people on their way to work. Packed buses, nose to tail, occupy a quarter of the road space. Taxis make up most of the rest. From my hotel room on the 18th floor I could see the frequent arrival of the elevated train bringing even more people into Beijing. There must be regulation of when delivery trucks are allowed to operate, since very few are visible.

Most of the commuters of Beijing are on their way to office or service jobs. Dress is informal, but not shabby. Neither is it stylish. About one out of 100 women wear something with real style, and some anti-style is evident in the form of flesh toned ankle socks worn to get maximum mileage out of the very flimsy-looking shoes most women are wearing. Men wear short sleeved shirts, unremarkable trousers, cheap shoes. Beijing is not about the clothes, perhaps due to the harsh climate.


Street life and food

One measure of China's emergence from ideological control over the minutia of life is the vibrant street life of a city like Beijing. Apartments are small, and life is lived out in the city. Middle aged women play cards on folding tables on the sidewalk. Emotive players bang the pieces of a Chinese chess game on boards resting on deliverymen's tricycles parked on apartment forecourts. Shirtless construction workers escape their pre-fab metal dormitories to sit in the shade of a tree on the street. There is a wide range of “normal” behavior on the street. Police do not break up the card game just because it is on a busy sidewalk.

Restaurants line the main boulevards, their shopfronts protruding from office buildings, brightly painted, festooned with lanterns. Many of the restaurants have large windows, and you can see the crowd (or lack of it) inside.

Young couples, many probably from nearby universities, and larger groups of work colleagues make up most of the crowd where I ate. The operation is large-scale, with about 200 boistrous diners seated, served by a wait staff that takes order and delivers food as it is ready, checking off their delivery against a carbon copy of the order left at the table. 600ml bottles of beer are delivered to the table in wooden totes.

Competition among restaurants must be fierce: New restaurants, closed restaurants, and restaurants under renovation are all in evidence. The ingredients and preparation at the restaurant I describe here are top quality: Green beans of the same not undercooked yet not mushy texture that really good French bistros achieve. “Streaky pork” with perfect taste, texture, and temperature throughout a thick slab of what amounts to fat fried in fat. It could have been a greasy mess, but the thin slices held together just right, and tasted something like bacon made by angels.

The food is not innovative. Everything on this menu appears on similar menus in hundreds, perhaps thousands, of other restaurants in Beijing. But, like traditional restaurants in Europe, correct execution of the local food idiom is life or death for an establishment, so quality is consistently high, even when operating at a frantic pace. For a foreigner, it's an amazing treat to experience food preparation that is so honed to perfection.

It is even more amazing to ponder the fact that the food culture and street life of Beijing have developed to the present scale only since liberalization began. Hundreds of years of tradition sprang back, ready to serve millions of meals every night, as if never interrupted.


Scale and density

China is on a wild ride of urbanization, economic growth, liberalization, demographic shift, and international influence. Scale and density make each element of China's transformation more intense, and potentially more calamitous if it goes wrong, than anything that happens in the U.S. or Europe. Density has benefits in that Chinese cities have the critical mass for vibrant street life that is hard to achieve in the U.S. In Beijing, even far from the city center, the city is a dense mix of offices, residences, restaurants, and shops.

Density and scale are also challenges in themselves. It is remarkable that the sea of humanity sloshing around Beijing's rush hour all have workplaces to get to and jobs to do – many of them apparently office jobs, in a country that is perceived as being all about manufacturing. The fact that what are, in local terms, middle class jobs and living arrangements, have been scaled up so quickly, is an optimistic sign.

Beijing is not merely a government town. The local economy outweighs the government in a sharp contrast with Washington D.C. While there must be the Chinese equivalent of beltway bandits among the office buildings of Beijing, they are not so obvious as they are around D.C., where businesses that sell to the private-sector look out of place among the government and its numerous camp followers and outfitters.


Brown again

By Wednesday, Bejing has gone from mostly sunny and a little brown and hazy in the distance, to the typical cut-it-with-a-knife Beijing smog. It will take a heroic effort to keep the 16 days of Olympic games, a year from now, clear enough not to cement Bejing's reputation for smog. China starts up new coal-fired power plants about as often as Starbucks opens a coffee shop.

China is living through a series of inflection points, each with am amplitude five times larger than what would happen in Europe or the U.S. Thus far, China has managed the ride with impressive balance and results that are worth going to see in person.

Because the perception of China in the rest of the world is behind the times, the Olympics are likely to be quite an education for the people watching on TV. They will see amazing achievements of development, and they will see normalcy in the lives of Chinese people. Hopefully they will understand the importance of China not in terms of trade surplus or diplomacy, but in terms of hundreds of millions of people emerging into the modern world – a feat that some held was impossible, and some still deny can continue.

iPhone: Analyzing the Industry Reaction

Toss a pebble into a pond and watch the ripples. In the case of the iPhone, it's more like a grenade was tossed into the pond full of typical telecom industry punditry. All species of industry assumptions are now floating on their sides, stunned, on the surface of the pond. Let's fillet some and see what's inside:

Don't say it's the new iPod
The principal mistake made in analyzing the iPhone is the being phone-centric. In fact, the iPhone is the new iPod. It is the video iPod. It is the new iPod user interface. It is the WiFi iPod. It is the first of many new iPods, some of which won't be mobile phones. If you had been thinking “How many people really want a $600 phone from Apple?” think again: Apple didn't sell 500,000 to perhaps 700,000 phones in the first weekend. They sold that many high-end iPods, too. This is the factor missing from most projections that will enable Apple to safely make their numbers for the iPhone.

Telecom industry people will have to learn to look at the iPhone as an iPod first. They don't look at the Nokia N95 as a video camera. Nor do they look at a Blackberry as a PDA. This is something entirely new, and it will affect the way future iPhones are formulated.

3G has value
Some regret has been expressed over iPhone not having 3G. The real reason for the tut-tutting about no 3G in the iPhone is that the telecom industry was hoping iPhone would be 3G's killer app. The reality is the mobile data network is a backstop to WiFi until speeds are up and pricing is down. It is possible the gap will never be closed. 3G has limited value and significant down-side in higher hardware cost and lower battery life.

Some iPhone customers, mostly pundits that don't see their phone bill, have griped about lack of 3G. But more than balancing that out has been buzz about how to use an iPhone with a cheap prepaid account, or no mobile account at all.

Where is 3G in Apple's priority list? It's below taking the iPhone down-market, so raising costs by adding 3G, except at the top of the model range, is not likely to be part of the plan.

Carrier-driven product management works
iPhone was defined within Apple, with the goal in mind of transferring Apple's success in media players to the mobile phone market. It wasn't designed for the existing network. It wasn't designed for a carrier's ARPU strategy. It wasn't designed to provide a delivery vehicle for a new section of the walled garden. iPhone was subject to none of the industry influences that go into “normal” phones. And yet the iPhone is a huge boon to AT&T, with half of iPhone customers switching to AT&T. Will other carriers, especially second tier carriers that don't have the resources to do more than follow the lead of first tier carriers' mobile commerce and data strategies, add more products that are not defined by their internal product management initiatives? Probably not! But they should consider that the more they tighten their grip, the more churned customers slip through their fingers.

It competes against smartphones
Name a smartphone product that could sell 700,000 units at launch. How many of Apple's 700,000 first-weekend customers compared iPhone against a smartphone? Still, many futile efforts will now be launched to turn smartphones into iKlones. Now you know how to spot the next set of industry train wrecks. Ironically, Nokia, which has the best chance of actually making a competitor to iPhone is probably trapped by the fact the S60 UI is the best among smartphone UIs, when abandoning the smartphone UI is the only way to really compete with iPhone.

The rumors of a Microsoft “Zune Phone” would be credible and welcomed, if only Zune hadn't flopped badly enough to damage anything called a Zune Phone. A Zune Phone would break from the smartphone mold and it would actually be a good idea to make one. Or, for that matter, to put MSN Messenger into a Zune, with a Zune-ish UI. Anyone willing to put away the PDA heritage in the museum where it belongs has a good chance of success.

All bow before mobile unit volume
One reason why mobile telephony is so fascinating is the amazing volume of phones being sold. A billion per year and growing, and not all developed-world markets are saturated. This makes phones, and the components that go into phones – the systems-on-a-chip, or SoCs – the most important computing devices today.

Because of the volume of mobile phones being sold, it was assumed that when mobile phones started to incorporate music players it would spell the end of standalone music players. What follows from this prediction is that iPhone is a defensive product – a shift to the winning mobile platform and away from a standalone iPod.

But, while everyone else still must bow before mobile unit volume, Apple now sells enough iPods that mobile unit volume cannot overwhelm the iPod. Apple isn't making an iPhone as a defensive measure. In fact, Apple has flipped this around to where Apple is selling phones because they are part of a new-generation iPod.

The game will really be on when iChat is added to the mix. Then Apple will be adding new modes of communication and new communications applications to their phone products.