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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yo mama is a PDA

What is a smartphone?

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

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

The PDA design legacy

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

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

An awkward relationship

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

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

The new need for a better phone OS

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

The new requirements:

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

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

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

The new wave of smart device operating systems

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

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

I, for one, welcome our new Android overlords

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

Is Indiana close to Nirvana?

If I can install Debian I can install Solaris

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

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

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

The boundaries of the Sun King's domain

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

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

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

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

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

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

What makes a modern desktop

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

Seduction

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

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.