Android: What problem does it solve?

At the recent Smartphone Summit at CTIA, I sat on a panel with Johan Sandberg, CEO of UIQ. When asked about what was needed to make mobile services more successful in the future, Johan smartly replied “we need to make it cheaper to fail”. I could not agree more. One of the major differences between the wireline Internet and the mobile Internet is that you can successfully start-up a wireline Internet company using a couple of credit cards. Development and distribution is relatively low-cost given that most people are reachable using one of three browsers supporting XHTML and AJAX technologies. If at first you don’t succeed, tweak it and try again. Everything is in a perennial “beta” state.

Compare this with the mobile Internet. The browsers are sorely lacking in features and fragmentation is considerable given the impossibility of most subscribers “upgrading” the browsers they already have. Network latency only compounds the problem, leading most developers seeking widespread adoption to look towards client-server architectures.

We currently support client development on Windows Mobile, BlackBerry, Palm OS, Java, Symbian Series-60, UIQ, BREW, and we are hard at work on the iPhone as well as on various interpretations of AJAX and Linux. I truly believe that you have to be willing to roll up your sleeves and do the hard work if you want to be successful in today’s mobile environment.

This week, Google finally made it’s grand entrance into the mobile arena with Android and the Open Handset Alliance. I have already had a dozen people ask me what I think about this move. My initial reaction was more of a “so what”.

This seems to be the case of a company not really understanding what the market needs. If I look at the current value chain or ecosystem and their needs, neither Android or the Open Handset Alliance seem to be nailing anybody’s need.

Let’s start with developers. There is no doubt that developers would like to have a deeper and richer programming environment on the phone. But if you spend time with the OS vendors for phones today, they will tell you that they could offer a richer programming environment but they do not for reasons of security and privacy — mostly brought on by the mobile operators that buy these phones to resell to consumers. Until the operator’s indicate that they will relax these concerns, I am skeptical that we will see widespread availability of truly open Android phones (vs. neutered Android phones).

Furthermore, Android says nothing about addressable market. Other than hobby shops and verticals, most developers need to focus their efforts on the devices used by their target demographic. For Android to be truly relevant, millions will likely need to be sold. Apple has done quite well with the iPhone, but consumers by the iPhone based on the form factor and user experience — not the operating system. Android will need to be in some really cool devices from really strong brands to see that kind of success.

Let’s look at the handset manufacturers. The handset manufacturers sell phones based on form factor, price, and 2-3 features understandable by the mass market. As I pointed out in a recent post, when I was in the UK a couple of weeks ago, the OS was not considered a feature of the handset — you could not tell what OS a phone used at the point-of-sale. For most manufacturers, most of the profit associated with a new handset comes in the first couple months of launch — when the price point is high and there are no competitors. As such, most handset manufacturers are incentivized to user mature operating systems for their big volume handsets — no sense in risking profit for something that has no material relevance at the point of sale. Hence Nokia’s allegiance to Series 60 and Motorola’s investment in UIQ. The one shining light for Android is if they provide a “killer app” that is exclusive to the Open Handset Alliance handsets.

Let’s look at the mobile operators. Mobile operator’s are looking for ways to differentiate from their competitors, increase subscribers, reduce churn, and increase ARPU. One way they do this is to get exclusive handsets or first mover advantage. So it is not surprising to see some operator’s on the list of partners. Traditionally, mobile operators have struggled with handset manufacturers to differentiate the handset. It was in the handset manufacturer’s benefit to keep differentiation low so they can increase volumes and reduce costs (one reason why GSM handsets are cheaper than CDMA handsets). Having an “open handset” is one way to get that differentiation. But “open” brings with it the challenges of “security” and “privacy” that I mentioned above. It cuts both ways. As such, I expect most operator’s to neuter Android handsets to meet their own requirements, subsequently reducing the addressable market for developers.

Lastly, we have the consumer. Consumers mostly buy handsets based on form factor and price within a “lifestyle” category — messaging, music, and photography being three of the more common. If the Android can create a new category that is meaningful to the consumer, then I think it has a chance. If not, then and Android phone needs to compete with the all of the other phones with respect to form factor and price.

Will Android solve world hunger for data services? I truly hope so. I’d love to reduce the cost and time-to-market for innovative services. I’d love to make it easy for subscribers to discover new services and developers to distribute the ones that they build. But nothing in the press releases or websites leads me to believe that they are solving problems in the critical path. I hope I am wrong and I am looking forward to the SDK for a glimpse on which way the wind will blow.

 

Dumping Google

MocoNews opines about Bill Gate’s comments regarding Google products in the smartphone space in the NY Times. The quote of interest from Mr. Gates:

“How many products, of all the Google products that have been introduced, how many of them are profit-making products?”

That quote is really quite interesting because it illustrates how an “old school” company can fail to react to a disruptive company when it continues to play with using the old rules.   Mr. Gates is measuring (or trying to get the industry to measure) Google based on the profits of any one product.  Google, on the other hand, is operating their business under a completely different set of rules.  Google has a “cash cow” in their advertising business and is willing to enter new markets with loss-leader products to simply acquire new customers.

Before Google had a profitable advertising business, they spent investor’s money to build out a distribution network on the backs of search.  They are effectively pursuing the same strategy with mobile — spend the money to get the eyeballs.  If you have enough eyeballs, you will find a way to monetize.

Having spent my formative years in the early Windows PC era (at Gateway, AST, and Tandy), I don’t have a lot of sympathy for Microsoft.  They were quite adept at bundling “less than great” software into the operating system, making it all but impossible for third parties to create viable PC software businesses.

But herein lies my anxiety about Google’s approach.  By entering these markets with zero-cost solutions, they make it difficult for non-Google companies to offer innovative solutions with a viable business model.

I am all for lowering the cost of mobile data services.  As I have lamented frequently in this blog, I believe that the total cost of mobile data (TCMD) is the biggest barrier to adoption.  But I don’t think its healthy for a marketplace when a gorilla “dumps” products below market costs.

From my perspective, this borders on predatory pricing — selling a product below cost with the objective of driving other firms out of the market and then raising the price to monopoly levels.

 

Google Gears and mobile platforms

Google had a couple of interesting things to say this week, along with a few words from Microsoft’s Bill Gates and Apple’s Steve Jobs.

First up was Google releasing Google Gears, a technology for developing off-line Web 2.0 applications. Adobe is doing the same kind of thing with Apollo. This type of technology enables what I call “intermittently connected” applications — applications which need to operate in both a connected mode and an unconnected mode. This capability is clearly important to any road warrior carrying a laptop. Business models continue to make airplane connectivity a rare possibility, much less simple and cheap.

Less obvious is why this is so important on mobile. Having spent a bit of time over the last 5 years involved with VCs and corp dev types, I can’t begin to count how many people think that with mobile networks attaining higher bandwidth and greater coverage, the browser is good enough.

Theoretically, this might be true, but in reality I think these people don’t truly use mobile data services outside the occasional test. In many ways, its the same 80/20 problem I talked about yesterday — even if the network is available at high speeds 80% of the time, if the 20% use cases fall off a cliff (airplanes, urban canyons, rural motorways), the overall value diminishes disproportionately. Mobile sets an expectation for access everytime and everwhere. When it fails to deliver on that expectation, trust is destroyed and subsequently value.

With Google Gears extending AJAX and Adobe Apollo extending Flash/FLEX, we have two well funded and smart companies building platforms that can address this problem. Importantly, building these platforms based on existing technologies promises to leverage existing development & creative communities.

Next, we have Google’s Eric Schmidt talking at the Wall Street Journal technology conference. Speaking at the conference, Mr. Schmidt talks about Google continuing to invest in more mobile applications –

Instead of saying ‘mobile, mobile, mobile,’ I should be saying ‘apps, apps, apps’

Lastly, we have Bill Gates and Steve Jobs speaking at the same conference. As reported in InfoWorld, both Gates and Jobs believe in rich clients. Gates believes the future of computing is what he describes as “rich local functionality” where “it’s using local richness together with richness elsewhere.” Jobs points to Google Maps functionality embedded on Apple’s iPhone:

The experience is unbelievable, way better than a computer. And that client app is the result of a lot of technology on the client. And you can’t do that stuff in a browser

I am heartened to see consensus building on the mobile programming paradigm.

Update:

I have had a couple of readers ask me if this is an anti-browser strategy. Far from the case as both of these solutions leverage the browser in their rendering engines. What this does do is strengthen Nokia’s strategy for open sourcing their browser (WebKit) and weaken “closed” browser solutions by Openwave, Opera, Access, and Teleca. As handset manufacturers implement these platforms they are going to want to avoid duplicating protocol stacks, parsers, DOMs, and renderers — hard to do when the browser is a black box.

 

Buying smartphones

Dean Bubley has a great post about smartphones in his blog Disruptive Wireless. He looks at how smartphones are perceived, sold, and bought throughout the world and comes to an interesting conclusion. To paraphrase:

• in the States, smartphones (RIM, Palm, Microsoft-based) are about the end user
• in Europe, smartphones (Nokia S60) are about the handset manufacturer
• in Japan, smartphones are about the operator

I find this conclusion eye-opening. Even though I have been aware of how different people segment the smartphone business (typically, keyboards vs. open OS), I had never overlaid that segmentation on market regions and appreciated the consequences.

What would be interesting to understand is whether stateside smartphone consumers (who consciously bought a keyboard phone, presumably to do e-mail) spend more on non-essential mobile data services than European consumers (who buy a phone that just happens to be an open OS). Just because stateside consumers bought the device to use mobile data, they may be solely focused on email and unwilling or unable to pay for ancillary services (not atypical if the phone is a corporate purchase). Likewise, the European consumer may not have bought the phone to use mobile data, but demonstrate more consumerism.

I would be interested to learn if there is disparity between what is used (beyond messaging) and how frequently it is used. At it’s extremes, I would expect that this would result in a greater opportunity for consumer services in Europe that function on a premium transaction basis (i.e., opportunistic business models) and subscription-based enterprise, small business, or executive aligned services in the States. Companies like Plusmo and Nokia Widsets, who offer direct-to-consumer widgets, ought to see a very different set of widgets being used.

 

JavaFiX

Sun’s JavaFX announcement at JavaOne is quite sad.  For me it underscores the opportunity that Sun had ten years ago when Java was the way to turn the browser into an operating environment.  An opportunity that was frittered away as Adobe’s Flash, Flex, and Apollo, Ajax, and Microsoft’s Silverlight grabbed the spotlight.

Lets assume for the moment that JavaFX truly is more than marketing sheen on Savaje intellectual property glommed on top of Java ME.  Lets assume that it really works.

In mobile, a successful application development environment will demonstrate:

• a low-cost means of developing applications & services that work across a wide-range of handsets
• a means of distributing those applications cheaply

I used to develop software for PCs back in the early-mid 90s.  Several events occurred in the last 8 years or so that made developing software significantly more cost effective.  First, the emergence of the web and standardization around browsers meant that software developers no longer needed to develop different applications for different computers with different video cards.  An emphasis on client-side software development was replaced with an emphasis on server-side software development.  Second, in addition to being a programming platform, the web served admirably well as a distribution platform — software companies no longer needed to offer shrink-wrap software at retail or strike volume deals with the PC manufacturers, people could send URLs or content to their friends via e-mail, post it in their blogs, etc.

In mobile, this type of development approach was not possible.  Network latency, connection costs, and browser variations made server-side solutions less than satisfactory (hence the trend to on-device portals).  This created an opportunity for a big win on client software. Sun rushed into the fray with Java, as did Qualcomm with BREW.  Unfortunately, going mobile was a huge learning curve for mobile developers as they needed to learn new programming paradigms and handle a myriad of device compatibility issues — without end.

Perhaps more importantly, in mobile there is no means for distributing applications (whether they be Java, BREW, Flash, etc.) cheaply.  Qualcomm did an admirable job by managing the service for their customers.  Sun never really got into the game as their operators all did something a bit different from each other.  Making matters worse, mobile operators have priced mobile data out of the reach for most consumers.

So does JavaFX stand a chance?

When it comes to developing client software, Java and BREW are still the technologies of choice and will be until the walled gardens are torn down and AYCE mobile data plan adoption is greater than 30%.  3G networks have reduced network latency to a point that its less of an issue for most services, but the cost of using the network is still too high for most consumers.  This means that their mobile applications need to act like PC clients of 1995 — intermittently connected with predictable cost.  When data plan penetration tips, I expect to see server-biased technologies take hold — Flash/Flex and XHTML/Ajax dominatings — with web browsers and widgets providing distribution.

JavaFX will be there, but its not very important.

 

Connecting to Search

Interesting survey results about mobile search were published by iCrossing today. The press release can be found here. Keep in mind that iCrossing is a search engine marketing firm.

The results indicate that 30% of mobile subscribers access the Internet on their mobile devices with 50% of those accessing it several times per week. 75% of those subscribers access the mobile Internet to conduct searches on their mobile devices. Not surprisingly, local information tends to dominate search and subscribers are unwilling to go beyond the second page of search results.

According to the survey, the respondents were essentially self-selected via the e-Rewards program. One of the criteria for selection was that they use the mobile Web — which makes me wonder what that 30% number really means!

While I question the methodology, the conclusion contains many points I have talked about in this blog. Some of the points made:

…sites must be optimized carefully so they can be captured in a maximum of three keywords. Convenience, ease of use, speed and relevancy are the values that must remain at the forefront…

According to the survey, consumers preferred Internet-branded search over the operator-supplied search functionality. I wonder how much of this is simply a brand doing its job — I know what to expect of Google on the web, so I expect the same thing of Google on mobile. I don’t know what the MNO’s brand means. If I don’t have the patience to experiment, I use the brand that I trust.

This does not mean that the operator is fighting a losing proposition. One thing rings out loud and clear — the results need to be relevant to the subscriber and the subscriber does not want to type in too many keywords. The operator can provide context around local search that Google would die for (location, location, location).

If I was an operator, I would have one of two decisions to make: (1) try and create a local search business that competes with these brands (using location etc. as a competitive advantage), or (2) use location as a revenue generator that enables third parties to compete on search. I would choose the latter — sell location data on a per-click basis to Google, Yahoo, Microsoft, etc. (as long as the subscriber opts-in, of course) and let them compete in their core competency.

 

RIM to Broaden Software Offering

The Wall Street Journal reports that RIM will make software available [$] for non-RIM phones that offer some of the features and services found on BlackBerry devices. RIM plans to sell the software direct-to-consumers via their online store or through mobile network operators. Engadget Mobile reports that it will include virtualization software that provides the ability to run third party programs.

According to the Wall Street Journal, RIM has decided to launch the new software because customers want more choice in what device they buy. I believe customers probably refers to enterprises rather than consumers.

As mobile email solutions (and increasingly other sales and customer management solutions) penetrate down the corporate ladder, the cost of devices becomes an increasingly bigger issue. Microsoft can now be found at price points below $100, making Windows Mobile based phones an arguably cost effective substitute for the enterprise. By making RIM software available on Windows Mobile devices, RIM can take the cost of the device out of the decision criteria, while the switching costs of the server remain. Smart move.

Some might argue that RIM is taking a first step towards exiting the device business — a business fraught with low margins and inventory risk. I don’t think this is the case.

Guy Kawasaki has an interview with Seth Godin, author of “The Big Dip“. In the interview, Guy asks whether Apple should quit the PC business. Seth Godin responds:

Apple has already crossed that Dip, big time. Not the “personal computer Dip” but the Dip of “style-conscious, designer’s, multimedia, student, family computer.” … Sure, if Steve hadn’t been arrogant, they could have been best in the world at a much bigger, much juicier market. But they’re not. Once they deal with that—and I think they mostly have—then they can erect a wall behind them, a bigger dip, one that prevents others from following.

While I don’t think RIM has achieved as much success as Apple with respect to owning the category, I do believe they understand that RIM as a brand is stronger with devices than without. I expect that RIM astutely sees the dip ahead of them and, in the words of Seth Godin, is making plans to stick through it.

 

Microsoft Color Barcodes

mocoNews and the BBC report on Microsoft developing a new color barcode solution (“MS Color Barcodes Will Store More Data…” and “Colour barcode system to hit DVDs“). These new barcodes can store up to 3,500 alphanumeric characters.

As I have mentioned in a previous blog entry (“Mobile Barcodes and Semacodes“), there is clearly a potential market for this type of technology having proven itself in Japan. As pointed out by James in the mocoNews piece, this is yet another mobile barcode and risks fragmentation of the market. James also says that with more storage capacity, there are likely more creative applications that can be built with the mobile barcode.

My belief is that in the near-term, barcode interoperability is more important than the density of the barcode. This does not mean that the world should only support one barcode technology. What this means is that consumers can’t worry about which application on their phone to use with which barcode. It is absolutely critical that if a consumer sees something that looks like a barcode, they know that their phone can read it. Without consumer adoption, brands won’t use barcodes in their products and the economics collapse.

Mobile operators and handset manufactures need to take this to heart and insist on clients that support multiple barcodes. Brands should look strongly at choosing barcode technologies that have broad base support.

I have mixed feelings when it comes to the need for higher density mobile barcodes. In mobile today, there is a high cost to connect to the Internet: it costs real $$ to use mobile data, there is a latency with each request/response, and non-integrated applications leads to a lot of context switching in the user experience. If these costs continue, having a higher density mobile barcode is important because the data in the barcode will either need to stand on its own, or it will have to be compelling enough to incent the subscriber to connect. If these costs are removed, there will be little reason for higher density barcodes as they can simply store URLs.

Either way, I am dubious that 3,500 characters provides either enough information for compelling disconnected applications at the cost of further fragmenting the market.

 

Mobile User Experiences

A very good post on a topic near and dear to my heart — the ever insightful Marek Pawlowski writes about Microsoft’s ZenZui user interface.

I have been working on user interfaces for 20 years, initially doing artificial intelligence research for fighter pilot decision aids. One of the interesting things I learned way back then from some cognitive scientists (anecdotally) was that when people had a complex set of controls, they thought the organization inefficient, but when they organized it themselves, the result was even more inefficient. A question that I always wondered was even if the controls were more inefficient, did the user either perceive that it was “better” or were they “happier” with the result (i.e., happiness trading off for efficiency).

Later, as I worked on the first desktop shells for Windows 3 up through 95, I worked on a variety of organization paradigms and I came to believe that they all tended to help me find the top 7 or so things I liked to do, but they failed pretty spectacularly as we moved beyond the “top of mind”. The less frequent I used something, the less useful a spatial system worked. Even semantic tools seemed to fail (for me). One of my favorites (which I did not work on) is still around, called “The Brain“.

I have been doing mobile now for close to ten years and I think the same issues arise. I have worked with lists, folders, buttons, zooming, transparency, you name it. Some are certainly more fun and have a lot more gee-whiz, but I am not convinced they are really solving a problem. And perhaps that is the problem — the problem has not been properly defined.

There are three things that you generally want to do:

1. access an application/service that you frequently use — what I call top-of-mind
2. access an application/service that I use infrequently
3. discover and access an application/service to meet some need (perhaps well-defined, perhaps ill-defined)

In my experience, most phonetop user experiences do a good enough job solving number 1. Some are more entertaining, some may require a couple less keystrokes, but all in all, they are pretty much on par.

In my experience, most phonetop user experiences fail to solve the second problem. Zooming and transparency all help deal with one big issue on mobiles — maintaining context (where am I?). But in many ways, they all begin to feel like “favorites” in my browser. And on a phone, the penalty of traversing through multiple levels of selections is very high since, unlike PCs, the subscriber usually needs to manage context in their head (they don’t have a big UI to provide visual cues).

Lastly, most phonetop user experiences punt on the third problem. You have to bring up another application called Search…. which might not even find an application already on your phone that you don’t know about.

On the web, most people I know have largely abandoned favorites and now simply type something they remember in Google and expect to get what they want within the first couple of results. To me… this is an unbelievable step forward since I no longer have to remember some potentially arbitrary organizational pattern constrained by the phonetop.

Typing on mobiles is notoriously difficult. But one company in Canada is using their predictive text expertise to solve this very problem. Check out what Zi Corp is doing with their QIX technology. While this technology may appear to be “boring” since it does not need an alpha channel or SVG, but more importantly, QIX scales… it solves all three problems I defined above and will work even as the mobile web reaches in size to the traditional web.