The current trend towards HTML5 as the medium for rich browser experiences is leading to changes in large segments of the interactive industry. As people learn the details about HTML5 feature-support, how these features are implemented in various browsers, and what tools and frameworks exist to expedite and simplify this process, they are sharing their learnings in posts and other social media.
And the trends we’re seeing emerge lead to one primary conclusion.
From a business perspective, the key take-away from this period, is that dollar-for-dollar, experiences will provide less functionality, to a smaller percentage of viewers. Viewed another way, producing the same feature, delivered to the same percentage of the market, will cost more.
The Central Cost Driver: HTML5 & The Browsers
This conclusion isn’t a comment on the particular values of either HTML or Flash. Instead, it is reflective of one underlying fact: Adobe absorbs a not-insignificant portion of the cost of production for the rest of us who have used Flash to deliver rich experiences inside of browsers. Adobe ensures that Flash runs the same everywhere, in every browser, on every platform, so that you don’t have to. As such, Flash represents a significant subsidy from Adobe to the rest of the Internet.
There is no firm investing in a similarly consistent runtime for HTML5. Instead, HTML5 works just the same way as prior versions of HTML; it is an international standard, and the different browser makers implement it differently. Each browser you wish to support increases cost and time in production, first by increasing time spent in quality assurance efforts, and then the engineering time spent on remediation of browser-specific issues that are inevitably discovered. All you need is to review a few posts like Adobe’s “Why Can’t it Just Work?” to see what impact these inconsistencies can have on production.
The browser inconsistencies fall into two categories:
- Certain aspects of the HTML5 specification which are not implemented with 100% consistency across browsers and platforms.
- Some items are not standardized in the HTML5 specification. These are left to the browser vendors to determine.
Let’s examine both.
The Example of Audio and Video
Audio and video implementations across HTML5 browsers illustrate these points. Both audio and video are characteristic of many rich experiences (it is difficult to imagine a rich digital experience without sound; and video is also a highly consumed digital medium). So what does HTML5 support look like for audio and video?
Well, it’s sort of a mess. At least to anyone who has been working with Flash as a web delivery medium for the past decade (see Robert Reinhardt’s earlier post on The World of Pain that is HTML5 Video).
For example, the HTML5 <video> tag defines several attributes (poster, preload, autoplay, loop, and controls). However, as we learn from Long Tail Video’s post, “The State of HTML5 Video”, not all of these attributes are implemented in all browsers, and as such, they can not be utilized reliably (unless you force viewers to a specific browser).
That is an example of how not all browsers implement the spec to the same standard. However, some key items are missing from the spec. Newcomers to HTML5 video may be surprised to learn that HTML5 does not define a codec (or, in layman’s terms, HTML5 does not specify a video format). Neither does HTML5 define an audio codec.
If you want to deliver sound reliably to all browsers using HTML5, you need that sound encoded into at least two separate formats (and deliver the correct one based on browser detection). If you want to deliver a video to all HTML5-enabled browsers, you need at least two separate copies of that video. This clearly and directly increases the cost of production and delivery.
There are related issues that each support the overall trend I’ve highlighted above.
Stated simply, the HTML5 specification does not offer equivalent functionality to what Flash has offered for many years now. I believe that many firms are choosing (or feel compelled by market forces) to adopt HTML5 for their web presences, without a complete understanding of what features and functionality would have to be sacrificed.
There are many examples of the unequal features (many of which I hope will be explained and examined on Transitioning.to over the coming months), but I think two features of video are illustrative of this point.
For several years now, we’ve grown accustomed to full-screen video experiences delivered through the browser (which Flash has offered since late 2006). Unfortunately, full-screen is not supported in most HTML5 environments.
Another key aspect of delivering video online that Flash has long supported is adaptive streaming — the name of the set of features which enable the delivery of the appropriate level of video quality for the active connection speed, as well as other important features such as DRM. And, once again, as we can see from the graphic, below, HTML5 lags behind.
And it’s not just video. According to Zynga Germany’s Paul Bakaus, “the number one challenge with HTML5 is audio, and this needs to be fixed. It’s as simple as that. There’s no way we can work around audio, right?” As an example, HTML5 is only capable of playing a single audio file at a time. The issues go beyond the fundamentals, as Flash has provided some stellar support for audio, which can simply not be reproduced with current HTML5 technology and support. Alexander Chen reveals many of these in last year’s post about his experience attempting to convert his custom Flash music generator/player to HTML5.
The lack of presence and maturity in certain functionality in HTML5 will force certain features off the table completely, and significantly increase the cost of compensating for the lack of some others (such as producing fall-back experiences in Flash).
Now, despite those areas in which HTML5 lags behind, there is also a class of experiences which HTML5 will be able to provide better, and less expensively, than prior browser technologies. But even in those instances it is likely that the total cost of production will increase. Why?
Adobe Flash Player has long maintained a very large distribution base. In the era of desktop computing, you could essentially rely on the fact that people had Flash Player installed (and, for those that didn’t, it was a relatively small download). It was as close to ubiquity as possible in the digital industry (it is still very prevalent on desktops; it’s just that desktops form a diminishing share of the market).
HTML5 has not yet reached that level of support in the market. Yes, all new smartphones support HTML5, but many people still use their desktop computers to browse the web, and many still use older browsers without HTML5 support. So, even with Flash’s lack of presence on mobile devices, as we see in this infographic from Business2Community, 26% of viewers can not properly see HTML5, while only 4% of people can not properly see Flash. (If you think ‘skip intro’ was bad, let’s see how you feel about going back to the world of ‘Best Viewed in [the browser you do not have]’.)
This means that, unless you are willing to force all of your users to upgrade their desktop browsers (a notoriously difficult hurdle), HTML5 solutions must be supplemented with other technology: using either Flash as a fall-back, or deliver a less-rich experience in an older version of HTML. Pursuing either of these will further increase your cost of production.
Where We’re Headed
So, the major trend in interactive development is that, at least for the time being, it is getting messier and messier. As a result, web production of rich experiences will become increasingly expensive, limiting the number of firms that can afford production of outstanding experiences in browsers. Yes, existing and future frameworks, tools and platforms will make this adjustment easier, and less expensive over time (we are ripe for some workflow innovation in this sector). But that doesn’t change the basic market dynamic that is in play here: if you continue to play in the browser, you need to start thinking about increasing your budgets and/or trimming features.
Following from this, we will see many rich experiences migrate to native apps, such as iPhone or Android apps (in line with what others are seeing, as Amir Nathoo posted just last week). None of the above trends I have cited in this post impact native apps. They do not have inconsistent runtimes; they do not suffer from incomplete feature sets. They do, however, by definition reach fewer viewers (the web plays everywhere, on every connected device; an iPhone app only plays on iPhones where the user has taken the time and effort to install the app).
Increasingly, then, it will be the larger firms that will have the resources to invest in the creation of outstanding experiences inside of the browser. Others will have to trim expectations, either by delivering less impressive browser experiences or by delivering native device apps that reach fewer eyeballs.
In short, a 2012-dollar spent on interactive production will get you less functionality delivered to a smaller percentage of the consumer market than the same dollar spent only two years ago.