Two weeks after I wrote Android App Ops is a Step Forward, Google has disabled/removed the permission manager. After the Android 4.4.2 update, invoking the App Ops app results in a RuntimeException.

The R.I.P. permission manager, a very important capability for end-users, WAS a step forward; we are going backwards here.

Google’s response for why they removed this capability (via ReadWrite) is as follows:

Since Google never supplied documentation for the accidental release of the permissions manager, Android developers had no opportunity to prepare for the possibility that users might be withholding individual permissions, or to warn users about the possibility that an app might break if they did so.

This will require that developers be aware and properly test for scenarios related to restricted features/APIs not being available, and perhaps new documentation related to permissions guidelines for developers.

Seems the whole thing was not given proper thought.

It is of extreme importance to end-users to re-add this winning capability as soon as possible.

The disappearance of App Ops is alarming news for Android users. The fact that they cannot turn off app permissions is a Stygian hole in the Android security model, and a billion people's data is being sucked through. Embarrassingly, it is also one that Apple managed to fix in iOS years ago.

Interest-based advertising, targeting specific users on your site based on their cookie ID.

I am not sure which one above is the one getting triggered, but from my perspective, the Ads being served have NOTHING to do with my blog content! Instead they seem to be related to my “search history”.

As a publisher, that is NOT what I want for my blog — I want to control the kinds of Ads that are served on my blog. I want them to be content-relevant, the way they used to be.

Google provides a way to “opt-out” which I haven’t tried yet, that supposedly allows you to “opt out of ads shown to you based on factors such as your interests and demographic details on your computer’s browser.” — whatever that really means.

I am starting to look for Ads alternatives — as I said, as a blog owner I want to control the kind of Ads that are served on my blog — which in my case I want them to be *content-relevant Ads*.

Perhaps I have problems with the Google Crawlers?

Does anyone know how (as blog owner) I can control the kind of Ads that are served by Google?

Do you have an alternative to Google Ads or suggestions for me? Thanks in advance.

As you can see, the majority of the devices out there, close to 60%, are still 2.3 (Gingerbread). This is followed by ICS with close to 21%. Froyo 2.2 is 14%.

I hope that by March (but more likely, summertime or later) of 2013, that by then the majority of the Android devices out there are 4.0+. This would make the Android app developer’s life in general much simpler — by (1) minimizing the number of major Android platforms to deal with, and (2) making it easier/cheaper to implement (or move up to) the recommended Android design guidelines. The result of this includes (1) cheaper to develop/maintain apps, (2) consistent apps per developer, and (3) consistent look/feel/behavior across the app market.

For this to happen, device manufacturers and operators must help transform the above piechart to be mostly 4.0+ Android devices. They can help by literally selling less (and even better, stop selling) Gingerbread/2.3 and older devices. If you look around you will see that operators are still selling Gingerbread devices. And we need Google to have more cojones with respect to this and stimulate, if you will, both the device manufacturers and operators to move forward — this transition is taking forever! (Note: Gingerbread was introduced on December 6, 2010.)

Some customers may leave feedback as “why the app does not follow the Android UI guidelines”, or “why the app doesn’t support the ICS UI paradigm” — but again, 4.0+ is just a smaller fraction of what is out there!

Part of creating a product is providing proper customer support throughout its life-cycle. A product life-cycle begins with product envisioning, followed by definition, followed by create/build, followed by going to market (which on itself consists of different aspects including customer support).

Vizio has failed to deliver my product. And has failed to make *me* a satisfied customer — after waiting for almost a month for the delivery/return-process to work itself out, they could have sent me the package again, perhaps with rush delivery for all the troubles I have been through. But they claim they cannot do that (I don’t believe them); they should take a lesson from Zappo’s book. Instead they will refund me and I have to reorder. But I won’t reorder. Maybe their Co-Star is a kickass product, maybe it is not; the only way I am reviewing the Co-Star is if they send me one. In the meantime, I will continue using my Android tablet for Netflix streaming and apps on my TV. I will wait for a competing Android TV product, and maybe I will end up buying an Apple TV.

Read more on the comments section.

I will categorize this one under “#FAIL”.

I believe SmartTVs will open new/great opps for content/developers; and this will be especially true when intersecting this w/ Mobile.

So, to begin researching this in more detail, I’ve ordered Vizio’s Co-Star. Based on Google TV (click on the previous hyperlink to see the specs) it has everything needed to play/hack-away.

Crafted by VIZIO’s years of entertainment expertise, Co-Star packs the powerful features of Google TV into a sleek, intuitive interface. Combining live TV, the Web and apps into one experience, it allows you to search and access content from all of them without interrupting your viewing.

Of special interest to me is the combined experience across TV & apps that the Co-Star supports; think about it, your app overlaid on top of the video stream — if this plays out as I hope, this is very, very, very powerful, and is what I’ve been waiting for:

While the major Google I/O fun is happening in San Francisco on June 27-29, some of us will stay behind and run/participate at the Extended version of Google I/O — in my case, Google I/O Extended Austin.

The Oracle vs. Google case on Java is such a precedence case that any ruling on APIs vs. copyright might open a can of worms. The outcome of this ruling literally will affect any software company and developers designing APIs (and protecting those as Intellectual Property).

(I personally believe programming languages and its APIs should not merit copyright protection — languages are the means of unique expression, not the expression itself).

In the meantime, Europe courts just ruled on this exact matter (SAS Institute Inc. v. World Programming Ltd) against copyright.

“Google’s position is that APIs, like computer languages, cannot be copyrighted; Oracle disagrees.”

“…if the jury finds that Google infringed and that Google’s actions don’t qualify as fair use, then the copyrightability of APIs comes into play.”

“The primary issue that might be made moot is whether Oracle can even make a copyright claim. The judge has made clear that he reserves the right to rule on whether APIs can be copyrighted under the law. But presumably, he’d rather not if there are other means to resolve Oracle’s claim. If Google is found not to have infringed, he doesn’t need to rule on the copyrightability of APIs. If Google is found to have infringed, but to have done so as permitted under the fair use doctrine, he also doesn’t need to rule on whether APIs can be protected.”

Above: note how the judge is trying to avoid having to deliberate on APIs and Copyright; trying to stay away of such “debacle” and its consequences.

On Thursday, that very question was resolved in Europe: The Court of Justice of the European Union ruled in a similar case, SAS Institute Inc. v. World Programming Ltd, that neither the functionality of computer program nor the format of its data files are expressive enough to merit copyright protection.

Some background: I spent many years as an individual contributor to a number of J2ME expert groups including MIDP 2.0, MIDP 3.0 and a number of J2ME APIs ~ around 10 different JSRs over 8+ years. I was a huge proponent of Java for mobile and still am.

In the next couple of days, the jury will decide in the trial of Oracle vs. Google on Java.

The Google vs. Oracle Java debacle is in my opinion, for the most part, the result of how Sun left behind a loosely defined and ambiguous Java, from the perspective of open source software (OSS).

To attract developers and win the community, Sun played the OSS “game”; but did it partially. I recall Schwartz claiming Java as open source, then trying to understand GPL classpath exceptions and whatnot.

Then Google started Android with Java, and Android became very successful.

As Sun shopped themselves around, Oracle, a coined-operated company, clearly understood the monetization opportunity that presented itself with Java and its state.

And here we are today.

Everyone in the business of SW knows that 3rd party SW must be licensed. The questions are “what is SW?”, “what requires a license?” and “what is up for fair use?” Is it the Java Programming language and related core APIs? The Virtual Machine and related bytecode? What about all the APIs developed by the Java Community and led by other companies such as Nokia and Motorola and others? All the above?

Google made a bet and decided to take risks — perhaps based on Schwartz’s OSS claims or the claims from the JCP vs. “fair use”.

But soon the court will decide, and all this will be over. Google may have to pay a lot of money for using Java, or maybe not, or maybe some kind of IP + $ arrangement is done between the companies, or maybe Google ends up using a different programming language on top of their VM.

The latest big news on Android is Google’s acquisition of Motorola’s Mobility group.

And I have to say, I wasn’t expecting that one.

The main arguments floating around on the acquisition are:

Patent play, driven by the patent war including the recent Nortel patent acquisition by Google’ competitors

Hardware play, which better positions Google against Apple

My thoughts

It is a patent play

TBD is the impact of this on Google/Android partners — this is huge with respect to Android partners, creates a love-hate relationship, and definitely will have a negative impact on their partners, their growth, their confidence, and as a consequence, will affect Android’s growth; it is the way things work. While Android’s global growth was leveraging big manufacturers such as HTC and Samsung, now, unless some kind of awesome agreement is done with the partners (see last bullet), Android’s success has now reverted mainly onto Google’s shoulders

Google must to decide very fast what they want to be: a SW or HW-or both kind of company

Google *must* keep the IP for the patent wars, and spinoff Motorola as a subsidiary — running a HW company is just a different kind of beast.

While maintaining ownership of the new IP, Google shall give royalty-free access of the Motorola patent portfolio to Open Handset Alliance (OHA). This will 1) provide incentives to existing OHA partners, 2) provide incentives for new partners to join OHA, and 3) allow OHA and Android to continue its growth path and benefits to OHA partners

Pretty unexpected, but very interesting move by Google indeed. We are witnessing a major reshape of the mobile industry from software to hardware; from Nokia and Microsoft, to Goggle, Motorola, the impact on APAC-based device manufacturers, the operators, Apple, and so on.

This counter-offensive by Google will or should help battle the potential new costs to consumers due to patents wars. As a side note, now imagine how much innovation (and quality of innovation) would be possible if instead of having to spend so much cash on patents, instead it is invested on people, their research-and-ideas, and thus true innovation.

Update Aug 16, 1:30pm: Android partners “welcome” Google’s Motorola Mobility buy (VentureBeat). Very interesting to see Android partners are welcoming this. Maybe they were consulted? (unlikely). But it means that today they see the ROI and are so committed to Android that as long as Android itself is less risky (due to more IP protection), then they are OK with some competition. And/or maybe they don’t see Motorola itself as a real threat. If the latter changes where Motorola becomes a threat, we obviously will see a change of heart.

As discussions and opinions continue at Forxum Oxford on the topic of mobile leadership and Nokia and so forth, the following statement was made by Tomi Ahonen, for which I responded as follows.

Why I am writing about this? Because it is important to understand some of the reasons why some are leaders or are perceived as leaders, or are laggards or are in between….

Tomi Ahonen said:

… that its Japan which is the leader, USA is the laggard – still today – and that Nokia is in between, and in many cases Nokia has led, but Apple does not…”

For which my response was:

Amazing how perception can change everything and even bring a whole global company to the brink of death…

While Japan has indeed been a mobile tech leader, they have remained, in my opinion, very localized geographically. As a consequence, Japan’s global impact has been minute when compared to what Apple, Google and Nokia have all accomplished.

I really don’t get how Apple cannot be seen as a leader in mobile. Apple has definitely led, by taking all the pieces (yes, they learned from others) and creating a new, unique mobile design package like NO other before it. Apple raised the bar for mobile OSes. Gave new meaning to (mobile) web. It gave new meaning to mobile apps. It removed the operator controlled deck. It gave new meaning to developers and ecosystems. It created a new economy for mobile and developers like no other before it. Apple not only brought to market a mobile HW-and-SW package like no other before it, but also changed the playground and the playing rules; the operator is no longer at the center, the ecosystem is. Software (and developers) drive this new mobile economy. And Apple (even if by accident) was the one who figured it out first. If you ask me, Apple was the liberator for mobile developers and the ecosystem. The beneficiaries? The regular user/subscriber.

And there is no turning back. Google, Nokia, Samsung, Palm/HP, Dell, others all understand that it is about the software and the developer ecosystem. Even Ballmer got this right when going Developers, developers, developers, developers crazy:

(for a second I thought he was going into cardiac arrest)

But I digress…

I continued:

Apple introduced its iPhone around 2007. Android ~2008. That is 2-3 years ago! And yet today Nokia has not been able to produce a true match.

The Nokia machine has all the needed parts, but its leadership failed. Today Nokia is struggling for its survival. But Nokia is not dead and will (should) not die; a major reality check this whole experience has been.

Back in April 2008, around a year after the introduction of the iPhone and Android, I wrote a piece on my blog on the Reasons Why The Mobile/Wireless Usage Boom was Underway, where I introduced the diagram below that highlights the convergence between the mobile lifestyle, advanced handsets and the state of the networks:

Here I argue that such convergence is the basis for the adoption we see today…

But why is that? For years I have focused on “application richness” as a key reason; software that extends and enhances the hardware by providing services and useful utilities, and the richer user experience and functionality the wider the adoption. And for years the topic of native vs. web mobile apps have had continued and while the promise and vision of rich web applications continues to move forward, albeit slowly, native applications have lead the way.

The answer is that (regardless of technology) it is about “monetization” and business models, and mobile is no exception. And that technology is *the* great facilitator to deliver this. After reading Mike Rowehl piece on Opening Up Mobile Monetization, which he wrote in response to John Arne Sæterås’ blog Mobile Web vs. Native Apps. Revisited, I agree that technology and application richness and user experience all by itself are not sufficient, and again, that technology all by itself is just a facilitator, and that business models play a key role.

But what has been happening is that three related areas of mobile have been converging over the last decade: 1) the mobile lifestyle where the mobile handset is such a personal social gadget part of our daily lives, 2) the advanced smartphones that provide applications both web and native as never before and 3) the advanced, faster, more reliable and accessible networks that allows for always-on connectivity — all converging closer with business models at the center that promotes a healthy ecosystem.

In this ecosystem we have consumers and we have businesses, some that focuses on creating handsets, others on networks, while others in software services (platforms) and applications. All benefiting — the consumers via improved experiences and businesses via the ecosystem business models. It is this convergence that have enabled the momentum and ecosystem that we are currently seen.

The business models are driven by the ecosystem. And by ecosystem I mean real ecosystems that allows different entities to participate in ways that simplifies trade, the ability to easily author, publish and sell software/applications, on top on other software and infrastructure, benefiting all — the consumer and the “providers”.

The application store showed that the original carrier-based deck was an issue. Even though a business model existed back then, it was flawed. Not a true ecosystem it shows why it was so easy for application stores to lead and show the way. Today the success of application stores is starting to show their weaknesses; thousands and thousands of applications mean finding one is like looking for a needle in a haystack. But discovery today is leaps and bounds better than before; and I am sure better ways to discover will be created.

Back to my convergence diagram vs. adoption above, let’s look at some support data:

On Handset Data Traffic (and Advanced Networks)

Source the Silicon Ally Insider — The above chart shows the consumption of handset data traffic, which correlates to the mobile lifestyle and its relationship to advanced networks behind.

On Advanced Handsets

Source the Silicon Ally Insider — The above chart shows the growth in the adoption of advanced mobile handsets which correlates to the relationship between mobile lifestyle as driver (and relationship) to advanced handsets (and decline of feature-phones).

On Applications (and Business Models)

Source the Silicon Ally Insider — The above chart is about the business model and it shows the growth in the adoption of native applications; see the increase in just one year. This chart shows how the creation of native (rich) applications have increased, in my opinion, thanks to the true ecosystems as allowed by app stores which have facilitated the creation and publishing of applications and the resulting revenues from such software applications economy (business models). Would we see a similar growth once such economy is available for mobile web applications? Or is “application richness” a factor as well? While business models that benefits all in the ecosystem must exist for all this to work, application richness is a secondary factor that certainly drives excitement and adoption.

So It Is Happening

It is great to finally see “the vision” being realized, in large part thanks to Apple and Google who helped shift control and focus into the ecosystem, open systems, the developers and applications. The result has been a tremendous amount of innovation in a relatively short amount of time

Will RIM adopt Android? A very interesting thought indeed. But why or not would RIM do such a thing? Some thoughts below:

Why this would be unlikely?

“Not built here” mentality — this is probably the biggest hurdle for them. There will be internal people resistant to the change, resistant to drastic changes and “throwing away” all legacy work, but sometimes, this must be done;

“Why promote a competitor” mentality — this would be a weak argument, due to the “pros” – see below.

Why this would be likely?

Deliver more value while reducing overall investments/expenses;

Overall reduced Build of Materials (BOM) costs — reduced R&D related to OS; reduce OS team size that instead can focus on value for end-users (apps) and developers. No need to re-invent App Stores. Leverage Google infrastructure (such as Maps which will be an expected feature by end-users) while adding own differentiators on top;

Android OS is advanced and customizable, and open — OSes are complicated and expensive handset elements. Android is based on Linux which is stable, which is open, and which is proven. The Android APIs are robust. The whole environment is open. And is community-based. Able to add own differentiators on top;

Java-based satisfies current developer base — no new programming languages to learn or adapt to. Tons of tools that already exists, from UI to IDEs;

Provides migration path — RIM can decide to continue exposing existing BB Java-based APIs and application life-cycles as needed on top of Android as a migration path;

IDE tools already in place — Eclipse is a very good IDE. There is NetBeans too. Both are open and community based and very complete. There would be no need for their own BlackBerry-specific Java-IDE and that t team can instead focus on BlackBerry-specific extensions to Eclipse, NetBeans and/or other – in other words, a much cheaper route to developer tools than developing or maintaining developer tools from the ground up;

Business models provided by Google — such as search, Maps, other and provide additional revenue streams for RIM.

As you can see, there are a number of positives for going the Android path; let’s see what will happen.

BTW, the above also applies to Nokia, but let’s see if they end up buying Palm instead…

Now it seems that Google Map with support for navigation has the potential to disrupt the whole Nav systems market. And if Google decides to make this new app available across different handsets beyond Android, wow, all the Nav vendors are going to be hurting.

(Side-note: Nokia paid $7.7 billion for NAVTEQ and yet I can’t recall anything from that deal with as much impact as this Google Maps Nav solution)

How can Google Map/Nav disrupt the whole Nav system’s market? Let me give you an example using TomTom since I’m more familiar with TomTom’s Nav system…

TomTom’s Nav app for iPhone cost $100 and if you add their $120 cradle the whole thing is $220. And I bet there are other “hidden” costs for things such as map updates; that is their cash cow.

Let’s now look at TomTom car nav system. Like 2 years ago my wife gave me a TomTom ONE XL as a present. I love the gadget I must say and it has saved my neck a couple of times already. My wife paid like $200 for it. Now, if I want live traffic (or other kinds of data) I have to pay extra (if I recall correctly, for each). And the big one – if I want to update my maps, I have to pay for new map content. Paying for new content is fine, it cost like $75 if I recall correctly. But, because I haven’t updated my maps in a while they want to charge me $75 for the next release after the one I’ve on the device, plus another $75 for the latest one. In short, they want to charge me twice! I felt that they were taking advantage of me by charging me for a version I won’t be really using and I realized map updates is their cash cow; I didn’t upgrade.

And now Google releases Google Maps with Navigation support, a complete solution, for free, for your smart-phone. Can’t wait to get my hands on it (seems I may have to wait for Android 2.0 or upgrade my phone).

You would think that after everyone gets hooked that Google will start charging after the Beta release, don’t you think? Maybe their business model remains search and advertising based, or they will have a new model around charging business to appear on their maps and layers.

…and once again, the mobile handset is at the center of disruption…

Google Maps Nav features:

Search in plain English (watch video). No need to know the address. You can type a business name or even a kind of a business, just like you would on Google.

Search by voice (watch video). Speak your destination instead of typing (English only): “Navigate to the de Young Museum in San Francisco”.

Traffic view (watch video). An on-screen indicator glows green, yellow, or red based on the current traffic conditions along your route. A single touch toggles a traffic view which shows the traffic ahead of you.

Search along route (watch video). Search for any kind of business along your route, or turn on popular layers such as gas stations, restaurants, or parking.

Today I received this from the Motorola marketing folks, here for your reading pleasure:

Motorola today announced DROID, the first device powered by Android 2.0 and features the brainpower and breakneck speed of a modern smartphone. DROID is designed to outperform where other smartphones fall short. It features a solid exterior, intelligent interior and is one of the thinnest full-QWERTY slider phones available. DROID delivers high-speed Web browsing, voice-activated search, a customizable large touch screen and access to thousands of apps and hundreds of widgets from Android Market.

Key features of DROID include:

OS: Android 2.0

World’s thinnest slide-out QWERTY keyboard

3G Web and full HTML browser

Cinematic 3.7” high-resolution display with more than 400,000 pixels

Powerful and fast Google voice-activated search

Run up to 6 apps simultaneously and customize the homescreen with thousands of apps and hundreds widgets from the Android Market

To stay up to date with the latest product news and promotions, you can also find us on Facebook and follow us on Twitter.

Very nice piece indeed, and I can’t wait for such a device to be supported on T-Mobile. Note that it comes with native support for Exchange (which will give Android a big push in the Enterprise) and the new Google Maps Navigation application will definitely disrupt the current Navigation system market (with players such as TomTom, NAVTEQ and others; ouch!) with this new free app. More info below:

A good article by Richard, he reminisces on how mobility used to be in the early days of apps (i.e. year ~2000) when operators were in total control — I do remember those days very well and all the unnecessary control and FUD that literally pushed innovation back about 10 years. Richard then compares that past with what he observed at CTIA 2009 and the lots of noise related to Android — the shift from an operator-controlled mobile world to “Open Mobile” players such as Android.

I have written about this before, on how “control” have been and will continue to shift from the operator and to the ecosystem — the developer and community where developers create (and add) value via their software innovations in applications, where the ecosystem, open systems and common sense will be the drivers for success, where the new deck is the “deck that is on the cloud” and users drive which application succeed or not via simple “application demand”, ranking, recommendations and comments.

For this shift that we are (finally) getting to see we have to thank Apple and Google, but these are recent players. We must recognize the impact made by the Mobile Web and also what triggered it all back in 1999 — Sun with their mobile Java technologies as well as the good old WAP.

I do believe the Android market is going to explode globally becoming a predominant mobile platform together with the iPhone, and that native/local apps will continue to rule for quite a while.

When it comes to mobile handsets the rate of innovation introduced via hardware (HW) vs. sofware (SW) is and will be mainly on the SW side.

Differentiation, especially on common platforms (such as Android), will be primarily driven by SW, this is: Innovation on UIs and interface paradigms (on Android we can see this with the introduction of Moto Blur and HTC Sense), better applications (developer ecosystem adding lots of application that in turn adds to the usefulness of the handset), and better services (some phones will be very good at social things, while others at music, and so on). At the end it is SW what makes the handset more dynamic and useful and different.

Differentiation is necessary. But typically differentiation drives fragmentation. So the follow-up big question is on the fragmentation introduced by the different UI paradigms. Will applications need to be adapted to each new paradigm (i.e. as in many versions?). Yes, very likely.

Developers writing SW for the iPhone only have one paradigm to worry about. On the Android though, as expected we are seeing different UI paradigms (with related APIs) but fortunately the rest of the platform should remain consistent across manufacturers so fragmentation is hopefully localized to the UI only. For mobile Java (beyond Android) fragmentation is yet to be solved. For mobile web and widgets, the same although I am seeing a lot of noise around the JIL Widget SDK.

Fragmentation across platforms will continue. Fragmentation within a single platform shall be localized to the user interface (or the user interactions). Allowing for the UI to be redefined/reconfigured allows for incredible innovation on human to machine interactions which basically redefines the perception for a given handset. The next best thing is re-configurable software and hardware, but for that you will have to go play with platforms such as Bug Labs (which BTW is an extremely cool platform).

This week guest post is by Dr. Kiran Mudiam, a long time mobile technologist and a researcher.

Here is my take after reading all the letters sent to the FCC.

We all know that there are positives and negatives to open and closed App Stores. And not everyone is happy with both models. For example, too open, such as the Android platform, we find lots of spam and light-p0rn. On the other side, too close, we have the Apple police, which results of lots of missing apps.

I have seen Google Voice and Google Latitude on the Android platform, and I believe that they need to be similary implemented on the iPhone as well; many, including myself, would want that on their iPhones. And to make it clean, Latitude should be integrated into the current iPhone maps app just like it is done on the Android, and it also makes sense to try to get it running in the background.

I am still hopeful and waiting to see these apps on the iPhone as they fit nicely; but that will only happen as long as they play nice with Apple. If not I would argue that Google can find another app store such as Cydia to release their apps if they want stick to their guns. I already have seen the availbility of the Gooble Voice App through Cydia.

About Dr. Kiran Mudiam

Dr. Kiran Mudiam is a long time mobile technologist and a researcher with several years of experience creating mobile software products and end-to-end mobile computing. He recently was a Mobile Architect at American Express – Technology Strategy and Innovations, driving the next generation Mobile Payments for American Express. He is currently at Trimble Outdoors working on their next generation of GPS based mobile applications.

The Google App Market – An Analysis

This article is about App Stores/Markets. It is a personal view on the Google App Market and thus it is totally unscientific. It focuses on Google App Market but it applies to all app stores. In this article “App Market” and “App Store” are used interchangeably and refer to the application catalog on the Web that allows for the discovery, payment and download of mobile applications.

There are like four ten thousand applications on the Android Market while the iPhone App Store has many, MANY times that. Everyone knows that the Google App Market is not doing as great as the iPhone App Store. Even when trying to compare oranges-to-oranges, this is, for example, the number of apps and apps-downloaded and paid-for on a given/same period of time or the same age-period of the store themselves, for some reason the iPhone has clearly done a much better job.

It is a very interesting problem. There are so many variables involved in this problem, starting with the human-factor variable, that makes this nut so hard to crack. Bring on the human-factors experts! Bring the designers and engineers. And let’s not forget the marketers! This problem is way beyond pure engineering — I’ve always said that the iPhone was created by designers and marketers and engineers, while the Android was made by engineers.

Why such big differences between both stores?

Are iPhone users really unique/different?

Are Android apps “sucky” or are Android users cheap?

Are the reported store/market numbers skewed?

Does it have to do with “critical mass”?

Or is it all due to user-experience — the experience finding, buying and downloading applications?

Perhaps it is all the above. But before I take a stab to the above questions, let me talk about a higher-level view to this problem. To be successful, App store/markets must be built on top of a number of foundation steps as illustrated next.

Figure 1 – Basic Ladder for App Market/Store Success

…where:

At the bottom of the ladder as first step is critical mass, as without critical mass there is insufficient effect to realize a long-tail effect. Handset positioning, marketing, pricing, region, all have part on critical mass adoption.

The next step up the ladder is user-experience, which perhaps is one of the most difficult steps to get right and is covered in more detailed later in this article.

The top step on our ladder is the ecosystem and quality applications as without these there is no app store/markets.

The above foundation steps are critical to the success of app stores/markets. Next let me go back to the questions above and how they relate to this Basic Ladder.

iPhone users have proven to be a unique/different bunch. They are more consumer-oriented than Android and even BlackBerry users. For some reason those users do get applications. Perhaps thanks to marketers (TV commercials | “There is an app for that”) iPhone users see applications as “things that solves specific problems”. The iPhone has critical mass, but BlackBerry has critical mass as well; the BlackBerry store should be a great tester of the theories written in this article (once they implement the two top steps of the Basic Ladder above). Yes, critical mass is one of the foundations for success. As a side-note, while the iPhone has an attractive critical mass, it is not as attractive in all countries due to cultural preferences/differences. Device manufacturers must understand and find what creates critical mass for their own products on specific regions.

Today Android apps are less sophisticated when compared to iPhone applications. On the iPhone it is expected that applications are somewhat sexy/eye-candy. This helps with application quality perception. Applications must just work well and be useful. Good quality apps is another foundation for success. In theory and over time, Android apps should become sexier as well. Should there be an approval process that enforces a minimum user-experience and eye-candy for Andorid apps? Hmm that is a tough one, and doing so go against the idea of a true open platform.

Android users are cheap; Android users don’t buy as many applications as iPhone users do! Maybe this has to do with demographics. Based on observation the majority of Android users are the techies-type who prefer free stuff and who are not willing to pay for applications that aren’t great. But the demographics for Android users will soon shift with the plethora of devices coming from emerging markets and other. (For the record, I’m an Android user)

While we always have to be careful when interpreting industry metrics, as collected numbers, by definition, are and alway be *relative* to a particular set of conditions and data set, existing metrics/numbers do show that there is not enough critical mass (a foundation for success) for Android at this moment. I expect numbers to shift in favor for Android as mentioned above. And the top reason I believe this will be the case is economics — more and more device manufacturers will introduce Android devices because using Android reduces their initial investment and maintenance costs (due to reduced Build of Materials) when introducing a new mobile handset. As you know software and especially Operating System software is a very complex piece and it is very expensive to build and maintain and it is just logical that manufactureres will take advantage of all the research and development already done by Google and that is available for “free” or “at no cost” to them.

And what about the user experience? The user experience, another foundation for success, can definitely be improved on the Android Market. The current experience is not terrible, but it is not helping maximize the transactional opportunity. Towards this goal of improving the user experience Google has been working on a new version (v1.6) of the App Market application which includes a number of improvements including screenshots and more descriptions and new categories — see Some News from Android Market (Google Android Developers Blog) including a short video of the new client.

While I’ve no insight (beyond the above) on what Google will be improving on the Android Market, they must take into consideration a number of additional things, including improving the user experience beyond the on-device client and helping the Search function a bit more.

On User-Experience

User-experience can enhance and promote usage, or discourage it. If the (app store/market) is too hard to use, or if it is too hard to find apps, then people won’t use it. And as the number of applications increases, better ways to find applications must exist.

Recently AdMob reported (PDF – AdMob Metrics July ’09) that over 90% of users in their study reported that most of the application discovery efforts are done on-device instead of their computers. Below are other insights from the AdMob report:

The most-cited ways of discovering apps are browsing the Android Market/App Store Rankings and searching for a specific type of app. Over 90% of users who cite these activities do them on their mobile device instead of their computer.

Android, iPhone and iPod touch users are all highly engaged with apps. Android and iPhone users download 9-10 new apps per month, while iPod touch users download 18. Over half of Android and iPhone users spend more than 30 minutes per day using apps.

iPhone and iPod touch users are more likely to regularly purchase paid apps than Android users. 19% of Android users download at least 1 paid app per month, compared to 50% of iPhone users and 40% of iPod touch users. However, of those users who regularly purchase paid apps, downloading behavior is similar across platforms.

The above goes back to better ways to discover, buy and download applications is key. I do believe though, that a web-based companion will also improve overall Google App Market performance.

Search is good, but even Search needs some help. And this help is about filters, good filters. Imagine the right filters, including self-organizing ones. With the proper Search and Filters we have the first step towards improving the app store user experience. The other two steps are related to buying and download.

While search by categories, “featured apps” and popularity is important, quickly filtering by “free vs. paid” and “new vs. old” is probably even more so. And to maximize the usefulness of the filters and maximize the transacttional opportunity (minimize incorrect bias) the filters must all be visible and accessible just “one click away”. Let’s take a stab at a potential UI design for such an application discovery application:

Figure 2 – Potential Enhanced UI Design for App Store Client

Note the emphasis on filters by categories; here categories aren’t fixed and will adjust based on historical usage, or preferences. This is important as my favorite categories not necessarily are your favorite ones, and once categories are fixed it translates to exclusion; indiscriminate exclusion is not a good thing. Note the “free vs. paid” and the “new vs. old apps”; the latter should be familiar to Google Reader users. Other useful filters are the ones found on the iPhone App Store client such as “featured” and “Top 25″. But again, it is very important that search and filters are ALL visible and also are “one click away”.

A complete discovery solution must not only be on-device but must have a desktop companion. Apple has iTunes. Google has the Android Market, but it is incomplete in my opinion. See the areas in red below: few filters, incomplete applications catalog, and no push-to-handset method, just to mention the obvious limitations.

(Part of the discovery — the App Market/Store shall also only show the applications that works on the user’s device — here works means resolutions, platform version compatibility and other).

Figure 3 – Current Android Market is Unnecessarily Limited

The enhanced web-based “desktop” market (companion to the on-device market client) shall provide the complete catalog of applications, provide and maintain download and purchase histories, but also must allow for the ability to initiate the download (push) of the application to the handset over-the-air (OTA). In other words, a user should be able to use their browser on their desktop/laptop and go to the Android Market, discover, buy and push applications to their Android handset. This market user interface shall provide all the same search functionality/filters as the on-device discovery UI illustrated above.

Once The App is Discover, what is Next?

Once the application has been found, it is about learning more about the application: here things like screenshots, ratings, descriptions are all important. And the upcoming version of Google App Market client v1.6 will try to improve on all of those areas. What about the ability to share the application? Yes, very important! Google must add such facility (i.e. “Tell a Friend”) as well.

The following illustrates the App Market/Store Cycle and Support Triangle that shows the three main phases a user goes through when interacting with an App store/market including some important characteristics for App Market/Store success.

Figure 4 – App Market/Store Cycle and Support Triangle

You should be able to extrapolate from the above app discovery, payment and downloads diagram and about the transitions in between them.

Last I would like to mention the importance for a super simple payment system. In the past I’ve written about “integrated payment with the operator” approach which should be a very simple approach for users (this of course would only apply to operator-subscribers scenario). Another solution to this is the App Market/Store PC (web) companion that I mentioned above that would allow a user to not only discover and buy applications, maintain existing download and purchase histories, but also easily setup and maintain account and payment histories; for Google this would be Google Checkout in the back-end.

In Conclusion

App Stores are little strange, difficult entities. At this moment it seems that Apple has gotten it right, but not the others yet (others are RIM, Google, Palm, Microsoft). App Market/Store success is dependent on a number of different moving parts, including the most difficult one of all: human-factors. It takes designers, engineers, marketers and human-factor experts to get it right. And it is important to get it right, as the future of the mobile handset useful relies on software and applications, and software and applications are the bread and butter of the developer community, you and me — the Ecosystem.

The Problem: Too many handsets, environments, and differences across platforms

The Solution: A single environment/platform for mobile apps

There you go, problem solved, no more fragmentation!

Google at MobileBeat 2009

Now that the “noise” level has dropped, it is my turn to comment on Google’s (Mr. Vic Gundotra) comment at MobileBeat2009 about mobile apps and the future:

“What we clearly see happening is a move to incredibly powerful browsers,” Gundotra said. “Many, many applications can be delivered through the browser and what that does for our costs is stunning. We believe the web has won and over the next several years, the browser, for economic reasons almost, will become the platform that matters and certainly that’s where Google is investing.” Gundotra added that Apple CEO Steve Jobs proclaimed “Build for the web” with the initial launch of the iPhone, a statement that met with resistance from developers: “I think Steve really did understand that, over the long term, it would be the web, and I think that’s how things will play out.”

Here Mr. Gundotra (Mr. G hereafter) emphasizes and reminds us that the main root problem with mobile applications is fragmentation and the consequences are higher cost of development and management of such mobile applications.

OK, fragmentation has slowed down mobile, and has resulted on higher development and management costs. But fragmentation will not go away any time soon. He said the Web has won, but on mobile it hasn’t. Because many applications can be delivered over mobile is not the same as it has won. The Web has won though from the perspective of “Services on the Web”. Mobile web run-time environments will, over time, continue to evolve, providing a rich development environment; I believe this will be the case, but this will take time, years, to happen. Now imagine a world where we have Google browsers and run-times and APIs — that would mean no fragmentation, right? Well, even with run-times from Google with its own APIs, yet another level of fragmentation will be introduced.

It is the way it is.

And not everyone will use Google tools and run-times and APIs. And not all developers want to develop their apps using Web technologies and models. And, mobile web apps are not sufficiently rich and transparent yet to replace local apps.

In any case, I will admit that I share Mr G’s vision on web run-times, as I’ve written many times before here in the weblog, but his message was so overloaded that I’m not really sure if that was Google’s official stand or just Mr. Gundotra’s point of view. For one, today Google is a large corporation, and I won’t be surprised if his comments caused some internal frenzy. You see, his view/solution to the issue of device fragmentation is “one platform”. But, that is exactly the goal of the Android team; reduce the number of mobile platforms out there.

Mr. G also implied that Google will continue to invest (greatly) on their (mobile) web platform with the goal of bringing it at the same level to local (non-web) platforms such as Android. This should translate to extending the browser/web run-times with the APIs and access to device functionality and HW that provides overall greater richness. That translates to investments in Chrome “OS” and the Google APIs including Gears, which are proprietary APIs. As a side-note, why Google didn’t participate on BONDI, which defined APIs for web run-times for application invocation, UI, location, camera and other, might reveal either “political” or proprietary mentality that should concern you (as it concerns me). BONDI and Gears are competing technologies, but they don’t have to be.

But all this push to web run-times and Chrome “OS” doesn’t mean that Google will stop investing on other. You see, Chrome “OS” will become a very strong brand. But Chrome “OS” is a misnomer, as it is not a real OS. And to be able to expose and offer the powerful browsers and rich user interfaces and experiences that the browser-based apps of the future will need, again, access to the functionality and HW underneath is needed – and for this a real underlying OS will exist and perhaps with it an application environment on top of that; in short OS = Linux, App environment = Android. In other words, Google’s investment on Linux and Android won’t go away. With this approach, Google has all the components, from the OS, to the app environment, the web-run-times and the applications to lead and keep it moving ahead, red-shifting from the competition.

App Stores are Dead, Not

Some folks have interpreted Mr. G’s comment as the end of App Stores; see Google forecasts browsers will beat out app stores (FierceMobileContent). But it is not; not sure why that conclusion. App Stores are nothing else than repository/catalog of applications, those being local or web or widget or whatever, for the purpose of discovery regardless of the application model. Thus, expect Google App Store to grow in the future to include widgets, web-based and other apps.

Mr. Jobs, Apple, The View of the Future, But Reality Strikes

Mr. G assumes Steve Jobs “saw the future” when at first the iPhone development was web-based only. Maybe he is right. But the iPhone had an SDK, perhaps primitive, since day one (used for the development of internal apps such as phone dialer, contacts, calendar, and so on). Why would Apple limit access to it? One reason could have been that the SDK was not ready for prime time. But Jobs is a coined operated individual, let’s not forget that. Maybe Mr. Jobs wanted to give access of the SDK (which allows for extremely rich and profitable applications such as games and music and video) to just a few privileged ones — the big power houses such as Sony and others, while the rest of applications by the developer community were to be done via simple Web (perhaps for free). Who knows. But that hypothetical plan didn’t work, and once Apple recognized the real power of the *developer community*, it reacted and offered the SDK; in the end, everyone won, you and me. And the unplanned succeeded. And this same exercise also showed the reality that today mobile web apps are not ready for prime time as compared to the richness and capabilities of local/native apps. There you have it. Native apps are kind today.

Today vs. Future

Let’s not confuse theory and practice. Let’s not forget why we are doing this. Today is about generating revenue while minimizing cost of development. Tomorrow is about the same, but lets learn and reduce such costs related to investment and operations, and part of this plan is reducing device and application fragmentation. This is important for Goggle as it is about applications and information (and the infrastructure that powers this). Google has two strategies on applications and fragmentation: one Web-based and one local/on-device (Android). Google has the whole SW stack including the OS. And on the top, it is about the information (and its meaning) w.r.t users/people. But it is IMHO that local apps are here to stay; because limiting apps to browser-based apps will be too limiting, in functionality and richness and in programming models and at times in speed. And because it is about the developer community (internal and external), “limiting” will translate to less innovation. And I will even predict that even Chrome OS will allow the user to “switch” to an advanced mode, the native/local apps mode (or a hack will exist for it).

And Mr. Gundotra’s comments are all about the future… So time will tell. And it should not be a too distant future (5 < years)...

With Gmail, Google introduced a couple of peculiar ways to deal with email. One of these is the “search vs. sort” approach to finding emails of interest or finding related emails.

Instead of going with the common approach of sorting by column which is typically done to easily find related emails (by author or by similar topic) with Gmail the way to find such related emails is to search, which takes extra steps such as more typing or more clicks. The end-result is the same but with one caveat — it takes too much time and clicks and typing to accomplish the simple task of finding related emails.

This makes me wonder about the UI design approach and its designers, as this approach feels as designed based on engineering-factors concerned about (back-end) performance vs. a design focused on “human factors”.

In any case, why not offer a solution that balances both? For example, fast filtering for related emails by adding new actions to the “Select” section, for example new “Author” and “Topic” actions, such as this:

>> Select: All, None, Read, Unread, Starred, Unstarred, Author, Topic

…where selecting an email and then clicking “Author” would result on Gmail searching and filtering and displaying only the related emails based on author, and clicking on “Topic” filters by related topic.

On December 2008 I wrote on my blog Browser Swallows OS, where I pondered on the idea of a Web OS.

The machine boots up to a totally web-based experience. The application-bar at the bottom of the screen consists of widgets and icons (links) to web-based applications. One of the apps/widgets in the apps-bar is “boot or switch to OS” (for those who may want to switch). The desktop which is the browser runtime, is tabbed. The main applications on the desktop itself are live widgets. Because it is web-based, applications are automatically updated as needed. And all (web) applications work even disconnected, when there is no access to the network.

And today, Browser Swallows OS, Part 2 — the Real Thing, was announced — see the Google Chrome OS (Google Blog).

This Chrome Web OS will be very attractive (and just in time) for the always-on Netbooks explosion that is coming. These 3G/4G/Wi-Fi Netbooks are going to be heavily subsidized by Mobile Network Operators; one recent example is Sprint offering a Netbook for 99 cents with Activation (jkOnTheRun).

Both consumers and business-alike will adopt due to its overall simplicity. Today when someones buys a Netbook, it runs Windows or Linux, but the user spends MOST of its time on the browser (over Wi-Fi).

The Chrome Web OS won’t be the best platform for gaming or graphic intensive apps –maybe; I’ve seen some JavaScript-based graphics/games that look very nice and very fluid. With HTML Canvas and Google’s very fast JavaScript VM (that is already targeted at IA-32 or ARM processors) even graphical apps might work just fine — see What is V8? But perhaps the main target is not gamers in my opinion. But for the traditional tasks – email, IM and other collaboration, documents, social networks, video, photos, calendar and contacts and so on it is perfect. Difference is that it is all resident on the cloud.

Because the main use case for Chrome OS is for connected device, I will assume the usage model requires pro-activeness from the user to sync/download ahead of time in anticipation of not being connected to the network. Or perhaps there will be a sophisticated auto-sync engine that keeps recent documents properly sync-up.

Obviously at the bottom of the stack will be a real OS, Linux, and I won’t be surprised if (some of) Android is actually adapted above the operating system.

I’ve read here and there that Chrome OS is about killing Microsoft and whatnot. Yes, sure, Google wants to kill Microsoft and any other strong competitor, as it should, but I like to believe this is deeper, and it is about the realization about the next logical steps or evolution of connected/networked applications. Combine this with the right timing (i.e. Netbooks and subsidies) and you may have the ingredients to help make this a reality.

8:24 Have had too much complexity. Today over 20 combinations of software, silicon, and UI platforms. This has resulted in high costs and portfolio gaps in 3G, smartphones, very low tier.
:
No longer planning to develop certain OSes. Will focus on Android, Windows Mobile, and P2K. ODM solutions for low and very low tier. Will no longer offer new OSes on internally developed Linux Java or Symbian UIQ. $370 million of charges on inventory write down.

The above is actually a very good thing. Focus, focus, focus. Less OSes translate to less maintenance overhead. And leveraging Open OSes mean leveraging others (i.e. cheaper) to build a high-quality product.

I think Android has fallen from the Sky and just at the right time for Motorola.

Motorola can focus on creating strong H/W pieces based on Android, while riding the Android wave and making things cheaper.

If I was Motorola, I would design a common platform, a foundation for all of their handsets, and drop all OSes except for one, Android, as it is (or should be) cheaper, it is based on Linux (and Motorola likes Linux), has a great UI (Motorola is not great at UIs), and leverages the Google infrastructure (GMail, Contacts, Maps, etc) allowing for highly functional handsets right out of the box. I would also use a powerful design company such as Frog Design for their industrial H/W design, and then concentrate on the manufacturing aspects.

I’ve the feeling positive things will be happening for Motorola, if they continue working on the right things: re-organizing and cutting costs/expenses, working on the right technologies, taking advantage of their strengths (manufacturing) and culture, and focus, focus, focus.

Last but not least, all of this begs the question: what is the future of MIDP3? Motorola is the MIDP3 spec lead, and the spec is pretty much ready to go, complete. But it seems for obvious reasons that MIDP3 is not on Motorola’s top/high priority list. Will Motorola drop MIDP3 or will Motorola have a MIDP3-runtime on top of Android? That would be interesting. Let’s wait and see.

Post navigation

Search

About

Welcome. My name is C. Enrique Ortiz (aka CEO). My professional focus is on Product Development, next generation mobile and cloud software, platforms and APIs.

As time permits, I like to write/share my interests: end-to-end mobile software, platforms and APIs, the mobile context and implications on the user experience, embedded and connected machines/software, intelligent machines/software, flying machines/software, the space program.

I'm author or co-author of two books on mobile development (J2ME and Android), hundreds of articles and presentations, and a number of patents.