01 Oct

Total Time Spend Using Mobile Web vs. Apps (October 2012)

Saw this today at BI website…

Source: Business Intelligence (BI)

Source: Apps More And More Important Than The Mobile Web (Business Intelligence). Original report by Nielsen.

The above is self-explanatory…

What I find ‘funny’ is that over time I have noticed that Business Intelligence’s opinion on “native vs. web on mobile” swings back-and-forth (based on the top news of the day). In this particular case, all the recent attention to “native vs. mobile web” is thanks to Mr. Zuckerberg.


11 Sep

“The biggest mistake we made as a company was not investing enough on native.” — Zuckerberg (2012)

The title of this blog is not what Zuckerberg actually said, but is what he really meant.

From TechCrunch Disrupt — Zuckerberg Shows He’s The Right Man For The Job:

“The biggest mistake we made as a company was betting too much on HTML5.” While building native apps that were bacially just a wrapper for the mobile web standard let it experiment quickly, it made the apps run way too slow. “We burnt two years.”

This validates what I have been saying for years… Don’t take me wrong, I’m a fan, user and developer of webapps. Web on mobile is big and the mobile browsers and frameworks are getting so advanced, and the mobile webapps so kickass, but for certain kinds of apps, especially rich consumer-based applications, native is the way to go today.

Consumers are about great user experiences and great quality. The “mistake” Zuckerberg refers to is not really that they bet “too much” on HTML5, but that they didn’t invest enough on native.

But that said, FB has nailed it down; recognizing the need to invest on the native apps and related infrastructure, and focusing on mobile first.

Any company going global must have a mobile first strategy — we know that for many around the world, their online experience will be on mobile.


31 May

Introduction to jQuery Mobile (May 2012)

See my latest article, Introduction to jQuery Mobile (developerWorks).

This article, an update to my original Intro to jQuery Mobile (Feb 2011), introduces the basics in the latest version of jQuery Mobile. Learn about browser support, the UI components, and the API.

“Summary: Get an introduction to the jQuery Mobile framework. Learn the basics of the framework and how to write a functional mobile web application user interface. In this article, an example guides you through basic pages, navigation, toolbars, list views, form controls, and transition effects.”

Link: Introduction to jQuery Mobile (developerWorks).

Related links:
* jQuery Mobile developer site
* Original article: Intro to jQuery Mobile (Feb 2011)


08 Mar

Mobility in 2011: Mobile Apps, Webapps and Tipping Points

(This is part of a series of blog posts on Mobility in 2011)

The debate of mobile (native) app vs. webapp is not new. This is a decade-old topic that has been debated since the days of WML.

Today the debate is pretty much the same debate.

The debate’s topics and considerations typically center around “design, experience & capabilities”, “marketing & monetization”, and “code-building-effort”.


  • The “design, experience & capabilities” part of the debate is about the application design, features & technical capabilities and its effect on the user experience; today this favors native apps;
  • the “marketing & monetization” is about awareness, visibility and discoverability, for example, creating a popular app will give you lots of visibility and direct and indirect monetization methods, and today it currently favors apps thanks to the app markets and stores, and;
  • the “code-building-effort” part of the debate is about ROI. This is mostly debated by those responsible for creating and delivering great applications and solutions as efficient as possible: fast development cycles with minimal resources, minimizing code duplication & maximizing code re-usability, better and cheaper ways for distribution and deployment. Topics like fragmentation, browser capabilities and centralized distribution come to light. This part of the debate favors webapps, unless you focus on a single native app platform such as the iPhone. Android is fragmented but this should improve over time as the platform matures (in theory). The webapps centralized model is a winner, but so is the centralized model of app stores. At the end, due to the previous two debate points, native apps are leading the way with iPhone and Android as the platforms of choice. But this is changing as well, thanks to toolkits such as jQuery Mobile which helps bring consistent webapp development and user experience across browsers. While apps are a clear winner today, an increasing number of customers are asking for mobile web versions of their apps before they commit to native apps; these typically are customers who want to go mobile now and who understand the ROI benefits of webapps across mobile platforms, yet are doing this as a starting point before introducing the app version of their applications (since they too understand the user and business benefits of native apps). It is important to note that hybrid app approaches that brings together the benefits of webapps into native apps (containers) is something to consider in the meantime.

Two Important Tipping Points

Below I cover two thoughts on the matter of app vs. webapp, and two tipping-points that most occur before the debate of apps vs. webapps become a moot point .

While the browser of today is a number of magnitude more advanced than its predecessors from the days of WML (and CHTML, etc), the relationship between apps and webapps have persisted over time; that is, from the application perspective the native app has always been ahead when it comes to features, user experience & capabilities. This answers the “design, experience & capabilities” part of the debate and the top reason why still today mobile apps are more popular than webapps.

But it is just a matter of time before webapps will be very close or equal to apps. If you were to picture this in a chart, based on experience, it would look something like the following:

…where: while the native platform and apps have had more features & capabilities than the webapp, as the browser becomes more capable (including performance) and the markup language becomes more “expressive”, the two lines will meet (but will they cross?); this is the first tipping point. And recall that “…after the tipping point has been passed, a transition to a new state occurs.”

In the chart above I also attempt to capture the impact the iPhone, Android and the Webkit, as well as sensors such as touch & location all have had in the progression of apps and webapps, and how they have contributed to awesomeness for both app and webapps.

But there is a second tipping point to be crossed. The second tipping point is related to user experience & perception. If we were to visualize this as well, it would look similar to the chart above, but with additional/different triggers. Apps have been very successful in creating analogous experiences to the physical world and its attributes, in ways webapps haven’t being able to achieve yet. Apps you can find, buy and own, see, listen to and touch in ways webapps don’t offer at this point. The way apps are owned is unique too. And people even socialize about apps in ways we don’t see yet about webapps. Before this tipping is crossed though, tipping point #1 explained above must be crossed first.

Will these tipping points occur in 2011? I don’t believe so. In the meantime, this has major implications on marketing and monetization which favors native apps.

So the debate of mobile webapps vs. native apps is not new. The debate of app and webapps is really relative as dictated by specific needs. We can debate the technical merits for each, the business merits or both. Today, the the user experience and perception favors apps which translates to business benefits ($) and thus outweigh the benefits of webapps. But there are business reasons why go webapp such as going mobile faster across platforms. The app is still ahead of webapps when it comes to the combination of design, experience & capabilities + marketing & monetization + development ROI, but the gap continuous to close; it is a matter of time. From the capabilities perspective such as a graphical and transforms, performance, sensors, connectivity, storage and offline behavior, the mobile web browser is rapidly advancing, and when combined with better webapp discoverability, marketing and revenue models, then we will be closer to the “features & capabilities” and “experience & perception” tipping points at which time the distinction between mobile apps and webapps will become a moot point.

Related to this, see: Is 2011 the year of the Mobile Web apps? (Open Gardens)

Related posts from About Mobility:


22 Feb

Article: DOM-based data storage and retrieval using jQuery

See my latest article titled DOM-based data storage and retrieval using jQuery. It covers the jQuery data() APIs and HTML5 data-* attributes in your jQuery-powered applications…

Summary: The popular, and free (MIT and GPL-licensed), jQuery JavaScript library has a concise and portable set of JavaScript APIs for rapid web development. In this article, learn how the jQuery data() method can simplify the task of associating data to DOM elements. In-depth examples show how to use the method in your own applications. Discover how jQuery lets you use HTML5 data-* attributes in your jQuery-powered applications.

See DOM-based data storage and retrieval using jQuery (developerWorks)


03 Feb

Article: Introduction to jQuery Mobile

My first article for 2011, meet the jQuery Mobile framework.

This article provides an introduction to the jQuery Mobile framework. Learn the basics of the framework and how to write a functional mobile web application user interface with minimal or no JavaScript code at all.

See the article Introduction to jQuery Mobile (IBM developerWorks) which introduces the jQuery Mobile framework.


18 Nov

OMTP BONDI 1.1 Candidate Release — Open to public for review/feedback

BONDI 1.1 is now in Candidate Release and it is open to public for feedback.

Note that this phase will close on the 2nd of December so you’ll need to get your comments in before then.

See OMTP and BONDI at the betavine website.

What is BONDI?

In short BONDI is a set of specifications, reference implementation and compliance criteria for the creation of mobile web apps based on Widgets.

This means that BONDI widgets rely on the web-runtimes or browser as its execution environment. BONDI defines a set of APIs that provides BONDI widgets with access to the handset functionality such as access to camera, contacts and location information.

The BONDI official website contains all the information you need to learn more.

From the BONDI website:

During 2007 and 2008, it became increasingly apparent that the future direction and success of the mobile web could be harmed without a concerted effort to drive a standardized approach to how web applications access the key local capabilities on the mobile device.

If web applications had to use different APIs (for the same capability) on different devices and platforms, then development of web applications which work on any mobile device would not happen. On top of this, the risk of malicious web applications having free access to local mobile capabilities is unacceptable. Therefore, a need to create some form of security layer to protect the user from harm was essential.

It is with this background that OMTP launched its BONDI project with the aim of acting as a catalyst to drive the standardization of a small set of key interfaces from web services to mobile devices and also to put in place a well understood and user controlled security policy with which to protect the user.

BONDI consists of several activities, each of which interacts and as a whole builds towards the aim defined above.

Interface Requirements — A high level definition of the BONDI interfaces which include a dynamic API which is remotely updateable once the device is in the field

Security and Architecture requirements — Requirements for BONDI architectural constraints and for the security policy which protects the user from harm

API specifications — A set of Doxygen generated HTML pages that define the syntax and semantics of the BONDI APIs

Security Policy DTD — An interoperable XML description of the security policy which defines the access that a particular web application and widget will have to the BONDI APIs.

Reference Implementation (RI) — The RI is a real concrete example (using Windows Mobile as the platform) of how the interfaces and security specifications should be implemented. The RI SDK contains API documentation and example code.

Compliance Criteria — A set of criteria which may be used to judge compliance of implementation against the defined standard and RI.

The BONDI Reference Implementation has been created as an Open Source project. This enables both OMTP Members and Participants as well as non members to collaborate on the creation of a rapidly iterating and testable implementation in a public arena. The use of real code in a RI ensures that other implementations for different devices and platforms can be tested and declared compliant against well defined criteria.


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


  • 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.


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:

08 Jul

Browser Swallows OS, Part 2 — the Real Thing

Google Chrome

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.



Oh, I liked this:

@Rhymo: App becomes browser. Browser becomes OS.

25 Jun

Friday Poll: Browsing the Internet, the Web or the Mobile Web

When browsing on your mobile, do you call it browsing “the Internet”, “the Web” or browsing “the Mobile Web”?

After an interesting discussion at ForumOxford on one vs. many webs, I’m curious (keeping in mind that the majority of the readers of this blog are mobile techies) on how folks see this.

Related to this see Barbara Ballard’s essay how many webs? (Little Springs Design).


P.S. It is the 1st time I use PollDaddy and I’m not sure how it will work, on the blog or feeds.

30 Apr

On Mobile Applications, Platforms and Monetization — “Show me the Money”

I’ve been keeping track of a very interesting thread at Forum Oxford (FOROX) on the topic of Android phone dissapointing developers (w.r.t. iPhone), with Jason Delport, Alex Kerr, William Volk (who started the thread) and others adding their different perspectives on the matter. All these guys are mobile experts so what they say resonate with me…

I like Jason’s responses as there is no bias, just pure pragmatism (i.e. he has been burned before); he makes a living building mobile apps, so for him it is about business and making money. Period. Jason’s take on why Android is dropping the ball is as follows:

  1. User’s don’t want to sign up to Google checkout
  2. There are plenty of places to find illegal copies of paid Android apps
  3. The store is over cluttered with crap apps
  4. The store has a poor design and has a rubbish user experience compared to the iPhone app store
  5. Paid apps were launched later than free apps and a tone was set in the market that apps were, and should be, free.

For which I respond as follows:

On #1, Google should do one of two: 1) require and capture credit card information the first time a user tries to buy a premium application, or 2) integrate with the network operator’s billing. On #2, true, but #1 is the main issue. On #3 and #4, I totally agree, plus, the good apps are hard to find! A better way to find applications is needed. On #5, I totally agree as well; the wrong expectations were initially set.

Alex followed writing that developers should be focusing on the platforms that are most “useful” to as many people as possible in the world… these being J2ME, Web and S60.

But useful is *very* relative. For talking on the phone? For writing applications? For deploying and making money from? I used to think as Alex… yes, it all sounds reasonable — target the platforms that (in theory) have the largest subscriber reach. Well, that is, until you take into consideration “Show me the money”, as Ajit likes to say.

From the “show me the money” perspective “rich development platforms and ecosystems” have proven, finally, successful. When I say “rich development platforms and ecosystems”, ecosystems go beyond app repositories, and it is about all the details that make it work, which includes user experience, integrated billing/payment, social and not, feedback system, and all the goodies a good/properly designed app store is all about.

I remember the debates between Ajit and myself over Web vs. local apps a couple of years ago, including at JavaOne Motorola Keynote, where I defended local applications while Ajit debated that “AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development” (note that he wrote J2ME but he really meant local apps). Today I can humbly say that I was right about local apps, and that “AJAX will not replace local apps as the platform of choice for developing mobile applications”. At least not yet. Ajit was/is right that mobile web apps will be huge, but they will in a different way as when it comes to richness and user experience and making money, today it is about a local apps.

And it took Apple to show “us” the way.

App Stores have proven central for developers (i.e. “show me the money”), and for subscribers (to easily find and download apps). And as a consequence, have proven beneficial to network providers themselves – gosh, it has taken so many years for network operators to finally open their eyes, not be so paranoid and over-controlling, and agree with common sense — it is an ecosystem after all. So now, all are converging into similar solutions such as iPhone’s App Store. They have to – the power is shifting to the subscriber itself, and to the developers who are bringing applications, software to the market. And those platforms that don’t play nice with the ecosystem, will fail.

So the argument that subscribers would not download local apps, argument a number of us didn’t agree with and defended against over the years via our blogs and apps, resulted in a non-issue. Yes, users will download rich, useful applications, and even better, will pay for them if given ways to easily find, pay for, and download those applications. While other types of apps such as Web and SMS, well, subscribers do like, but for free! Don’t you agree? What this translates to is into business models centered on the subscriber vs. “the other side of the subscriber” such as businesses, etc.

A word on the various platform

A word on iPhone: the device, the platforms rocks. I have an Android (personal) and an iPhone (work). And the iPhone is a beautifully designed piece, overall, from hardware to software. AT&T will hurt and cry if/when iPhone goes to other operators. As a sidenote, see ReadWriteWeb article by Sarah Perez titled The State of the Smartphone: iPhone is Way, Way Ahead, where she explores a recent report by Flurry that concludes that the iPhone is way ahead when it comes to mobile apps (based on the number of developers, apps and consumers). But, let’s take this report “with a grain of salt”. Why? Because it can be biased as follows: the majority of the developers using their analytics instrumentation code might just be iPhone developers, thus, the sample-set is biased by default.

A word on Android: just give it time. Android has the potential to be everywhere – phones, internet appliances, cars, etc. around the Globe, and thus many different types of developers (mobile to embedded). And it very well might allow developers to enter “emerging” markets easier. Judging Android after 6 months or so means nothing in the grand scheme of things. Time will tell (but I stand by what I’ve been saying thought).

A word on BlackBerry. They are getting it, but imposing a minimum app price of $2.99 — because “they value the efforts of developers” is bogus and is an attempt to sound developer-friendly. Let the market decide pricing!

A word on Nokia: they are trying with Ovi, but keep it simple! I really hope Nokia hits the ball out of the park –but they should consider simplifying their portfolio tho, see On Nokia’s App Store Strategy. Nokia’s attempt to do integrated billing for their App Store and (eventually) requiring Credit Cards mean they are thinking the right way.

A word on J2ME: Java ME suffered over the years due to 1) the process that created it was too slow to adapt, allowing for inconsistent implementations and incomplete API-sets, 2) its security model, and 3) lack of integrated app repository (i.e. app store). I still believe it has potential to be the platform of choice for mid-level phones. Specially with the latest MSA API-stacks and MIDP3 that (I hope) will come out later this year. And today,if you have the right market and channels, go for it.

A word on Web: best channel for apps that easily bring “generic” content out to people. Huge potential, especially with efforts such as BONDI and HTML 5 persistent data and the Canvas elements. In any case it is always a good idea, if it is applicable, to have a mobile web version of your app.

A word on short messaging (regardless of SMS or Twits): best channel for notification-like distribution. Second to none. True SMS is way to expensive and prohibitive for many; SMS though is a cash-cow for network providers who must be terrified of Twitter. If targeting notification-like app such as promotions SMS and Twitter is the way to go.

A word on voice apps: I wish we spend more time investing/researching this mode of interaction.

A word on SIM-based apps: The SIM card will always be at the center of mobile apps – directly or indirectly. New technologies such as JavaCard 3.0 and Smartcard Web Servers (SCWS) have the potential of bringing a new breed of mobile applications. Still developing SIM-card based applications is a niche and very network provider oriented, but if you have the relationship w/ the carrier, go for it!

And what the best type of application is? The hybrid app! This is a rich *local* app that is very good at consuming and rendering web content, as well as direct messages (i.e. SMS, Tweets). In the future, mobile web has tremendous potential but again, it is about making money *today*.

So in conclusion, we have to agree that today, integrated app stores that caters subscribers directly is the best channel for subscribers, and developers, and for operators as well. The potential for reaching more subscribers via J2ME, S60, and Web do exist, but but one thing is to create and attempt to deploy apps for those platforms, and the other is those apps getting payed for, downloaded and used.

As a recent report by IDC (Scott Ellison) titled “Developer Strategies for Success Shift as Apple iPhone Apps Store Passes 1 Billion Downloads” concluded:

Apple has demonstrated — again and again — that the success factors in mobile can change in the blink
of an eye — indeed in as little as 3 quarters in the case of the Apps store. The Apps store is increasingly
central not only to Apple, but to any developer or company seeking to play in the mobile applications and
content space. And understanding the shifting success factors within the Apps store is key to success
both on the device and in the digital marketplace that continues to remake mobile.


P.S. Anders Borg (Abiro Mobile News) has written an excellent analysis of this blog piece — see The state and future of mobile applications. And I like very much Michael Yuan‘s comment saying “What developers want is to address the “maximum number of people who are willing to pay”; exactly!

15 Mar

Reminder this evening (Sun Mar 15) – Mobile Web Apps & Widgets Meet-Up @ Driskill

A reminder that this evening, Sunday March 15 don’t miss the “Mobile Web Apps & Widgets Meet-Up” at 5:00pm:

  • Event: Mobile Web Apps & Widgets Meet-Up “Find out about your chance to win £20,000″
  • What: Informational Meeting
  • Host: Vodfone/Betavine & OMTP
  • Start Time: Sunday, March 15 at 5:00-8:00pm
  • Where: Driskill Hotel Bar

To see more details and RSVP, follow the link below:

Or if you don’t use Facebook, just show up.


02 Jan

Mobile Apps in 2009: Local/Native, Mobile Web, App Stores

Happy 2009 New Year to all my readers. My first post of the year is about mobile applications: local/native vs. web, and app-stores.

App-stores have been shifting the balance on application development and distribution (back) towards local/native applications. I don’t mean to undermine mobile web which will continue to be very important and very large for access of information of type “web content”. But the reason for this is the same reason I’ve been preaching for a long time: the ability to deliver/maximize “application richness, functionality and experiences” – which (today) maximizing these is only possible via local/native applications. This is the same topic took Ajit and myself into a debate at JavaOne’s keynote a couple of years; that was fun.

What I’m describing above can be seen on the iPhone which is the best mobile web handset today, and which redefined and raised the bar on mobile web applications, yet the really cool applications are local/native, and more importantly, developers of local/native applications seem to be the ones who are generating (receiving) the most revenue – after all, it is about making money. And this trend will continue… I do believe that in the future mobile web will be able to match the richness and functionality of local/native applications, once the proper APIs and functionality are put in place and become standard, and that today a happy medium are local/native applications that consume mobile web content; i.e. hybrid apps providing the best of both worlds.

And when combining the above with App-stores, which provide for the application discovery and revenue streams for developers, the market place becomes very attractive and thus active.

But to be successful, app-stores must exhibit certain characteristics:

  • From the end-user perspective: the app store must be seamless and well integrated into the user experience. Downloaded applications must work. There must be a good selection of high-quality apps. Integrated checkout/payment is easy and straightforward and secure. The end-user is in control, including influencing how applications will perform on the market (via feedback that influences ranking).
  • From the developer perspective: there must be a low cost and barriers to entry and distribution. Must provide application visibility (see below). Good revenue model. Provide feedback back to developers for improvement.
  • Application visibility: the app store must provide the means for good application visibility. Already established applications are ranked appropriately based on user feedback, while new applications (including new versions) go into a different bucket that allows them to be visible regardless of ranking (perhaps for a period of time).
  • As Ajit writes, must provide a true ecosystem (that benefits everyone: developers, network providers, the end-user, and so on).

Part of the above is why the iPhone has been successful. And is also the reason that I expect the Android app store to do well once it starts paying back to developers — it is just then when the Apple and Android stores can be compared.

There are app stores for Java ME, for example GetJar. The problem faced by GetJar is that there are things that are out of their control, such as cost and barriers to entry (due to fragmentation and certifications and fees and it is just a pain-in-the-neck to deal with network operators issues in general), and not being well integrated (seamless integration) into the overall user experience.

For years I’ve been attributing the lack of integrated solution for Java ME that works (per the above) for application discovery and download and revenue share, as one of the top the reasons why Java ME has failed to maximize its opportunity. As a member of MIDP expert group, this is an important lessons learned for me, that sometimes you do need to include such functionality into the platform vs. expecting 3rd parties to solve the problem; this seamless solution is still needed for Java ME…

On Goodbye 2008 and welcome 2009 and some predictions on mobility I made some predictions on app stores, which I will repeat here:

  • Google will introduce a checkout process for its app store, and developers wanting to make money will notice; the Google app store will explode with a large number of applications.
  • App stores will continue to have its huge effect on mobile apps and distribution. Due to the revenue and fast distribution models offered by iPhone and soon Android app stores, developers will first target such local applications (vs. mobile web). An even larger number of local/native applications will be created and distributed via app stores for Android and iPhone.
  • The BlackBerry app store will be somewhat successful.
  • Someone will introduce an app store for mobile web that goes beyond an application catalog. dotMobi will take leadership by going beyond an application catalog but also providing an associated business/revenue model.

Last but not least, and related to this topic, check out Paul Golding (Wireless Wanders) on his video blog entry Mobile 2008/9 all about App Stores where he discusses and provides his insight on why app stores have been important in 2008 and how important they will be in 2009… right on.

Also related to this see Ajit on Mobile Web Megatrends event – Making money from Appstores – Singapore – April 27 and 28, as well as his related thread on ForumOxford.


12 Nov

On Mobile Web Development — Develop mobile widgets with Yahoo! Blueprint

I’ve written an article/tutorial on mobile web/widget development using Yahoo! Blueprint; see Develop mobile widgets with Yahoo! Blueprint (IBM developerWorks). The article shows how to develop a Weather widget using the Blueprint XML markup and infrastructure, PHP for server integration, and the consumption of Yahoo! services on the web.

Developing mobile applications can be a daunting task. With hundreds of handsets to develop against and support, mobile application development can be time consuming and costly.

With Blueprint, you can author a mobile application one time that can be targeted at mobile devices with a browser (or devices that support the Blueprint platform), allowing you to potentially reach thousands of users. In this tutorial you will see how to develop a weather mobile widget using the Yahoo! Blueprint platform.

This tutorial is for developers interested in learning how to develop mobile widget-based applications using the Yahoo! Blueprint platform. While this tutorial is for entry-level developers, general knowledge about Web applications, mobile applications, XML, and PHP is desirable, but not essential.

The article is dedicated to the memory of Heidi Carson:

This tutorial is dedicated to the memory of Heidi Carson. She was the editor of IBM developerWorks (dW) Wireless and Web development zones. I used to write about mobile and wireless for her; many years ago Heidi gave me the opportunity to write for dW. And she was friendly, kind, and always willing to help through the process. As I learned that she has left us, I’m saddened. But a part of her can be found in each of my previous articles at dW.


10 Nov

The Programmable Web – 1,000 Web APIs (Nov 2008)

The Programmable Web reports that as of Nov 2008 it has 1,000 Web APIs on its directory.

You can see the distribution below (which looks pretty balanced all around) with Mapping APIs at the top:

And what is the preferred way to expose and consume Web APIs? The following chart shows REST at the top, with SOAP second:

(my recommendation, to use RESTful calls and XML Feeds, and consider JSON for mobile-to-server Data Interchange)