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.
Thursday, January 28, 2010
Zigurd's iPad Scorecard
Monday, January 18, 2010
Reviving Windows Mobile: A Bigger Challenge Than Most People Think
Friday, January 08, 2010
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:
- 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.
- 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.
- 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.
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.
Saturday, November 07, 2009
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.
Sunday, November 01, 2009
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.
Thursday, October 08, 2009
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.
Sunday, October 04, 2009
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:
- Smartphones have broken out of the PIM-oriented business niche
- 4G networks, WiMAX and LTE, are coming to market
- IP voice has taken over enterprise telephony
- 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:
- 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.
- 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.
- 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.
- 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.
Tuesday, May 26, 2009
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.
Monday, May 18, 2009
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:
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.
When people hear “user interface” they think “draws pretty pictures”
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.
Monday, May 11, 2009
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.
Thursday, April 16, 2009
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.
Tuesday, March 18, 2008
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.
Sunday, March 02, 2008
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.
Wednesday, November 14, 2007
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.
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.
Friday, November 02, 2007
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.
Sunday, August 26, 2007
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.
Tuesday, July 10, 2007
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.
Monday, June 18, 2007
JavaFX'plained
Previously I gave an overview of Sun's present condition and prospects. Sun's recent announcement of JavaFX provides an illustration of how well Sun is doing staying on the right course.
First, remember to steal the good ideas
The use of one brand to cover disparate products is one of those bad ideas people really shouldn't steal from Microsoft. What the hell was COM, anyway? Sun had their own misadventure with one confusing name for a variety of technologies: “Beans.” Netbeans, Java Beans, Enterprise Java Beans, this beans, that beans. The meaning was obscure from the start and it turned into a semantic fog as things labeled “Beans” diverged from each other and from their original technologies. JavaFX carries on this proud tradition: In part, it is a product that was formerly called F3, or Form Follows Function. What a fine name. Let's replace it.
In part, JavaFX is the mobile Java and OS technologies acquired from SavaJe (“sava J?”, “savage?”) which is a stinky name that ought to be replaced – but not by the same one that will only confuse people. Now it's all called JavaFX. Alles klar?
JavaFX Script
The hard part about the discipline of focus is that people keep tempting you to chase competitive responses. This temptation is high right now, with Adobe attacking Sun on the server side with Flex, and Microsoft attacking Adobe Flash and server-side Java with Silverlight. I'll keep this brief lest anyone mistake me for a Web application guru: While F3 is a great product, it isn't enough to make Sun a key player in client scripting technology. Various Javascript/AJAX tools – many of which complement server-side Java - and Adobe Flash rule this area now. Microsoft has the chops to make a run at it, and Silverlight looks like a credible attempt. Why tilt at this windmill?
There are reasons to doubt JavaFX Script is up to the task: For one thing, it requires the full Java runtime - the same hurdle that makes Flash a more attractive alternative in many cases. It also relies on Java Web Start, a little-used and somewhat cumbersome technology for launching Java applications from Web pages. Silverlight takes a more direct approach to the runtime problem, shrinking the .NET runtime to where it can be deployed as a browser plug-in that is comparable in size to the Flash plugin.
There are numerous doubts about JavaFX Script's future: Can Sun apply the resources to make JavaFX competitive? It that possible without rearchitecting JavaFX Script? Is there a need for a Java technology other than, say, GWTs for creating browser-based rich interfaces?
The announcement of JavaFX Script looks like Sun gave in to the me-too temptation, and took an interesting but underdeveloped technology, dragged it half cooked on stage at a developer conference, and discovered that most of the audience's reaction was “Huh?”
It will take a marvel of cross-project coordination to make JavaFX Script work: A scale-able JRE, UI creation tools, improving on Web Start for deployment, etc., all going into the teeth of better-funded efforts at Microsoft and Adobe.
JavaFX Mobile
In addition to the general confusion that comes from using the same name for two different things, JavaFX's chances in Web applications could drag down JavaFX Mobile.
JavaFX Mobile is the re-branding of assets acquired from SavaJe. These assets include an operating system with roots in the Bell Labs Inferno OS, an implementation of JavaSE for mobile devices, a mobile phone user interface, and a suite of applications. Why not call it “JavaSE Mobile” or “Java Mobile OS?” That would be recognizable, descriptive, attention-grabbing, unambiguous. Nah.
Sun has a task ahead of it: Buying the assets of a failed startup with a pre-market product is dicey because the product isn't in saleable condition. Sun has to quickly diagnose what went wrong with SavaJe and make the right adjustments. This may include a substantial investment in product development on top of the cost of purchasing the assets. Purchased assets are seldom aligned with the priorities of potential go-to-market partners, so a purchase can look disappointingly off-target just as new resources need to be committed to it.
SavaJe took the most brittle strategy possible and broke their $120M VC pick on it. That doesn't make them stupid: A VC funded company's task is to pursue the opportunity the investors want pursued, even if it is riskier than what the founders might think is the optimal balance of risk and return. SavaJe pursued top-tier mobile OEMs with the proposition that Java SE on a minimal embedded OS from the same vendor makes for a compelling modern platform for mobile handsets.
Handset OSs are due for a shake-up. The winner, by default, for an off-the-shelf mobile software stack is Windows Mobile. Palm used to contend for this business but has failed to update their OS for too long now. And while mobile software took approximately twice the usual number of versions for Microsoft to get it right enough, Windows mobile is now a low-risk path to market for ODMs making smartphone platforms.
Still, there is a huge opening for other mobile OSs: Microsoft doesn't “get” OEM requirements: If you want a feature, they will add it to the list. Thanks for your input. Windows Mobile is too resource-heavy, and the license is too expensive for mass-market phones. Microsoft is a competitive threat to any OEM with an eye on the enterprise mobile and unified communications business. There are plenty of reasons the market needs an independent technology provider that isn't taking a vertically integrated approach.
So why did SavaJe fail? The short answer is that they failed to provide sufficiently compelling product and value to crack the very limited number of target customers they were aiming for. The SavaJe UI was no great shakes. From looking at it, and from what it did, it was hard to discern the benefit of a new OS and a Java application layer. In fact, the newness of the OS, and the need to buy and interface compulsory components like Bluetooth, dragged down SavaJe's ability to make use of Java as a tool for creating a superior user experience. Inner beauty doesn't put software on handsets.
On top of that, SavaJe's founders had an attachment to doing their own operating system. It's what they did at Bell Labs. It's what they understood best. And while the decision to use Java (instead of a purpose-built managed language system as in Inferno) was the correct one, the OS consumed resources and mindshare that could have been better focused.
There are other examples of attempts at mobile software stacks that lacked a reason to exist: Pollex, based in Beijing, tried the “it's cheaper” approach to the lower and middle-tier handset makers, and ended up in an asset sale to a chip maker that is re-purposing those assets under the heading “it's zero-cost.”
Which leads to one of the big questions facing Sun: double down on the operating system bet, or cut your losses and go with Linux as a mobile operating system, or they could go batshit crazy and convince themselves that if Apple could turn OS X into a mobile OS, Sun could do the same to Solaris. Frightening that that is even plausible enough to enumerate as a possibility.
Another big question Sun faces is: How to forge the SavaJe applications suite into a compelling user experience, and for what purpose? Look at the lesson of Pollex: Is SavaJe anything more than Pollex in Java? Sun has to come up with something better than “Series 60 is getting old.” Java, by itself, can't sell it. The story has to go something like “JavaFX Mobile solved the incredibly painful _______ problem for me, and what's more, it was a great software development experience customizing it because of Java.” If they can't fill in that blank, better to stop and rethink it.
Last, and not least, Sun faces the question: What is the market insertion strategy? There are only a handful of tier-1 mobile OEMs. Even if Sun comes up with an amazing mobile user experience, what makes it so compelling that a mobile OEM would give up their own differentiation through user interface in order to adopt Sun's? As a high-cost technology provider that can't afford to be as patient as Microsoft, it will be difficult for Sun to avoid the same logic that drove SavaJe into the long shot approach of targeting tier-1 mobile handset OEMs.
Sun has opened two fronts against adversaries that can apply more resources. The better decision would have been to pick one and go for a decisive win.
Friday, June 01, 2007
A Week in Beijing
Prelude
The Chinese consulate's visa office is efficient. It has to be, since it is thronged from the moment it opens in the morning. A display above the row of windows shows a queue of the next several applicants' numbers and assigned windows, so you know the optimal time to get up and and stand at the assigned window. My wait time was short, even though the waiting area was full. Same-day service (about 4 hours, really) costs just a little more, and a kiosk in the waiting room enables you to check the status of your visa processing by scanning the bar code on your receipt. They seem to beat their estimated completion time, so show up a little early for pick up and check at the kiosk.
United Airlines still uses the East German service model: The PA system blasts your ears if you are unlucky enough to use their “entertainment” system when the safety announcements are made. The seats are packed-in, making it difficult to use a laptop. The Boeing 737 is dingy, and the lavatories smelly. Service is sparse and unfriendly: If you ask what is in the snack boxes, you are told to look it up in the magazine. There are worse airlines, but not by much.
The plane was delayed at departure due to a broken seat. More seriously, the smell of burning electrical insulation filled the cabin in the middle of the flight. It was serious enough to cause the flight attendants to grab fire extinguishers, and for passengers to get out of their seats to try to assess the seriousness of situation themselves.
This time, United got me to my connecting flight, barely. The 747 out of SFO was an improvement over the flight from Boston. The service was less customer-hostile. In-ear, noise-isolating headphones and a few hours of sleep on this leg of the flight were key to arriving Monday afternoon in good enough shape to push through to evening in Beijing without falling asleep too early. The 12 hour time difference was easier to adjust to than the 6 hour difference to Europe.
What it's like to be illiterate
The biggest pucker-factor in traveling to China is the fact that, if you have not put in the considerable effort to learn a few hundred Chinese characters at a minimum, you are illiterate. On top of that, Chinese pronunciation isn't easy, and the locals are not used to non-native speakers mangling their language. Nobody will understand what you are staying if you try to use a phrasebook. If you get lost, you are screwed.
You must have your hotel's address and phone number printed in Chinese to show the taxi driver. At the airport in Beijing, walk past the touts for gypsy cabs and go straight to the efficiently-run official taxi line. The attendant will make sure the driver understands where he is to go.
Even though people are getting their visas for travel to China as fast as the consulate can process them, the scale of Beijing means that visitors are swallowed up. The hotel clerk will speak enough English to get you checked in. That's it. You are well and truly in China, and most of it isn't labeled in English. Signs are undecipherable to you, and therefore untranslatable, even if you had a dictionary.
Hotels are plentiful, moderately priced, and (at least the better moderately priced ones) clean. Since it is nice to have a hot shower and BBC news in a place where you can't read and nobody understands what you are saying, I would not economize on the hotel too much. Food, however, is another matter. You will be happier in a local noodle shop than in the hotel restaurant. The only substandard food experience I found in Beijing was at a hotel restaurant where the potstickers looked as if they came straight out of the freezer and into the Fryalator. Noodles are to Beijing what bread is to Paris. The locals will gawk at you, and you will have to point at what you want, but it's worth it.
Smog
Beijing is often cloaked in smog. Monday afternoon combined smog with a low overcast. Eventually it rained. The evening was science-fiction gloomy, illuminated by incomprehensible shop signs reflected in the wet pavement of the main road through the Haidan district. Disappointingly, the evening did not include anyone saying “He say you blade runner.”
Tuesday
The rain failed to clear the smog, and a pale yellowish-browish haze created a bubble of visibility about three blocks in radius.
China, as a relatively open society in practical terms - that is, where people can choose their education and employment - is less than 25 years old. Everything is new here. So, although liberalization in China predates the fall of the Berlin Wall, it started from a far more closed society, and with a far larger population.
The fast pace and massive scale of development in China gives rise to startling realizations: Although Beijing is full of cars, people measure their driving experience in thousands of miles, not years. Almost everyone working in software is young, and they look younger.
While not readily visible in Beijing, there are aspects of China that remain Dickensian in their vividness: A news story about an orphanage for deaf-mutes renting their children to pickpocket rings, and another about a horrific industrial accident in a steel mill, for example.
Big, and getting bigger faster and faster
China consumes half the world's production of concrete and one third of the steel. It is said half the construction cranes in the world are in China. Maybe more. Beijing is a mid-rise city, perhaps due to an aversion to having the Imperial Palace fenced in by skyscrapers. Instead, 15-30 story buildings line the boulevards in all directions for miles. Seldom is a new apartment building a singleton. More likely four, or six towers cluster together.
Beijing is not a tidy north European city. There are plenty of older, down at the heels apartment buildings. Petty theft is a common topic even in English language newspapers. But brief strolls away from the main road, through the back streets where apartments tower behind the front rank of commercial buildings found little misery or hooliganism.
Construction workers live on-site, in prefabricated two and three story metal dormitories. These were much in evidence in the Haidan district since a new subway line is under construction.
China is young
Young people, often walking hand in hand, were typical of the people on the street. Modest shops catering to the locals are in the side streets, and, often enough, on the main road, too. The shopkeepers were typically cheery, often chatting with friends or customers in front of the the usually small shops. The scale of Beijing ensures tourist shops cluster near the Imperial Palace and a couple of nightclub districts. Everyplace else has to make a go of it based on the local people's custom.
The defining characteristic of Beijing is youth and easy informality. People are neither wearing rags nor do they stretch to look more “proper” than they need to. Work attire at technology companies, where pay is a bit higher than average, is remarkable for being mostly the same as what coders everywhere wear. Workmen loudly go about constructing the shop next door to a restaurant, and diners are unfazed by the noise. Beijing is about getting on with commerce.
While a city this large cannot be dominated by a building, the Olympics are on everyone's mind. Much of the modernization of Beijing was driven by the deadline of the Olympics and the people of Beijing are genuinely excited that the world will see what their city has become.
In 25 years, hundreds of square miles of overcrowded hutongs have been transformed into a modern cityscape, even as the city absorbed millions of migrants from the countryside. Millions of trees have been planted in time to grow large before the Games. Hundreds of miles of new expressways were built, and were filled with cars in only the last decade. If anyone still thinks China is a cluster of industrial parks feeding the Wal Mart supply chain, they will be stunned to see Beijing.
Mobile culture in Beijing
The Chinese have phones. Many of them have nicer and more expensive phones than people at the corresponding income level in other countries, indicating that the mobile phone attracts a larger share of income.
The typical mobile phone shop, or department in an electronics shop, puts the high-end Nokias and SonyEricssons up front. The mainstay phones are little different from those in the U.S., with color LCDs and the usual set of features, a bit trailing-edge, with an emphasis on low price. Super-low-end phones are available, with monochrome displays, but not all that common. As in the U.S., most phones are GSM, with a large minority of CDMA phones.
I have seen the future of electric vehicles
The government makes is hard to get a registration for a motorcycle or scooter, so these are rare on the streets of Beijing. Bicycles are still commonplace, but the typical Beijing commuter takes the bus or the subway. Taxis are ubiquitous, and there are enough people who can afford cars to clog the roads and make it faster to bike during rush hour. The main boulevards have frontage roads that are for parking and for bicycle traffic.
But the real star of Beijing traffic is the e-bike. An e-bike is a bicycle with a 250 watt electric motor in the rear hub, and a battery pack on the down-tube or behind the seat-tube. The batteries are removable for charging at home or at the office, and pedals ensure that you cannot be stranded by a faulty charger or unexpected side trips that exceed the range of the batteries. The look is somewhere between that of a bike and a very light moped. Some come with more powerful motors and larger batteries, and look like scooters.
The popularity of e-bikes is exploding. They glide along at about the top speed of a bicyclist, and because they can keep that up consistently, they are the fastest way to go when traffic is heavy. They are incredibly energy-efficient, and cost about US$300 – affordable for most Beijing commuters.
The impetus to create e-bike products is the limitation on motorized scooter and motorcycle registrations, so this is a market that is rapidly evolving in China. Outside China, Giant and a few other bicycle OEMs sell e-bikes in the U.S., but these products are expensive and have not found a customer base. Ad hoc importers, which you can find on eBay, offer China domestic-market models but at a steep mark-up.
The knock on e-bikes is that the lead acid batteries must be replaced every two years – more often than car batteries. While lead acid batteries have been successfully recycled for decades, there have also been numerous cases of poor practice in developing-world recycling plants. However, if proper recycling can be assured, the e-bike could become a very beneficial global phenomenon.
Coffee in Beijing
Coffee is foreign. Coffee is expensive. “Coffee shops” often don't “get” coffee. But sometimes, you need coffee. The strangest food experience I found was in a “coffee shop” where I ordered a coffee, which was passable, and a “puff pastry” that turned out to be a blob of deviled ham on a toaster waffle.
The Coffee Time chain of coffee shops is very good, however. Excellent espresso drinks and gelati in the Italian style. But the prices are high enough to keep the locals mostly out.
As with many other things in China, coffee and chain restaurants are new and still being worked out. Things are happening faster than the local tastes can absorb, and some commercial developments have the logic of an Internet land-rush, where presence equals success. The number of Kentucky Fried Chicken and Papa Ginos in Beijing probably have more to do with aggressive execution on the part of the companies behind these chains than a real taste for this kind of food.
Friday
Smog dominated the sky until Thursday evening. Thursday night was windy enough to blow the cap of smog off, and Friday dawned bright and clear. Bright sunlight, sharp shadows, and blue sky, as far different from the combination of smog and rain that greeted my arrival as can be.
The office where I was visiting now had a view of the mountains north of Beijing, a bit like the typical view of mountains in San Jose. The Imperial Palace and Tienanmen Square are as impressive as reputed, and very pleasant on a sunny day.
Sunday, May 13, 2007
What I learned at JavaOne, or: If I Were the Sun King
If you were at JavaOne last week, you would be reminded there is a another player on the world stage of computing: Sun Microsystems. They don't get noticed the way Google Apple and Microsoft do, and they don't have the aspect of a social movement that the Free Software Foundation, kernel.org, Mozilla, Eclipse, Ubuntu, Red Hat, and the other major open source projects and Linux distributions have. Sun is the last of the vertically integrated computer technology companies. This fact alone makes Sun's impact on computing potentially enormous. And the fact that Sun is widely ignored either means that Sun's ability to bind its technologies together into a strategic advantage has been poor, or that vertical integration, and a companies like Sun, are passe.
Sun has a new CEO, Jonathan Schwartz, and he has executed a tactical turnaround by focusing Sun on high-value customers. Sun is now profitable, for the first time in a long time, and that is cause for some optimism. But that optimism has to be tempered by a objective look at the size of the task ahead, and it the difficulty of each component of that task.
Another good reason to take a look at Sun's position in the industry is that there are some signs of strategic execution at Sun: Sun recently acquired the assets of SavaJe, a failed mobile handset software venture that left a 120 million dollar crater in a couple VC funds.
At JavaOne, Sun made several announcement that show the intention to move in the right direction, but this isn't they story of a sure thing. As of now, Sun has 20% of the market value of Apple, 60% of the revenue, and twice the number of employees. Sun has been so down for so long that making things right won't be simple, nor is there room for any lack of decisiveness.
In this blog entry, I take a look at each aspect of Sun's business as it relates to the industry and to major trends like open source, and see what Sun can do to improve their position, and weigh that against the costs. One thing that is clear from the outset is that Sun is engaged the computing industry at so many points it is hard to see them sustaining all of them without very strong justification for each. That makes the SavaJe asset acquisition all the more interesting: at a time when Sun must focus and decide what not to do, they have added mobile platforms to their agenda. Is this a brilliant move or a distraction?
Operating Systems
Solaris is characteristic of Sun's missed opportunities. Sun had the position of providing the best-supported UNIX-like operating system and squandered it through a complex combination of ambivalence regarding open source software, internal conservatism that prevented making radical changes in pricing, and lack of foresight regarding Sun's ability to compete without finding a parter (in this case, either Apple or open source distributions).
While anyone is free to download and use Solaris on x86 architectures, this gesture alone did not make Solaris a viable open source operating system. It didn't amount to more than a try-before-you-buy offer, and Sun's weak financial position through many consecutive quarters of losses made Sun's commitment to desktop operating systems questionable. While Solaris is in many ways still the best UNIX-like operating system, it must either be brought into a leading position in the open source operating system world, or Sun must use the open source community as a way of gracefully exiting the operating system business.
In either case, Sun must turn Solaris into a branch of the open source operating system and distribution taxonomy. That is, the Solaris kernel must become an alternative to the Linux kernel, much the way the BSD kernel is, and the GNU Hurd would like to be. And the Solaris userland must merge with the open source userlands and applications in the open source distribution world.
Solaris becomes, then, a collection of open source projects that feed into distributions, and, if Sun remains in the operating system business, an open source distribution that happens to emphasize Solaris projects. In concrete terms, merging Solaris with the Debian repositories wold be one way to implement this concept. Solaris as a product would then become a downstream distribution like Ubuntu, which would not be the worst thing to flatter with imitation, both in implementation and in business model.
A further irony is that Sun is executing well in some isolated cases, like NetBeans, but overall has failed to accrue the benefits Canonical (Ubuntu) and RedHat base their whole businesses upon. How long has Sun known internally how to get this right? Since 1993: http://www.redhat.com/support/wpapers/community/freeunix/freeos.pdf This is typical of Sun: full of individuals who know what to do way ahead of the competition, and no ability to act on what they know.
Languages
Microsoft has C# and the rest of the .NET family of managed languages. Apple has Objective C and Cocoa. Sun has Java. Java is the dominant managed language system for Web applications, which is arguably the dominant position overall among programming languages.
Java suffers from not being a revenue-generating product in proportion to the effort Sun puts into Java. But this is through no fault in Java. Development tools and languages are a thankless task. So the main benefit to be had is indirect.
Sun has lagged far behind Microsoft in making Java a usable client user interface language system, and has lagged integrating an IDE into the language system strategy. Only within the last year or two have these aspects of the Java language system strategy reached parity with Microsoft's .NET and Visual Studio products' capabilities. This lag is mostly the product of Sun's unwillingness to match the resources Microsoft applies to languages and tools.
Going forward, Sun must decide to either compete with Microsoft on a continuing basis, and not allow aspects of Java to fall behind, or Sun should find a way to exit the competition and turn Java and related products over to the open source community. Sun must also integrate Java with other product strategies. Currently, Java is not key to the Solaris userland. The open sourcing and dual licensing of Java finally made it acceptable for inclusion in mainstream Linux distributions, but Java has not taken its rightful place as the .NET equivalent in the Linux world. Sun is moving in roughly the right direction with Java, but has a very long distance to go:
Sun's Java should be more thoroughly blended with the open source world. This means a more cooperative stance w.r.t. alternative implementations.
The Java Community Process, a name containing at least four separate untruths, should be scrapped in favor of a process modeled after Internet RFCs.
Java should be made scalable on the client, and the Java CDC variant should be scrapped in favor of a scaled-down Java SE. There should be at most three Java variants: a minimalist Java ME, Java SE for almost every desktop and device, and Java EE for servers – but the client and server Java line might blur to the point where that distinction no longer works.
Java should be multi-platform (multi-CPU, that is) out of the box.
If Sun does not speed up the integration of Java with the open source movement, Java will lose to simpler open source dynamic language alternatives, and Microsoft will make further inroads into mobile devices with their relatively coherent implementation of .NET across desktop and mobile devices.
Hardware
While Sun can continue to compete in server hardware by building the biggest server systems, Apple has set the tone for how to compete in desktop hardware: Adopt the best CPU over the long-haul, and differentiate using software and design.
Sun has all the ingredients to be a world-class competitor, but has flubbed the execution needed to stay in the desktop computing game. Most of the rest of the UNIX workstation business died so long ago it forms a fossil bed under San Jose. There may be a business in super-high-end visualization workstations, but for 98% of users, PC hardware is a commodity and is best left to the master commoditizers. Sun should sell their workstation business to someone who wants to become a high-end desktop OEM.
CPUs
Sun cannot justify being a CPU company without having a long-term sustainable advantage. Sun cannot afford the capital to acquire that advantage, nor the price of failure: Could Sun take a hit like AMD just did? Sun should therefore exit the CPU business and focus on, for example, chipsets, clustering hardware, and storage systems to sustain Sun's position in high-end server systems.
Applications
On top of operating systems, languages, hardware, and CPUs, Sun is also an applications company, with the Star Office/Open Office products. Like other aspects of Sun's portfolio, Star Office/Open Office is a mix of grassroots open source success and standards leadership, combined with under-resourced development and lackluster product management, resulting in a lack of truly distinctive features in a rigorous competitive environment. In other words, Sun is lucky to have an opportunity here, but should not mistake that luck for an excuse not to focus resources.Sun must, again, decide whether to keep this product, find a new home for it, or fully transition it to the open source community. For it to make sense to keep an office productivity suite, Sun must get on track to re-entering the desktop computing game as a software and/or hardware maker. Star Office/Open Office must move closer to Java as the glue between software subsystems.
Mobile platforms
It almost seems like piling on to say that Sun, at a time when it must make hard decisions about what to do, and what to get out of, has taken on another operating system, another Java variant, and has entered the mobile platform business when others, like Symbian and Palm, are illustrating what a difficult and thankless business it is.
Without extreme clarity of vision in identifying customer needs and quickly shaping the former SavaJe mobile platform assets into a winning product. Sun will have dissipated resources in reaching for the seductive unit volume of mobile handsets when it just can't afford such dissipation.
SavaJe left a $120M crater in the surface of planet VC part due to building their own operating system in a market where embedded Linux is super-hot and entrenched proprietary platforms are mature and reliable. Even mighty Apple is having trouble birthing a new mobile OS. Does Sun have the focus to question this aspect of the value of what they just bought? Can they mold the already unfocused SavaJe user interface into something that addresses concrete needs? This acquisition is an albeit inexpensive daredevil move by a company that should probably keep the skateboard in the closet. It could be made to work, but without strong signs of excellent execution in other areas, or, alternatively, a excising of marginal products in order to put overwhelming resources on mobile products, this is likely to end up as another under-resourced dispersion of focus. Moreover, the mobile software world has only the faintest glimmer of an open source ecology. Sun can't offload part of this burden they way it has with OpenOffice. If it fails it fails hard.
What if they don't?
What if Sun does not move to get on the right track in each of the expansive range of product categories in which it now participates? If Sun does not focus Sun, Sun will likely be focused through external actions. Private equity companies roam the landscape, scarfing up slow, fatty dinosaurs. Sun could become the target of such a takeover, with the tarnished crown jewels being sold off to defray the cost of buying Sun, which would then continue as a server OEM and services company, unburdened of the responsibility for workstations, Java, Solaris, Star Office, SavaJe, and SPARC.
That might happen. But I hope the alternative prevails, and Sun re-emerges as a key player in the computing industry. The computing industry would benefit from another strong participant in all the important technology categories, and open source has provided a new opening for a competitor to enter (or re-enter) such a position in the industry. Sun has an amazing collection of people who are more than able to achieve any goal. Which is to say, it comes down to leadership.
It would be fun to download an Open Solaris with a unique eye-candy-rich Java-shell/desktop that installs as painlessly as Ubuntu, and that lets me mash up my Open Office documents with Internet applications using Java, and that integrates nicely with a viable mobile software platform. I also hope this visualization of a good result illustrates how large is the task. If Sun can't see themselves getting there, they ought to plan for what happens when they don't.
Saturday, April 14, 2007
You Can't Spell DRM without "A-S-S"
The lesson is: Don't ASSume. Don't assume that DRM will be around forever. Don't assume that the computer and telecommunications industries won't throw off the yoke of DRM to achieve more growth. With one modest epistle – not the “tear down this wall” flourish you might expect from Steve Jobs – the future of DRM was thrown into question. Subsequently, EMI tore a hole in the RIAA members' hitherto seamless adherence to DRM, and Apple removed the barriers to using EMI music bought from iTunes on other music players.
Content protection of consumer media products has been around in one form or another since Hollywood got all itchy about consumer videotape machines and started fooling with the signal to prevent tapes from being copied. Macrovision, the most successful developer of tape content protection was founded in 1983, and is still around, protecting digital content from the people who buy it. Other early forms of content protection include market research reports printed on blue paper, with watermarks and serial numbers, to thwart photocopying.
DRM, the digital form of copy-protection, has been a topic of serious research for about the past 20 years. Video games, commercial computer software, data compilations, typefaces, clip art, etc. use, or have used, various forms of content protection to try to slow down use of commercial digitally stored products in ways that contravene the license agreements that sellers of these products use to create an environment in which – in general terms – content belongs to the provider and is rented to customers. DRM is the prevalent form of content protection today because copying digitally stored content is fast and cheap, and this has raised the stakes: Any “leak” of a digitally stored product can be quickly turned into thousands or millions of copies.
The moral and legal basis for contracts licensing the use of intellectual property long predates recorded performances as a consumer product. In the U.S., copyright and patents were created, in the words of the United States Constitution...
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
That's it. Anything outside that authorization, in U.S. federal law, is illegitimate in that it has no constitutional basis.
There are three distinctive aspects of intellectual property: 1. It is a right created by government. The right to intellectual property is not an inalienable right – it is not one that exists with or without government acknowledgment. 2. It has a stated purpose. No other human right has to justify itself. 3. It expires: You own your property forever, but your copyright or patent expires and your “ownership” or, more correctly, your exclusivity in use, licensing, or publishing, is over, in order to create a greater common holding of knowledge and art.
So how did we get from such a weak, limited, qualified, and overall second tier right as that created by this cautiously crafted clause to today's ponderous, invasive, unbounded, intrusive, over-lawyered, kudzu-like thicket of laws and technologies? Consider, for example, showing the “FBI warning” on a DVD recording, that says you will become a felon by doing something untoward with a DVD of Howard the Duck, to one of the people who drafted the Constitution's intellectual property clause. Ask them “Is this what you meant?” Never mind the DMCA and other sausages of dubious legal content.
The 100 year history of recorded performances has funded a tsunami of lawyers and lobbyists that have succeeded in overwhelming all restraints on turning our intellectual property laws into a travesty of original intent. Starting on the basis of such raucous cognitive dissonance, no wonder the modern pursuit of intellectual property has overshot even the most elastic bounds, and is now starting to snap back.
Steve Jobs's objection is, like any reasonable view of intellectual property, both pro-freedom and pro-commerce. DRM has failed the business of selling music recordings. Two or three out of a thousand songs on iPods are sold from Apple's relatively successful Internet music shop. The rest of the DRM-protected music download business is a miserable failure, just like DRM-protected e-books were a readily predictable irretrievable flop, and for much the same reason: Even the most apathetic consumer sees the value of the ability to transfer, backup, and migrate their music collection. DRM thwarts these basic requirements. The value of buying and selling in a secondary market is also completely extinguished by DRM.
The response of the recorded music industry was to try to eradicate any choice other than DRM'ed music. As if making a content gulag that was so big you could not see the barbed wire perimeter would make it seem like your content was not imprisoned.
Content protection does not always fail. When is the last time you heard someone complain that their Nintendo DS uses content protection? You don't hear such complaints because all the software runs on all and only that hardware. You can buy a DS cartridge, transfer it to another DS, sell it, and buy a different used cartridge exactly as if you were buying and selling books. The product is tangible and your use of it is in practical terms irrevocable. You don't use a DS for private documents. You can chat on it, but it isn't a general-purpose communications device, so there are no privacy concerns. DRM, when it is un-intrusive, and non-essential to any truly important personal matter, does not stand in the way of product success.
People who make DRM systems have no excuse: The examples that work are out there. Failure to realize that anything outside such closed ecosystems is damaged by DRM to the point where customers reject it as defective is entirely the fault of the system designers.
How far will this backlash lash? There is another change in Apple's position on DRM that is also noteworthy: In October 2006, Apple stopped using a Trusted Platform Module (TPM) on its motherboards. Trusted Computing is a delightfully newspeak term. It means you, the computer owner, cannot be trusted, and that certain data and code has to be hidden from you on your own computer. Trusted computing is, of course, antithetical to Personal Computing. If you don't control every bit inside your computer it isn't personal. In fact, it is partially owned and controlled by someone else.
The full exposition on Trusted Computing is a topic for another post. But the summary of the problem is that computers are an all or nothing affair: Once you let that tiny bit of camel's nose under the tent, you will have a tent full of camels in short order, each of them snooping on behalf of some interested party, be it the people who think you might be a terrorist, or the people who think you have evil intent for their music recordings. One could even implement some form of “Information Purification Directives.”
If Apple smells an opportunity in reasserting the Personal part of Personal Computing, especially as Microsoft appears to be turning your PC into a servant of the content publishers, we may see a very interesting phase of the PC business emerge.
Thursday, February 08, 2007
The Meaning of iPhone, Part II
.
This is where it get provocative:
- iPhone uses the mobile network as a backstop. The real action will happen on iChat, over WiFi. The iPhone platform is sure to be used in iPods that don't have a mobile phone radio in them. But those iPods will have WiFi, and they will be communications devices as well as media players. Communication will be an Apple product, but not the way the mobile network operators would prefer. iPhone is turning mobile service into the dial-up modem of the 21st century. The mobile carriers have been quarantined into providing switched circuit voice service in the iPhone, and left out of iPhone's commerce and higher-value communications.
- iPhone is an embarrassment to 3G. iPhone isn't selling music over 3G. Unless there is some unforeseen disaster in iTunes sales because people can't buy music while driving, iPhone will show up 3G data service as not having found an application. The premier mobile media commerce channel brushes off 3G as unnecessary in a mobile product, and the network operator accedes to this decision. Verizon turned down iPhone, and Cingular snagged a long term of exclusivity, so it's also a missed opportunity for EVDO and MediaFLO.
- J2ME is a ghetto for low-rent games. Too limited. Too security obsessed. Too much rigmarole to install and manage applications. Too fragmented to support applications that have a lifecycle. What could have been done in J2ME will be done in widgets or Cocoa (or in Symbian-native apps on Nokia handsets, or in .NET Compact Framework on Windows Mobile devices). However, most mobile applications will be AJAX running in full-featured embedded browsers. Java on devices? Make it Java SE on Linux, which is a fine alternative to .NET and Cocoa, is needed for applet support (dirty little secret: some of the best “AJAX” is actually applets), or fuggedaboudit.
The communications part of mobile telephony can be made more valuable and more powerful:
- Presence is the killer feature of IMS. Presence that is standardized and that interoperates across service providers.
- The user interface should have presence at the center, not off in a cheesy push-to-talk application written by a 3rd party and with a UI that looks like a programmer drew it with a crayon.
- Presence is common to mobile and Internet communication. Make something out of that fact that makes users go “oooooooh!”
- Real-time and messaging are a continuum. Push-to-talk is the bridge.
- All messaging is the same – to the user. Break down the protocol-based silos.
- Find applications and lead experiences outside of mobile media: Enterprise integration, social networks, etc. Don't bang your head against iTunes.
The mission for the mobile industry is to add value to communication. That's easy and natural in IP media, and anyone can create a new application. If comparable natural flows among modes of communication are available on mobile devices, users will go with mobile networks for their pervasive coverage. Blending the mobile network's pervasive availability with Internet applications captures the best of both worlds.
IMS both creates opportunities but it presents a potential blind alley, too: IMS makes mobile presence-based applications, like PoC and instant messaging interoperable and standardized, but it also plays the siren song of “service creation” - a blizzard of new services that won't add much value and that will confuse users. Stay away from things that duplicate a Web service using IMS.
Thursday, February 01, 2007
Calling All Telecom Bloggers
.
Have you got something original to say about the ways that humans communicate over a distance? Comment this post and let us know about your blog.
Monday, January 29, 2007
The Meaning of iPhone, Part I
iPhone was announced, raised up as a messianic product, suffered a backlash (already, five months before it ships), and is still supplying fresh blogfodder:
First, what everyone knew from 10 seconds into the demo, is that iPhone is not a defensive move. Apple did not merely forestall what has been the oft-repeated and never realized prediction that mobile phone unit volume would inevitably crush iPod under a tide of carrier-subsidized music players. Apple is now the maker of the most desired phone on the planet.
Nobody has ever gone from zero to the very top of the game with their first mobile phone product. Expectations for the iPhone were that it would be a Very Nice Phone inside of an iPod. But only that. Instead Apple has created a new mobile phone OS and UI platform and implemented it to a level of polish above all others. They put this new software into a vessel that is, once again, the nicest package in the business. Only this time in a demanding and mature business to which Apple is a new entrant.
How much better is iPhone? Despite the very competent efforts put into mobile user interface systems like UIQ and Series 60 UI, has anyone ever really been impressed by the results? At best, users of existing products find them adequate. Inoffensive. Nice that they don't often get in the way of an important task, like reading e-mail. Meeting this standard is what Apple was expected to do. Instead they passed it from a standing start and are now in the lead.
The only knock on the iPhone is that it does nothing new, other than provide a visual interface to voicemail. But even that modest advance was a zinger. Handset product managers world-wide are dope-slapping themselves for not pushing that through in the fifteen years since that has been technologically do-able.
But this is Apple: Making the object of desire is just the start. Apple also took the challenging environment for selling a mobile phone into the U.S. Mobile network operators' channel and turned it into a work of art comparable to the iTunes contract negotiations.
By giving a willing network operator the temporary advantage of exclusivity, Apple got at least two critical benefits: Apple set terms that drive a wedge into the garden wall of mobile content sales by keeping iTunes sales off the mobile network. Apple also got the benefit of not having the iPhone subsidized by the network operator. That's correct – the benefit. In both cases one imagines the negotiations to have gone a bit like asking not to be thrown into the brier patch.
By keeping iTunes sales off the mobile network Apple completely hornswoggled Cingular. Cingular is a network operator. So who came off worse: Apple, for having to require that their customers use WiFi to download iTunes purchases? Or Cingular for having failed to sell the use of their network for this purpose? Cingular has ripped a hole in the wall in order to get that big wooden horse inside. Users of Nokia E-series handsets already know the real Web over WiFi is a much nicer experience than the mobile Web. Now millions of Cingular users will be comparing the iTunes over WiFi experience with the typical mobile content shop experience.
Which leads to the next issue: Why would Cingular subsidize an iPod, especially when it isn't using Cingular's network? Turns out they don't have to. Which also frees Apple from the prospect of music-only iPods competing against subsidized iPhones, and from mobile network operators using varying levels of subsidy, resulting in a range of iPhone prices, once the term of exclusivity expires. No subsidy also makes it easier for Apple to sell iPhone in Apple stores.
Keep in mind that MNOs' executives had not seen the iPhone. The only precedent they had to work with was the first iPod, which was hardly a revolutionary looking device. In agreeing to terms that appeared to be solutions to some practical problems when they were negotiated, they gave Apple the levers to move the mobile handset business in directions advantageous to Apple. As in the case of Blackberry subscription revenue, the mobile industry is willing to shift on some fundamental points of the handset vendor relationship if the handset brings with it significant end-user demand. But unlike Blackberry, it wasn't just a matter of revenue sharing.
It took two years for iPod to gain momentum. Analysts project that iPhone will take 1% of the mobile phone market fairly quickly. If sales fall into the range of 5 to 15 million units over 12 months Apple will roughly match their only near-direct competitor: Nokia Nseries, which sold 6 million units last quarter. In about two years Apple will have a product line as broad as Nseries, and could take 5% of the mobile handset business, and a really hefty chunk of the total profits, since Apple won't be selling any low-end handsets.
Are Cingular chumps for agreeing to these terms? Not really. They will look like geniuses for seizing what will be one of the very few opportunities to move a couple million subscribers to their network. The strategic impact of iPhone on the mobile industry will only be felt once the product exists in millions of units, and it will be spread throughout the industry. Apple will be free to set pricing of handsets, and will be free to operate a parallel commerce channel on a parallel network. No other handset maker has ever taken as much away from a negotiation. Even Qualcomm would be jealous of that kind of leverage.
What about the impetus – defending against mobile phones that are also media player? It sure looks like iPhone is a solid defense. But is there really a threat to defend against? Apple will sell more than 100M iPods in 2007. That is about one tenth the number of mobile phones that will be sold. The iPod market is now too big to be “crushed.”
Those engaged in building a mobile phone-based music business will have to contend with a fragmented handset technology and m-commerce landscape. Only Qualcomm and, perhaps, Nokia have control over enough of that landscape to mount a challenge, and to do it comprehensively from e-commerce channel to handset. On top of that, a mobile music challenger will have to use the mobile data network to deliver content of similar quality to that available on iTunes. And on top of that the prices will have to meet iTunes prices. Being able to buy on the go, out of WiFi range, just isn't enough to justify a higher price.
By the time a mobile music challenger really gets going, Apple will have new iPhone models on the market, and will be on the way to taking 5% of the mobile handset business and not just defending itself against the mobile music business, but being the mobile music business.
Wednesday, January 03, 2007
A Brittle Monopoly, a Fragile Revolution
Vista will have a broad-based launch soon. Unlike the launch of Windows XP and Windows 95, buyers won't be lining up outside stores to get the first copies. Vista is late, and Vista benefits are uncertain. This uncertainty was not helped by Microsoft's longstanding and widely publicized fascination with DRM – the benefits of which were seen by customers as ranging between dubious and toxic.
The other recent Microsoft product launch – the Zune – did not add to Microsoft's momentum. Zune is a geeky, awkward device that adds DRM to your own rips. It is promoted by an ad campaign with an obscure and awkward strap line that feels like something out of a “your brain on drugs” ad. And then there is the “squirting.” Oh, the squirting.
With all the bad news about Microsoft, you might be shocked to find statistics that say that 90% of the installed base of PCs are running various versions of Windows.
One can argue that the number is flawed. But the numbers that all add up to around 90% come from various sources, with diverse methodologies, such as retail sales and Web-site visitors. So 90% can't be attacked as a static measure, or one that is skewed by showing only one kind of computer user.
Another measure that suggests a near-monoculture of Windows is that viruses and spyware are almost exclusively targeted at Windows. Or, look at a catalog: Even the catalog of a “hobbyist-friendly” outfit like Micro Center has, maybe, 3% of desktop PCs with Linux. The rest run Windows. 0% of laptops come with Linux installed.
All indications are that personal computing still at the very narrow end of the wedge of restoring diversity in end-user operating systems. This is a movement that could be crushed or turned back. It certainly has not become strong enough that it is certain to survive.
However, when change comes, it will be sudden. Either Linux will be banned as too subversive for society, law enforcement, and content publishers to tolerate outside of Web servers and embedded applications, or Windows will precipitously fall from its position of near monopoly in the installed base of client operating systems, driven into retreat by the polish of Apple's MacOS and the freedom and democracy of open source.
The reason that change will be abrupt is that the Windows monopoly is brittle. It is brittle because it is based on hegemony in licensing to manufacturers, and on taking the content publishers' side in promoting DRM even as publishers become more strident, restrictive, rent-seeking, and litigious in their view of how content can be used by consumers.
This isn't the road to general popularity, much less is it the way to keep opinion leaders on your side. Any customer that is smart enough to be aware that their computer is going to rat them out to content publishers (and who knows who else) resents it. While most consumers are unaware or apathetic, opinion leaders are almost uniformly against DRM. Microsoft failed to grasp early opportunities to show DRM could be used to secure users' documents against misuse. That might have shifted the argument to something closer to a balance, but as it is, DRM is purely a source of resentment, without identifiable benefits.
Microsoft also appears to have a tin ear for the resentment against DRM. Apple is praised for pushing DRM mostly out of sight, while Microsoft is in the news for completely embracing DRM to the extent it is fundamentally changing the nature of a personal computer from a machine the user controls completely to one that is outfitted for surveillance and control by publishers (and who knows who else).
But all that does not mean that the Forces of Good will triumph. It does mean that the conflict over free and open software will be sharp and full of rhetoric about how free and open software is the tool of drug kingpins, terrorists, and pornographers. This rhetoric, and laws that make general purpose computing and communication tools contraband, will be used against free and open software. It will be used to hang the threat of liability over computer makers in order to maintain license hegemony.
Is Microsoft's share price stagnation and Microsoft's position for DRM linked? Before answering that, let's also ask if there was a different corporate culture at Microsoft when it was in ascendancy.
Microsoft's success was based on providing an inexpensive, off-the-shelf computing system that was good enough to replace many expensive minicomputer and mainframe systems that held customers hostage to high maintenance fees charged by hardware and software vendors. For those who could not afford minicomputers, Microsoft's software used to be the tool the little guy could use to level the playing field.
When Microsoft was on the way up, they were breaking eggs and making omelets. They were making other companies' products obsolete, and delivering high value, and driving companies like Wang, Digital, and Data General out of business. Now they are in the business of preventing the RIAA and MPAA dinosaurs from shuffling off to the tar pits, preventing corporate computer users from doing anything their IT department does not approve of, and preventing you from knowing everything going on inside your computer. That is, Microsoft has gone from selling creative destruction, to preserving obsolete business models, corporate IT controls, and facilitating content publishers' and others' intrusions into your use of information.
Does this mean Microsoft is doomed? No. Microsoft has thriving businesses in appliance devices like mobile handset software and game consoles where customers do not expect – yet, anyway – to have full control over the device. Microsoft's Office Communications Server is a dagger at the heart of the PBX business, and very much fits the model of the ascendant Microsoft. These parts of Microsoft will grow rapidly in the coming years.
It does mean Microsoft is in a vulnerable position on the consumer desktop. Like GM that can't compete with BMW quality or Hyundai price, Microsoft Windows is becoming a product only for those that don't care about having something better: Apple will be the choice of customers that can afford Apple, and Linux will be choice of those that value a true personal computing experience. Microsoft will be left with the sort of people who still buy Buicks. On top of that, depending on the extent to which DRM becomes visible to end-users of Vista, Windows will also become a product for people who don't care about not having Big Brother Inside. That may sound like an extreme comparison, but there was just recently a time when it seemed like GM could go on selling Buicks forever, too.
To really turn itself around and gain a path to new growth, Microsoft has to say no to the content publishers and say yes to end-users' concerns about privacy and control over computers and content they buy. But I don't expect Microsoft to do that until the message is written in declining market share and further stagnation of the company's value.
Monday, April 24, 2006
Writely or Wrongly, WebOS is Coming
Predating the first Internet bubble, there was the applet craze: It was thought that software would be delivered through the Web, on demand. Java was riding high on this fad, and lost a lot of credibility when the immaturity of Java technology (i.e. the unsuitability of AWT for making big, rich UIs on PC clients), low Internet connection speeds, high bandwidth costs, and Microsoft’s adverse reaction to hosting a potentially undermining technology in the bosom of their desktop OS, worked together to make applets less of the big deal than the pundits made them out to be.
Microsoft was able to contribute to blocking this disruption, but was not able to directly counter it or provide an alternative. .NET, like Java, became one of those dull gray tools of the IT crowd – a means of making multi-tier software systems without the hassle of understanding the complex threading implementations needed to make a middle tier that can serve thousands of users. This, despite the fact that .NET implemented code-behind-HTML and other features that made it quite a good tool for delivering user interface in Web pages.
Web hackers – the sort that don’t program in Real Languages like C# and Java - who never got the memo about server software, kept plugging away at making the Web user experience better.
“Better” means escaping the UI-as-form-filling paradigm that gave the Web a plodding, oppressive feel any time user input was required. The Web was born a hypertext system. Accommodating interaction beyond that required for hypertext is something that should be unsurprising in its difficulty.
Mapping MVC architecture onto multi-tier Web applications is not easy. In Web applications, the model is usually a relational database. The view is projected by middle-tier through a Web browser, which may include client-side code in Javascript. This complexity, and the hypertext heritage of the Web browser keep sucking Web UI back to a series of forms to fill out.
A rich Web user interface has to be debugged across multiple tiers, and, in the case of Javascript, across the client-to-middle-tier network connection. So, most Web UIs fail to grasp how to bring a consistent and highly interactive experience to the user and settle for the equivalent of what passed for UI back in the days of DOS, but with a prettier layout.
For an idea of the size of this problem and the value of simplifying the solution, take a look, on the one hand, at Enterprise Java Beans, even in its much cleaner 3.0 implementation, and, on the other hand, Ruby on Rails, which epitomizes the Web 2.0 ethos of productivity over universality. By focusing on solving exactly the above specific problem, which, while narrow in scope, vexes a large number of application developers, Ruby on Rails struck a very resonant tone, and has made an impression beyond the number of projects that actually use Ruby on Rails.
Ruby on Rails belongs in a spectrum of technologies we can call “Web OS.” Web OS is a system for running and building applications that run on Web servers and are used through the medium of a Web browser. Ruby on Rails is at the “building” end of the spectrum, while application suites like Writely, Gmail and Google Calendar, that have Web services interfaces but no SDK, are at the “running-only” end of the spectrum (although you can be sure Google has an impressive set of tools for their own coders).
We will soon see a lot more Web OS attempts, and, hopefully, some successes. Success, in this context, means making it possible for a large number of coders – not just those with Google's resources for toolsmithing – to create and run rich Web-based applications that truly break free from the “screen A -> screen B -> screen C” model of UI misdesign.
Whatever you may think about having your documents live on a server and editing them with tools that also live on servers, the WebOS future is likely to provide some interesting results: One easy prediction to make is that the mash-up culture will spread to all manner of applications, whereas the component document technologies that were supposed to put a spreadsheet inside your word processing document never really delivered. Maps, communication, auctions, translation, etc. will drop into Web OS documents naturally, because the data and communication that animates these document mash-ups will be available and compatible.
This is what makes Web OS interesting. If it stopped at implementing MVC applications in a particularly challenging implementation environment it would be only a technology curiosity, and probably not enough to motivate investment. But Web OS applications really can be better.
It's a good thing developers of these applications were never told how hard that is to do.
Thursday, February 02, 2006
The Model-View-Controller Design Pattern and iPod-like User Interfaces
In my previous blog entry I asked whether the iPod is an example of a new user interface paradigm, and concluded that it is. This time, I try to provide more of the nomenclature for describing user interfaces of this type.
Discussion of desktop user interfaces is much aided by the desktop metaphor conceptual framework, augmented by the MVC (model-view-controller) design pattern. The desktop metaphor describes how overlapping graphics contexts give rise to on-screen windows that mimic the look of overlapping pieces of paper. MVC provides a design framework for (potentially) multiple views of the same data to be present on the screen and to stay in synch as the underlying data changes.
Together, the desktop metaphor and MVC are the foundation of nearly every non-trivial desktop user interface. iPod-like user interfaces discard the desktop metaphor. Overlapping objects are out of place on the iPod. They have no metaphoric meaning, and the screen is too small to give overlapping objects enough visual context.
In the desktop metaphor, each window is a viewport into a two-dimensional document that extends, mostly, above and below the view the viewport provides. In an iPod-like user interface, the whole of the screen is a viewport into a document consisting of a network of nodes. And here is found an interesting connection to the desktop metaphor: Most document data models are networks of nodes: Web browsers’ data models of Web pages, for example. The iPod, therefore, achieves an elegant presentation of a document by being one step closer to the type of data model used to model many documents.
The iPod shows that MVC is not inextricably linked to the desktop metaphor: The iPod has a model, a view, and a controller, although each is simplified: The model doesn’t change until iTunes changes it, the view is a full-screen view of just one set of nodes which all are children of the same parent-node, and the controller provides no means of editing the content of nodes.
Not every element of the desktop metaphor is a success. The desktop metaphor is plagued by an innovation known as the dialog box. The dialog box is familiar to most users, and in its most florid examples brings no less joy than a long session of filling out tax forms. The dialog box was a feature, used sparingly, in early desktop metaphor user interfaces, to put a pressing matter in front of the user, in situations where the user could not proceed without at least acknowledging the matter, e.g. a serious error. Since then, user interfaces have experienced a metastasis of the dialog box as mediocre designers, armed with visual dialog box layout tools, have attached numerous multi-tabbed tumors to software. Pre-AJAX Web user interfaces brought the dialog box to its pinnacle of dominance: If you have ever filled out a multi-page “registration” for some Web site, you know it well.
The iPod does without dialog boxes, not least because text entry on an iPod would be brutally hard, but also because dialog boxes, like other overlapping elements, have no good visual representation on an iPod-sized screen. The lesson embodied in the desktop metaphor’s encrustation of dialog boxes compared with the iPods lack of such goiters is that designing the direct manipulation of the data model is hard, and widgets, dialogs, and menus are easy. The iPod escapes this damage by being an environment that is hostile to the concept and implementation of dialog boxes. The iPod is also a browser, not an editor, and therefore manipulation means viewing, not modification.
Can this simplified MVC user interface survive being extended into providing a first party call control user interface? Or a mobile commerce interface that brings iTunes Music Store into a connected iPod? While these are not small design challenges, there is reason to think this simple and elegant UI paradigm can encompass new functions without losing its qualities: First party call control is not document manipulation. It has its own very severe challenges, but it should not require a fundamental shift away from the iPod user interface. Similarly, shopping can be thought of as a series of database queries followed by the user browsing the results. This, too, should be possible to implement in the iPod paradigm without warping it out of shape. These examples are not randomly chosen: If there is to be a wirelessly networked iPod that includes a PLMN or VOIP telephony subsystem, these are the major components that would have to be added to the iPod user interface.
The iPod can also be categorized as a “one-handed” UI. One-handedness is also linked to the lack of overlapping elements in the iPod UI: If you don’t have a pointing device to access overlapping elements the way you would access papers on a desk, you should not have them in the UI. Failure to heed this distinction between one-handed and two-handed UIs leads to such kludges as “two level focus” and other severe compromises that are inherently incomprehensible and inexplicable to users. For examples, you can look to any mobile handset HTML Web browser that attempts to map the two-handed PC Web browser human interface to a one-handed handset interface. Microsoft still struggles to fully reshape the two-handed Windows CE user interface – which is a fine user interface if you assume the user is holding a stylus – into a friendly one-handed UI for mobile phones. Two handed UIs allow rich and ambitious interfaces, while the iPod’s strict observance of what the user’s thumb is capable of leads to an entirely different result.
The iPod, therefore, can considered to be a full-fledged example of a distinct user interface conceptual framework. It has all the characteristics of the consistent application of such a conceptual framework to an implementation. Graph or network traversal, one-node-at-a-time views, mapping of architectural aspects to the MVC design pattern, and extensibility to other application domains put the iPod UI alongside the desktop metaphor as something that we will likely see more of, in other types of devices, applied to other domains.
Tuesday, December 27, 2005
A Mobile User Interface Paradigm
The iPod interface is not original, and the USPTO has thus far ruled it isn’t novel. Creative Labs and Microsoft both hold related patents, and a hierarchical user interface is fundamentally unoriginal. But, as with Macintosh, taking a good idea more seriously than one’s competitors has given Apple the leading position in establishing the iPod user interface as the best example of a new paradigm.
That new paradigm can be summed up as “node by node visualization of taxonomy browsing.” Evidently I won’t go down in history as coining a new moniker as succinct as “desktop metaphor,” but the concept of taxonomy browsing on a small screen deserves almost as much exposition as the desktop metaphor in order to explore what it can do for small-device user interface.
On the iPod, the taxonomy is composed by iTunes and downloaded into the iPod. The iPod user browses the taxonomy node by node. That is, only one node of one taxonomy is viewable at any one time. That sounds rather unattractive, for a couple reasons: First, it comes off as limiting. Who would not want to see more information if they could? Second, “hierarchy” has become a bad word. Search-based file browsers on PCs are happily burying one of the worst user interface ideas ever created in computing – the file hierarchy.
And yet, the iPod is clearly a brilliant user interface. How does Apple turn limitations and what seems to be an out-of-style idea like hierarchy into user interface gold? With two broad approaches: First, accept limitations. Do not strain to deny them. Second, work to create the best user interface within the limitations. Much the same could be said about the difference between Lisa and Macintosh. Lisa did not accept limitations. Consequently, it was slow, and it highlighted the limitations of the Lisa platform. Macintosh accepted tighter hardware limitations than Lisa, and did what was needed to provide an excellent user experience within those limitations. Apple, in the person of Steve Jobs, and institutionally, clearly remembers those lessons.
In the iPod, limitations are ameliorated by the perfect interplay of the physical user interface and the “trail of crumbs” browsing interface. It enables the user to access one branch of a taxonomy so easily that the one-node-at-a-time limitation of the view into the taxonomy is no burden. In fact, compared to more-conventional taxonomy browsing interface of iTunes, it is a model of clarity.
Is this really a paradigm? Is it applicable to domains outside of music taxonomies? With specific examples thin on the ground one has to drill into the paradigm to come up with an answer. Here, I will state that answer in the form of how iPod-like taxonomy browsing fits the model-view-controller architecture for user interfaces: If the model is static, or nearly so, and if the model can be created from some interaction outside the hierarchical view system, such as the iTunes database, or some other database query, and if the results of that query form one or more taxonomies of categories, with nodes of manageable size, then taxonomy browsing iPod-style is a valid paradigm. Speculating on what kinds of applications fit this description, one can think of social networks, heterarchies like semantic networks (such as the CNet semantic network of news stories), and even first party call control interfaces, which I have seen implemented as a menu hierarchy attached to a tray icon.
I think this is enough to define a taxonomy browsing user interface paradigm, and test that node-by-node visualization and trail-of-crumbs forward/backward linking are a good visualization of that paradigm. I did not delve into physical UI and controller design, and it may be that the iPod wheel is key, but I will assert it is not, and that the mobile handset dpad is sufficient (perhaps this will emerge as a single-button versus multi-button mouse theosophical topic).
Now how about some iPod phone rumors!
Saturday, December 03, 2005
Why Mobile Java Has Not Converged on Compatibility
Mobile games are flourishing. Mobile games are modified – ported – dozens of times in order to run on dozens of handsets. That’s no way to make enterprise software, and the mobile game industry can support this practice only because most mobile games have no life cycle – they are not maintained or updated once they are released for a specific handset. If every time an update was released for a product the porting process would start all over, such products would never be economical or manageable.
It isn’t for lack of effort: Current J2ME standards show considerable progress over the MIDP 1.0 API standards. MIDP 2.0 provides easy standardized access to multimedia capabilities, an elegant and consistent connectivity model that spans connection-based networking, HTTP, and store-and-forward connectivity, and a form-based user interface system that enables custom UI widgets within a framework that abstracts display and input method differences.
Still, the mobile application environment has nothing like the application compatibility provided by PCs.
There are two main reasons for this:
- The J2ME standards are correct without being right. They are lawyerly in their concision. They can be defended as providing all the necessary definition – the contract the implementers must fulfill – and, yet, demonstrably they do not deliver a consistent target environment in practice.
- There is no body of applications to help identify slovenly interpretations of the MIDP 2.0 spec. The makers of compatible PCs had to show practical compatibility. The makers of J2ME implementations only have to smuggle their cruddy TextField and CustomItem implementations past a validation suite that cares nothing about the quality of presentation to the user.
Perversely, the lack of a practical compatibility test prevents the growth of a corpus of applications that would form that test. IBM’s PC attracted hundreds of applications that were being expanded and updated with an expectation of compatibility across IBM’s PC product line and new models before the first compatible clone appeared. These applications formed the basis of a practical test for compatibility. Mobile application compatibility has neither chicken nor egg.
Mobile search is one of the first areas where a mass-market application has to overcome the compatibility limitations of J2ME. Mobile search client applications will have a lifecycle. They will be updated. They will be released into a environment where it will be impossible to exhaustively test on every new handset. In short, they have to make the leap from the J2ME environment that is barely tenable for games, all the way to making it work for a mass-market product.
This won’t be easy, and many mobile search developers have concluded that J2ME is not ready to support such an ambitious application. They have stayed with presenting a user interface through the WAP browser, or they have started with smartphone platforms like Symbian and Windows Mobile as a basis for mobile search applications.
One problem with the latter approach is that Symbian and Windows Mobile phones constitute a narrow sliver of the market. There is also no great support among network operators and manufacturers to push smartphones. There is no distribution channel for large smartphone applications that must be installed from a memory card. Customers don’t know what benefit smartphones bring, and all the popular features like cameras, video, and mp3 music are available on inexpensive phones that do not tout themselves as “smart.”
The opportunity is in the billion or so Java-enabled phones that will be in the installed base by 2008 – within the next two or three product cycles for application development. If any mainstream phone will be “smart” by current standards, it will be mainly due to the price of hardware declining to the point where, for example, Nokia Series 60 phones become cheap enough they can come free of charge with a postpaid contract of a year or two.
So, can you just hang back and wait for the mobile application situation to fix itself? Only if it is satisfactory to see a billion people running around for several years not using your software. With numbers as big as they are, you have to try. So, what can you do?
You can:
- Use the available tools. As imperfect as the MIDP 2.0 UI tools are, they are better than rolling your own, which cuts you off from platform-specific input methods, like voice input, that are accessible only through the built-in UI widgets. MIDP 2.0 forms enable custom UI widgets with convenient interfaces to keypad and stylus inputs, focus management, and repaint management. Add custom widgets to your application to create powerful and distinctive user interfaces within the MIDP UI framework.
- Build tools where appropriate: While CLDC and MIDP 2.0 handle UI adequately well, and networking and multimedia quite well, they fail to address many practical issues in creating serious applications. Script-driven testing, logging, and update management are areas where you are on your own. Take the time to design these capabilities in harmony with the basic capabilities of J2ME.
- Write once, test everywhere, fix portability issues as if they are bugs – which they are. Don’t “port.” Compatibility is within reach, although it may not seem that way when first you begin to test an application across multiple KVMs. The numerous issues you will discover will make you want to give up the pursuit of compatibility and adopt the game publishers’ approach of creating a “port” for every handset. If you persevere past your first handful of handsets, compatibility on subsequent platforms will come easy, and by the time you are done with testing on 15-20 handsets, you will have achieved compatibility on dozens of handsets.
- Test everywhere, and use the update tools you built to keep your handset compatibility footprint growing. You will perpetually find new issues. But if you successfully fit the solutions to these issues into a single widely compatible build, you will have the ability to update your applications quickly and with minimal pain. This is the payoff: When you achieve wide compatibility, your next major application rev will ship with accessibility to the most customers, with the least support burden, and it will ship more quickly than your competitors’ applications. If you succumb to the port-per-handset approach, your rev 2 launch will suffocate under the load of porting, testing, and release management.
There is a reward for the first developers to cross the compatibility threshold in mobile Java applications. First-mover advantage in complex mobile Java applications is available, but hidden behind layers of challenges. If it was easy, everyone would be doing it.
Sunday, September 25, 2005
Why Everyone Won’t Succeed
There are general answers: there isn’t room in the market for all the ventures that enter it to succeed; some will be undercapitalized, some will fail due to project risk. But those are unsatisfyingly unspecific answers. To provide a really good answer to why most attempts at mobile search will fail, the answer must, at least, carve out a slice of the problem space, and it must say how this kind of answer applies to mobile search, and how it does not apply to startups in general, or search in general. I find that there is a fairly clear and informative answer to why some people – and I aim to make sure this means “other people” will fail:
Unified messaging, the focus of a company I started many years ago, was also a case where mastery of two very different disciplines was required. Then, as now, however, the difficulty of integrating across two disciplines where you will seldom find experts in both is hard to measure, and is often not taken into account in measuring the ability of a venture to capture and defend a position in the market. That is, this is both a hidden danger and an underappreciated quality.
It is, of course, easy to enumerate the features of voice mail, and of email, but, as evidenced by the implementations, most attempts failed to integrate the two correctly. Successful implementation of the idea of unified messaging required insight into the direction – not just the current position – of voice processing and messaging systems, mainly in the area of emerging APIs and standard interfaces, and it required integrating this knowledge right through to the business model and business development strategies. Even Active Voice, which is widely regarded as the exemplary case in unified messaging for having the best integration to messaging standards, did not until fairly recently, when media gateway nodes displaced voice processing cards as the interface point, fully abstract hardware from the unified messaging system.
In hindsight is it fairly clear: unless you see where messaging and voice processing are going, you can’t position yourself correctly among your technology providers and channels. There is no obvious choke-point here – no way to deny a competitor who has figured this out access to the same partners and channels, so this isn’t widely seen as a differentiator. But the fact that so few entrants to the unified messaging field got this right means that interdisciplinary integration probably is a significant advantage that some ventures will wield with strong effect against their competitors. Not all ventures share this attribute, so there is probably something to be learned about building a venture where interdisciplinary integration is a requirement for success.
Mobile search is, if anything, a more difficult problem than unified messaging. At least three major distinctive areas of competency have to be integrated into a successful system:
By “compatible minds” I mean people that can flex to fit the requirements of interdisciplinary innovation. Failure to flex means failure of the whole enterprise: mobile game coders will often fail to find the discipline to create an ambitious mobile application that works reliably. Symbian coders will fail to see that J2ME is an adequate platform, and that broad platform reach can be available through J2ME. Those steeped in search might fail to adapt to the limitations and opportunities of small-format presentation. And IN-experienced engineers can be too much in the telco mindset to integrate with anyone else with a more entrepreneurial world view. If the executive leadership of such an enterprise cannot encompass all that enough to evaluate if it is coming together or not, chances for success are diminished. If the participants reach only a minimal level of compatibility and fail to reach for ambitious goals in every distinct area of competency, the result will be easily matched and exceeded by competitors.
It can all be boiled down to four points:
- Only a small subset of ventures require innovation and audacity across multiple disciplines, so it isn’t a familiar problem.
- Apart from recognizing that some of these ventures are execution plays, VCs find the value of interdisciplinary innovation hard to measure.
- The participants in these ventures have to be inquisitive about each other’s domains of knowledge, and be able to seek innovation near those boundaries. The more dimensions to the problem, the less likely it is this will happen.
- The leadership, at the stages of founding, funding, and operating the enterprise have to be cognizant of their situation and act to make an interdisciplinary venture work.
But even simplified to this degree, interdisciplinary ventures are more complicated, and therefore more risky, than simpler plays. They are all the rarer in that, even when they are recognized it may only be to avoid them.
Monday, May 16, 2005
Interfaces Again
“A ‘pleasing’ user experience? And compared to what?” At the time, those were novel questions. The desktop metaphor design pattern and underlying architecture of multiple graphical contexts were solidly in place by then, but Steve Jobs was the first to get it right. The Mac had an interface that was up to standards that could be analogized to professional print layout design, while retaining all the structure of the desktop metaphor and windowing graphics system.
Since that time, the desktop metaphor got deconstructed into something more like the rock and roll magazine metaphor, as Web hypertext interfaces became the dominant area of interface design activity (desktop productivity having been pretty much done to death). Meanwhile, Sun tried to turn Java into a multi-platform GUI system, and, as if to illustrate the difficulty, is only now getting to a satisfactory result with the latest version of Swing, which still has no substantial library of applications.
Today, we are replaying this phase of user interface evolution in miniature. The memory and processor resources of mass-market mobile phones are about the same as the early Mac systems. A cut-down version of Java has evolved, in its MIDP 2.0 form, a usable user interface system for the small-screen medium – something short of a windowing GUI system, but good enough if one takes a more free-form approach to UI presentation.
The commercial and design contexts of mobile user interface creation are very different from the coherent drive to a desktop metaphor productivity suite that propelled early desktop GUI efforts. Mobile handsets have terrible user interfaces. Many mass-market phones don’t even try to have a good UI. Nokia’s Series 60 and Symbian UIQ are in danger of becoming obsolete before they fully evolve, having developed on too-limited platforms, and lacking a modern garbage-collecting implementation language. Windows Mobile is a very credible effort, with a long life ahead of it, but it suffers from Microsoft’s failure to develop momentum for Windows Mobile and of the curious and persistent incompleteness of the .NET Compact Framework to encapsulate all the platform APIs and become the unequivocal choice for UI implementation on the Windows CE platform. BREW, like Symbian-platform UIs, is stuck with C++ and an API that is inferior to the mobile version of Java, but BREW, at least, has been explicitly targeted at providing a customized user experience in Qualcomm’s new UIOne initiative.
Any serious effort to create a widely used GUI on mobile handsets has to encompass Java, BREW, and Symbian, and it has to provide a road map to cover Windows Mobile, Palm, RIM, and Linux-based 3G and VoIP handsets. It has to be designed in the context of present realities in handset hardware content, likely new applications like mobile video, and one-handed operation where the thumb – the least dexterous digit – is made to do all the work.
The Web has influenced UI design again. This time it isn’t by deconstructing the UI into an interactive hypertext Web, but by being the place where user interface has evolved toward search being the starting point of interaction.
So this is the environment into which my current effort at creating an ambitious non-game mobile application is launched. Compared with desktop GUI applications, the evolutionary stage of mobile platforms makes things more challenging: more variation in the platform. More technologies to understand. A necessarily multi-platform implementation. Fewer design rules, and certainly no Steve Jobs and his salutary UI fascism, but in a world with a lot more interactive design sophistication.
Success requires remembering this evolutionary context and using the analogies it provides to navigate the new challenges. Those new challenges, and the solutions, will write a new chapter in UI design.
Wednesday, April 27, 2005
After Games
I am no longer working at a mobile game company. Not because I became disillusioned with mobile games – I’m still advising people and companies in the mobile games arena. But the mobile games train has left the station. The time for startups in mobile games – at least until some fundamental shift occurs – has passed, and acquisitions and consolidation are a big part of mobile game news these days. I look forward to Kayak more-fully realizing the potential of the products the Chasma team created.
Mobile games transformed my view of a new vehicle for applications delivery. And, while mobile games are now a battlefield for larger companies, new areas of non-game mobile applications are opening up. The same low-friction channels and staggering numbers of mobile customers will do for mobile search and rich forms of mobile media what they did for mobile games. In many ways, the landscape is like that of mobile games three years ago: the technologies and delivery vehicles are there, waiting to be adroitly exploited.
Even more exciting than the mobile games business, where m-commerce and billing-on-behalf-of were the keys to making large piles of money from simple products, the business model for new fields like mobile search is still malleable. Stunning breakthroughs is business strategy will unfold alongside what are likely to be the most sophisticated mobile applications ever created.
Mobile search holds the key to a shift in the mobile telephony user’s usage patterns that is far more powerful than features like push-to-talk that, up to now, form the basis for differentiation among mobile service offerings. It is an exciting time in mobile applications that will reverberate through the whole structure of the mobile network.
To take but one example:
Google’s brilliantly simple user interface has conditioned people to the belief that search is simple, because it is simple to use and delivers the right results so reliably. This is, of course, a misconstruction of what is, in reality, a subtle, deep, and complex system that happens to work very well. Even more than Web search, mobile search will tie together information sources from the mobile network, the Web, and numerous structured, specialized feeds into a product that appears simple, but represents a new level of sophistication in search, as well as breaking new ground in mobile applications.
Tuesday, January 11, 2005
Content Networking by the Numbers
Google has indexed, as of the moment I write this, 8,058,044,651 pages. Google also indexes about 1 billion images and about 1 billion netnews postings. In a masterful piece of S-1 filing divination, Tristan Louis estimated the size of Google’s computer infrastructure: 719 racks; 63,272 machines; 126,544 CPUs; 253,088 Ghz of processing power; 126,544 Gb of RAM; 5,062 Tb of hard drive space. You can find his research on the topic here: http://www.tnl.net/blog/entry/How_many_Google_machines.
Pretty impressive. Google users evidently think that Google finds what they are looking for. So, not only is Google large, it has successfully found what most users want to find. Google has made meta-search an anachronism. Few now have the resources to catch Google.
Any flaws? Some people complain that Google can be gamed. Others complain that Google censors. But the real issue is that Google indexes only a tiny fraction of the Web. This analysis - http://www.brightplanet.com/technology/deepweb.asp - claims that fraction is somewhere between 1/120th and 1/620th.
An interesting aside in Bright Planet’s analysis is that original deep Web content now outstrips printed content. Yes, the Web is now bigger than the printed word.
Bright Planet’s analysis excludes images from the size measurement of the un-spidered “deep Web.” So where do we look to get a handle on the size of multimedia content in the Internet? In this case, we can look to measures of Internet traffic – specifically P2P traffic.
The numbers are stunning: CacheLogic, a maker of traffic management and network intelligence (deep packet inspection) gear, found that P2P traffic ranges from 55% to 80% of the bits traversing the Internet (http://www.cachelogic.com/research/slide12.php). The Web, which is 120 to 620 times larger than Google has indexed, is only 5% to 20% of Internet traffic. A single movie or TV show can significantly drive traffic levels in an ISP’s network. Boggling, but what does it all mean? Here we can turn to the Eight Fallacies.
Topically, the Eight Fallacies were formulated by Bill Joy, Dave Lyon, Peter Deutsch, and James Gosling – some of the brightest of Sun’s luminaries – as Sun was formulating its approach to the mobile computing market. If you don’t pay attention to the numbers, you can fall into one or more of the Eight Fallacies:
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- There's a single administrator
- The topology won't change
- Transport cost is zero
- The network is homogeneous
It could take a book chapter to fully elucidate the meaning of each of the Eight Fallacies in the context of content networking. But the main point is that content is so big that the Internet will be designed around moving content. The Web is just the literate scum floating on top of an Internet that is rapidly evolving toward the post-literate masses. Never thought you anyone need those monster petabit routers? Think again. Asymmetrical last mile OK? Maybe not. Many other apple carts will be overturned.
What category of application will drive the next big shift in Internet traffic? Content networking will probably be a big part of that next killer app.
Sunday, November 28, 2004
Not Exactly TV
Tuesday, November 09, 2004
Mobile Entertainment: the Current Landscape
- Handset hardware platforms that are less capable than most handheld game consoles in graphics, processor power, and storage, but universally capable in anytime/anyplace Internet connectivity.
- Hundreds of millions of customers accessible through a relatively small number of channels. Some, like Vodafone and Verizon, have achieved Wal-Mart-like domination of m-commerce in their territories. But, overall, the advantage is with content providers. The terms for mobile commerce are most favorable in the most mature markets.
- Hundreds of millions of new handsets each year that both expand the number of customers and upgrade older customers into a mobile networkthat includes mobile commerce and entertainment platforms.
