RIA Platforms for Mobile Services
This post is a follow-on to my last post Mobile 2.0 - what and how in which I introduce the key drivers for Mobile 2.0: ubquitous mobile broadband data connectivity, open & frictionless distribution and mobile rich Internet application (RIA) platforms. This post will mainly focus on the state of rich Internet application platforms as they relate to mobile and to some extent the role of the mobile Internet browser.
In terms of market acceptance, it seems to be clear that the front-runners in the RIA platform space are Adobe and Microsoft, AJAX (supported by Google). Here is my take on how they are starting to play out in mobile.
Adobe FlashLite, FlashCast with Flex
Adobe is clearly the leader with regards to having an established developer / designer community and having the widest install base of full RIA clients. Whereas Microsoft has the additional weight of having to drive adoption of Windows within mobile, Adobe is set on defending the position and reach of Flash. FlashLite is actively used on carriers like DoCoMo in Japan.
We are just starting to see the early entrance of Flash in N. America with Verizon shipping FlashLite on their high-end phones. Currently, you can only deploy Flash-based mobile RIAs either via Verizon (aka through Qualcomm and then through Verizon) or on a small number of smart phones off-deck. There are roughly 10-15 million Verizon phones that have some version of FlashLite. You currently can only access Flash as a BREW extension, which means you must become a BREW developer and pay the NTSL certification fees and share revenue with both Qualcomm and Verizon. FlashCast is slated to launch before the end of the year. Although FlashCast leverages the FlashLite engine, the types of services have been limited to essentially data casting services based on restricted RSS feeds and applications that are around. The significant benefit of Flash Lite is that existing Flash developers can utilize familiar tools.
Microsoft Silverlight with WPF
Silverlight is Microsoft’s answer to Flash. Microsoft’s Silverlight and WPF will likely have the best combination of both developer tools and design tools, they have had some trouble attracting the design community that Adobe has been able to garner to date. Also, it seems clear that Microsoft is still set on enforcing and defending its dominance as an operating system which is still lagging in mobile. A key question is whether Microsoft will actively support a Silverlight client for Java CLDC or BREW-based devices. And, if they do, will it be able to run on non-smartphone, feature-based phones that have limited memory. Microsoft has outperformed Symbian and Palm in the U.S. but may remain somewhat marginalized due to the success of the iPhone and Blackberry in the U.S.
I put together a diagram (based on data from mMetrics) that shows the percentage of data-capable handsets that support Java, BREW, Flash, Microsoft, RIM, Palm and Symbian.
Mobile AJAX
In and of itself, Mobile AJAX is not an RIA platform. It appears that Mobile AJAX companies are essentially becoming in-browser variants of on-device portals (ODPs). Mobile AJAX, when deployed via a Mobile Internet Browser, is missing a number of key features that are necessary for a true mobile RIA platform:
- > Limited integration with the phone’s core features such as call handling, messaging, PIM, etc.
- > Rich media support (e.g., audio / video integration) is non-existment
- >The level of interactivity is quite minimal when compared to that of Flash or Silverlight
- > Some of these limitations can be minimized when using a stand-alone AJAX-based application that can run independently of a browser.
The role of the browser
WAP
In the late 1990s, WAP was championed as the key enabler for accessing the Web from any device. It became the de facto standard for building page-based, websites on mobile devices. Due to the limited bandwidth, high latency and primarily text-based experiences, the phrase “WAP is crap” came to summarize the overall industry attitude towards WAP as a vehicle for delivering mobile applications and content. Although WAP is actually a collection of protocols, the term is often used to connote HTML-like sites on mobile devices. In fact, most WAP 2.0 mobile browsers support a version of HTML called xHTML. Over the past year or two, “WAP is back” has become the mantra. During the time that WAP was effectively de-emphasized, the mobile industry focused on “static” content such as downloadable binaries (e.g., games) and personalization content, i.e., ringtones and wallpaper. In addition to the improvement of enabling infrastructure (e.g., improved WAP browsers, better devices, better data networks), the re-emergence of WAP and the Mobile Internet has been driven primarily by (i) the availability of Mobile Internet browsers and high-end Smartphones with 3G data connectivity, and (ii) opportunity to create new data revenue streams from mobile advertising. The early impression-based ad networks and ad delivery methods that were proven and are currently thriving on the Internet are being replicated on mobile devices.
ODPs
The emergence of on-device portals (ODPs) developed for mobile phones is akin to the development of RIAs on the PC. ODPs are mobile applications optimized for accessing and interacting with content and information. They were initially conceived to address the poor user experience provided by resident mobile OS-based applications and/or WAP-based mobile sites and applications. ODPs specifically tackled problems that arose in WAP-based services such as compounded network latency issues, poor user experience & limited user interface, and most importantly, the high number of clicks required to access relevant data on a mobile device. ODPs typically deploy strategies related to caching and pushing data that creates a more responsive and immediate experience when compared to WAP-based alternatives. While ODPs provide a better user experience and have been shown to make finding, trying and buying content faster and easier, they must often be downloaded over-the-air (OTA) to the phone and almost always require complex, proprietary tools. This reliance on proprietary toolsets has increased the complexity for developers when creating and deploying new mobile services. Desktop or browser A number of ODP providers have focused on providing homescreen replacements. It is too early to determine whether these vehicles will drive data usage and drive premium content sales. Or, they may turn out to simply add yet another mediation point, and hence latency or delay, between the end-user and their desired destination. An interesting indicator to the future role of the desktop versus the browser is to watch when and how applications and services move from the browser to the desktop on the PC. I content that a majority of media access and network usage comes from applications and not necessarily the browser in-and-of itself. The PC-based RIA platforms are rapidly moving beyond the browser to the desktop. Examples of early initiatives in moving from the browser back to the desktop:
- > Adobe’s Integrate Runtime (AIR) extends their Web development to the desktop
- > Microsoft’s Silverlight is taking the .NET Framework and WPF both cross-platform and cross-browser
Mobile 2.0 will drive innovation
Irregardless of how Mobile 2.0 is defined and how the key enabling tools and platforms evolve, it will:
- > Encourage innovation
- > Lead to a creation and deployment model in which mobile services are rapidly brought to market
- > Enable a new market for existing web developers by letting them use standard, common web tools
- > Solidify multi-platform, multi-modal content and services.
At a minimum, it seems clear that the concept of ‘mobility’ is evolving to become associated with a state (e.g., a lifestyle) rather than a device. We will be able to momentarily attach our personalized access, content and services arbitrarily to any device, network and format.
I expect that Mobile 2.0 will come to represent a wide range of personalized mobile experiences resulting from open access and distribution networks coupled with frictionless, multi-platform content creation and connectivity. One thing is for certain, current telephony platforms (think IMS) are not in a position to enable and deliver these types of services consumers have come to expect.
Add starLikeShareShare with noteEmail
[…] There are other aspects of openness that these four categories do not distinguish. I have discussed openness in more detail in a past post entitled Two by Six Degrees of Openness – Apple and Google’s impact on the mobile ecosystem. […]
02 Oct 2009 at 1:10 pm
[…] my earlier post on openness, Two by Six Degrees of Openness, I articulate six types of openness from which to distinguish various “open” mobile platforms […]
02 Oct 2009 at 1:47 pm