Aral, a well respected member of the Flash community recently posted an interesting article to discuss our mobile and devices strategy.  It’s really great to see community members thinking about our approach, and yes, even criticism is welcome.  So here I’ll try and address Aral’s points and demonstrate why we have the right approach in the immediate term.

Hopefully we can put a few minds at rest

Adobe’s current mobile strategy is very similar today to what it always was: get the Flash Player on as many handsets as possible. Let’s qualify that statement, however, with some all-important details, starting with differentiating the two types of Flash support that Adobe wants to implement on devices:

• In-browser Flash support (plugin)
• Standalone Flash application support

Markd: It is absolutely true that our intention, working with our Open Screen Project partners, is to enable the Flash Platform to extend from the desktop and web to devices.  This includes everything from desktop PCs, netbooks/Mids, smartphones and ultimately to the Digital Home.  We believe that by ensuring the availability of a highly optimized and consistent platform that we can enable the creation, and continuation of innovation across all screens.

Some time ago we agreed with our partners that the browser and standalone use-cases were key in this strategy.  Our partners see demand for these, in part because of competition from the iPhone OS and of course to help with their applications strategy.  The Flash community is one of the largest, and obviously most creative group of professionals creating rich user experiences.

For those reasons, among others, we believe that this will result in an uplift for the community and ultimately more business for all of us (we sell tools and services remember).

In-browser Flash support is good*

Getting in-browser Flash support on devices is a logical and understandable goal and Adobe is right to devote as much effort as possible into making that happen. In-browser Flash support on mobile devices means that your mobile phone can render today’s web (which, like it or not, contains heaps of Flash content) faithfully and thus provide a similar experience to what is possible on the desktop.

* That said, given that Flash content is notorious for its high CPU (and thus power) usage, and given that a lot of Flash content on the web today is undesirable from the perspective of the end user (ads, intros, etc.), it would make sense for such in-browser implementations of Flash to voluntarily default to a Flash Block behavior (i.e., have Flash disabled by default with the option to activate Flash content if and when the user wants to.)

Markd: We definitely see a huge value in ensuring that web experiences are made available on devices.  With Flash Lite we spent a huge amount of time and effort in optimization, battery performance and developer workflow (Device Central).  By integrating our engineering teams we added all of that experience to the new Flash Player 10.1 and then some, the proof will land early next year.  That said, you will still have to understand how the Flash renderer works and create experiences that are suitable for devices.  That is true of all development platforms without exception.

I don’t think that blocking Flash as a default option is very important for the vast majority of users.  Many simply want a complete web experience, and while in theory browsing could slow down we have invested alot of energy into startup/shutdown/instance management performance.  Feel free to pass judgement when you’ve actually seen it in action.

The remainder of this post will deal with Adobe’s attempts to get Standalone Flash application support in mobile devices.

Flash Lite: stillborn

Adobe’s initial mobile strategy, dating back to 2005, revolved around getting a cut-down version of the Flash player called Flash Lite on as many handsets as possible.

According to Adobe the number of Flash Lite devices shipped should have reached 1 billion in 2009. While that seems like a huge number, it’s rather irrelevant. For one thing, there is more than one version of Flash Lite so that 1 billion number includes outdated players. Also, that number hides further segmentation in that it includes both devices that support only in-browser Flash content as well as those that support standalone Flash applications. Finally, and most importantly, Adobe failed at making it possible for developers to monetize Flash content and failed to provide compelling reasons for developers to create Flash content for Flash Lite.

Why did Flash Lite fail? Because it went for a lowest-common-denominator approach, trying to support as many devices as possible, instead of focussing on creating a great user experience on one device and expanding from there. In other words, it failed because the focus was on features (in this case: wide-range of device support) instead of user experience.

Markd: Today we have shipped over 1.2Bn devices with optimized Flash Players, but do not ignore that ~700m of these were shipped in the last year.  To call them outdated negates the fact that regional segmentation, and in some cases carrier control, has enabled highly consistent distribution in key markets.

In some cases platform restrictions have limited the availability of standalone or browser plugin support.  This opinion is quite real, sometimes unfortunate, but ultimately based on an out-dated principle that content must run on every device at all costs.  At times I’ve heard this same error crop up from those building iPhone applications, who mistakenly believe that everyone has an iPhone (even when there are 3 devices and 5 OS versions).

I have to disagree completely with the principle that it is Adobe’s role to create an entire ecosystem.  It is not the role of a tools vendor to build businesses to buy their tools, that is of course completely impossible.  In the two years that I have been working on this ecosystem we have seen applications distributed to millions of users, millions of dollars have been made during my time.

One simple game made $2m USD last year alone in one country, and it took 2 weeks to create.  Services have been created in Europe (eg Playyoo) with various successes in the US also, some developers reaching over the $1m USD mark in under a year.  Is that successful?  In fact “sometimes” it is, in reality it depends on your expectations.

The problem is not that we failed to provide monetization, that we don’t have an AppStore or that we reached too many devices.  Flash Lite provided an incredible foothold and allowed us to build a new opportunity in a highly complex ecosystem.  That ecosystem is global and while we didn’t see many signs of “success” here in Europe, in other parts of the world like USA and Japan we did.

I’m unsure how wide and global device support could have affected user experiences, although I’m sure that companies like LG, Samsung and Sony Ericsson would disagree entirely having sold hundreds of millions of devices using Flash as the user interface engine.

Open Screen Project: same old, same old

You would think that Adobe would learn from its failure with Flash Lite that getting your technology on a huge number of devices isn’t worth the effort if no one wants to use it. Unfortunately, their strategy hasn’t changed with the introduction of the Open Screen Project.

The Open Screen Project aims to remove the fragmentation created by Flash Lite and ultimately aims to have a single Flash Player (the latest one) run on every device on the planet (cue: hysterical world-domination laughter). It seems that Adobe has learned nothing from the recent failures plaguing another company with a similar strategy for its operating system: Microsoft.

Where Microsoft struggles to provide at least a mediocre user experience across the countless hardware combinations that it must support, Apple runs circles around it: Having limited itself to a handful of hardware configurations – all, furthermore, within its control – Apple can provide its users with an exemplary user experience. Apple can do this because it wisely chose to control both the hardware and the software, limit segmentation, and focus on the user experience instead of expanding effort in a fruitless quest to run on any given hardware configuration on the planet.

Adobe’s Open Screen Project is a Microsoft-style, Age of Features strategy that aims to get Flash running on every mobile handset on the planet, user experience be damned. The question is: who cares if you can run the same crappy experience on every handset?

Markd: If Aral had come to see my session at Flash on the Beach then he would have heard my talk on “Relevant Reach”.  The principle is quite simple, the world of devices is complex, but largely follows an 80/20 rule for distribution.  In the EMEA5 countries 80% of users can be reached targeting only 20% (285) of mobile devices.  So in reality the wide reach is to ensure that as a developer, or content provider, you can reach the mass audience for a given market.

The Open Screen Project is an initiative that includes the worlds leading OEMs, even the ones that you’ve never heard of.  The achievements made this year are simply unheard of in the ecosystem, and there are more announcements coming of course.  It is however a slow-burner when you look at it from the outside, but if you look at what’s changing, the consistency, updated runtimes, hardware optimizations, chipset alterations.  All of these things are indicative of a massive effort to realise the full potential of Flash on devices, they are not a fruitless effort to scale, but a global strategy from the key players in the devices industry.

The argument “same crappy experience” is a pretty bold opinion and one that assumes alot about the expectations (and capabilities) of many in the Flash community.  We could all argue the value in targeting a single platform, and internally we considered this of course.  Ultimately however, the world is bigger than the device in “your” pocket (whatever that may be), and while Adobe is US company we must consider a global audience and customer base, something that many forget.

Flawed to the core

Adobe’s Open Screen Project and its mobile efforts will fail for one simple reason: they are not competitive when it comes to user experience. A Flash application running on a device will never have the same performance or the range of hardware support as a native application. It will never be able to compete with a native app in terms of user experience. Whereas Adobe’s plugin strategy worked on the web, it has and will continue fail on mobile devices.

(See this post for a more detailed discussion of Write Once, Run Anywhere and how it differs from Write Once, Compile Anywhere.)

Markd: This argument is totally subjective and based in principle on an understanding that Flash should be perfect at everything.  Flash Player 10.1 includes a new JIT technology to speed up the execution of Flash on devices, we use the power of new GPUs and hardware decoders for video and audio.  It is true, at times native code or feature access will be required, that has always been true on any platform.

Our goal is not to run desktop applications on mobile devices, and nor should it be yours.  The Flash Platform is designed to enable content production that *can* be optimized for any device or screen.  If you create an iPhone app then the same piece of content compiled with Flash Professional CS5 will also run on Android, Blackberry and Symbian.  That said, you will still need to invest time and effort to make the user experience compliant with the users expectations.

The user experience is reliant on the capabilities of the developer, the device, and the amount of money spent to achieve relevant reach.  Nothing in this business model is new, not even for the desktop developer.

So what should Adobe be doing instead?

In its scuffles with Apple to get Flash on the iPhone, Adobe has already stumbled onto the strategy that it should be following for mobile devices: focus on tooling and Just-In-Time (JIT) compilation to native applications.

In the upcoming CS5 Suite, you will be able to use Flash CS5 to create native iPhone applications. In other words, Flash developers will be able to reuse their existing skills to build native applications for the iPhone. Native applications that will be optimized for the iPhone and, hopefully, indistinguishable in terms of device-specific support and performance from native applications compiled using Apple’s own tools.

This should have been an a-ha moment for Adobe. And I did hope that it would usher in a new era of focus on Adobe’s core business (tooling). Unfortunately, that doesn’t seem to be case, if this short Twitter conversation with Ted is any indication:

I respect Ted greatly but what he (and Adobe) are missing here is that FPS (the frame rate an application can achieve) is just one tiny variable that affects the user experience of applications on mobile devices. How well are native features like location, multi-touch, local storage, etc., supported? A virtual machine is always going to be a couple of steps behind native applications in terms of device-specific support. It’s a losing game. The focus is wrong.

The majority of Adobe’s revenue comes from sales of its Creative Suite products. As such, it should be keeping its eye on the ball and adding value to the CS products as much as it can by making them the premiere toolset for creating mobile content. Getting Flash application support on handsets is not a requirement for this. Instead, Adobe should drop the huge amount of time, effort, and money that it is currently expanding on this and instead focus on enabling Flash developers to make native applications for the top mobile handsets.

Adobe’s next move should be to support native application creation on Android phones like the HTC Hero and Motorola Droid and maybe even adding support to Dreamweaver for building native Palm WebOS applications.

Markd: Aral’s point here is correct, FPS is not a deciding factor on the success of any platform.  When you put Ted’s comments back in context he is merely addressing a concern that iPhone applications packaged with Flash Pro CS5 will be slower than native applications.  This is absolutely true, even with huge efforts it will always be possible to create faster applications using native code.  Again, this is true of all platforms and you have to weigh up your skills and requirements.  Is it going to be easier to port your Obj-C game to Android than a highly optimized Flash game?  NO.

The core of Adobe’s business is indeed to sell tools, but those tools are successful because of the consistent and expressive platform that they support.  Creating a multitude of wildly varying toolchains and workflows for multiple platforms is not only expensive, but a red carpet for fragmentation.

We will not see another cross-compiler/Packager for other platforms, it simply isn’t required where Flash Player 10.1 and it’s nano-JIT are available.

As with most platforms the mobile space is changing all the time, for this reason we build frameworks and today that’s called FLEX.  In the future you can expect to see a more rational development workflow for mobile and devices, that not only uses Flex, but shapes it into a more optimized and expressive product in time.

Aral is right to ask questions, and frankly one of a small few who have fully considered the pitfalls.  In my role it’s a little alarming that everyone has been so quiet about all of these changes!  So in many ways I’m glad to finally discuss some of the concerns and wishes for the future.

We are of course in a transition period and as you’d expect mistakes will be made, courses will be corrected and we’ll all learn together.  There should be no doubt however that we are on the right track to make this a success together.  Even with our Open Screen Project partners, and with the best tools in the business we do need you all to play your part.

In the next couple of years we’ll all be created new experiences for mobile devices, televisions, set-top boxes and netbooks.  Our request is that you get to grips with these new platforms, and the new customer base now so that we’re collectively ready for the future of the platform.

Next year is going to be very very interesting, it’s time to get started.