20 Jun

On App-Specific (Customer) Support | Developer Survey

For many years I’ve been heavily involved on the mobile application aspects of mobility; the app layer and the network layers. Most recently I’ve been spending quite a bit of time managing the development of a new product called Mobile Broadband ServiceView; development that has exposed me to a new point of view when it comes to mobile. Today my customer is the network operator themselves in the areas of “device activation, management & support aspects” (where device is a handset and/or wireless modems).

One aspect of interest is the impact of Mobile Broadband (MBB) which is globally exploding like crazy– an explosion caused by increase in use of smartphones and PC wireless modems — 3G, WiMAX and later coming is 4G. The following chart from Chetan Sharma‘s excellent recent report on “The Role of Optical Wireless Broadband in the Evolving Mobile Ecosystem” shows tremendous projected growth on data consumption on the USA alone:

…which is traffic generated by mobile services and apps. It is such growth that there are even rumors that some operators may be considering pulling the plug off voice to concentrate purely on “data”!

And with this growth it is also known and it is expected that the related costs of support will increase as well. The complexity of mobile broadband (data usage, connectivity and network issues, application impact, device issues) are some of the variables that add to key metrics such as number of support calls, number of repeat calls, call average handling times, first call resolution, escalations and other. Some of these metrics are very call-center specific, but what is the impact of this to the application developers themselves?

Impact on App Developers

Operators are big on call deflection and reducing the support call talk time, and with the thousands of applications that exists today plus the thousands more that are expected, operators, who have the tools to identify if applications are the cause of device and network issues, are pushing to the application developers themselves the burden of application support.

Is app-specific support a real issue today or one that is coming? How can application developers handle the burden/cost of app-specific support issues? I believe this is an upcoming issue for app developers to address in the future. I have my own ideas but I am curious about what developers themselves think about this topic; for this I put together a very simple/basic survey; I will be sharing the results… Thanks in advance!

Click here to take survey (SurveyMonkey)

Comments are welcome…

ceo

21 Sep

Mobile Application Stores Conference at CTIA 2009

Ajit and team have been organizing The Mobile Application Stores, Strategy and Deployment conference to happen during CTIA WIRELESS I.T. and Entertainment on October 8th 2009, in San Diego. Featured speakers for the event include:

  • William Volk, CEO, PlayScreen
  • Chetan Sharma, CEO, Chetan Sharma Consulting
  • Tim Haysom, Chief Marketing Officer,OMTP
  • George Linardos Vice President, Product Management, Media, Nokia
  • Ilja Laurs Founder & CEO, GetJar.
  • Dr. Jin-Sung Choi Ph.D, Senior Vice President, Head MC Global Product Planning Team, LG Electronics Korea

And many others. App Stores is a hot topic worth understanding as it is at the center of application discovery and monetization. For more information visit Ajit’s blog

Related to this topic see my writeup: The Google App Market – An Analysis.

ceo

06 Sep

The Google App Market – An Analysis

I’ve written a quick analysis on the Google App Market situation… Looking forward to your feedback/opinions!


You can download this article in PDF format. Download The Google App Market – An Analysis (PDF).


The Google App Market – An Analysis

September 6, 2009 | © 2009 C. Enrique Ortiz — http://CEnriqueOrtiz.com

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.
  • Requests from the Android Operating System increased 53% month over month. Android has 7% worldwide OS share.

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.

ceo


V1.5 | September 6, 2009 | © 2009 C. Enrique Ortiz — http://CEnriqueOrtiz.com


26 Jul

Resolving Device Fragmentation Issues – Mobile Web and Local Apps (and Google)

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)... ceo Related to this: