Tag Archives: Web

Mobility in 2011: Mobile Apps, Webapps and Tipping Points

Posted on by

(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”.

…where:

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

ceo

Article: DOM-based data storage and retrieval using jQuery

Posted on by

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)

ceo

Article: Introduction to jQuery Mobile

Posted on by


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.

ceo

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

Posted on by

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.

ceo

The Google App Market – An Analysis

Posted on by

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