The Major Trend in Interactive Development
January 30, 2012 in Business, Tech
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.
Inflation
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.
Market Share for Different Browsers
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).
Browser Support for HTML5 Video Tag Attributes
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.
Browser Support for HTML5 Audio and Video Codecs
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.
Related Issues
There are related issues that each support the overall trend I’ve highlighted above.
Unequal Spec
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.
Browser Support for Full Screen HTML5 Video
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.
Browser Support for Adaptive Video Streaming in HTML5
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).
Incomplete Distribution
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.
You make some great points. Along these lines I’ve always wondered what roll the browser wars back in the late 90s early 00s had on the dot-com bust. Obviously it was mostly due to a bunch of gullible Wall Street yahoos who thought every startup .com was going to go gold. But there were also a lot of good ideas that could have panned out except they ran into development hell and could never get off the ground. The browsers of the day – Netscape 4 and IE 4 – were partly to blame.
I wonder how many startups today are going to drink from the fountain of HTML5 when in fact Flash is the best choice for their needs. They’ll end up spending more money, taking longer to get to market and that may be all that is needed to make the project fail. It won’t happen to everyone. But it’s going to happen to some.
Thank you, Dan.
There’s definitely a lot of kool-aid drinking going on. It’s difficult to watch.
But utilizing Flash does not counter this trend, either, because of the tablet and phone market. So, even on those projects where Flash is utilized for the desktop browser, those projects will still require fall-back experiences for mobile devices, or forego an increasing segment of the market. So, even approached this way, the total cost of production goes up, or the percentage of the market that you reach goes down. It’s just what’s happening.
Thank you.
I have an agency client (the only one I still tolerate!) who needs exactly this kind of information – and your summary is perfectly pitched.
Much appreciated.
And yes – drinking the kool aid can be fun, but the come down is a *killer*.
Hi Stray. I appreciate the feedback and am glad you found this to be a helpful explainer. It’s definitely designed as a ‘bookmark’ post, to be referenced when you find yourself in need of explaining just this situation. I’ve already sent it to a few clients, who have found it quite useful in understanding the changing nature of their conversations with their vendors.
Good luck!
-r
“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]’.”
It’s already started. Toyota created an HTML5 minisite to introduce a new car. The site only works in Chrome, and everyone else sees the stripped down Flash version.
Think about it: they spent thousands of dollars to create a site that will never be seen by about 75% of web users, then they spent thousands more for the stripped down version of the site, and then spent thousands to create the video equivalent of “This site best viewed in Google Chrome.”
http://www.toyota.com/itsacar/
And all to tell you that what Toyota sells is a car? Seems to me like they’ve got that sales point covered, and can safely move on to other points (like passenger safety, fuel efficiency, etc).
-r
@Tor that link is especially interesting when you see what the Toyota competitor Nissan is capable of: http://www.nissan-stagejuk3d.com. None of them work on my iPad though
Yeah, I think that site is fantastic (Adobe showed it off at MAX last year) — and also representative of an increasingly common failure.
Sure, you can basically ignore the phone market for rich browser experiences, but I think that you can not ignore the tablet market. It’s just too fun to browse the web on tablets. Increasingly, firms will discover that they are unable to ignore those tablet users, and will have to build experiences that will work on those devices, as well.
-r
As web developpers, we might be happy with the fact that it requires more work to build a website nowadays, for the reasons exposed here, as it means bigger contracts. The problem is that clients don’t understand that and it’s very difficult to explain it to them. Even when we tell them what we support for the price they pay, they almost always come back to say that there is a bug in such and such browser, which we explicitely don’t support. It’s not very pleasant to have that kind of confrontation with the clients, we have many other problems to solve already…
Agreed.
Bigger budgets are nice, but getting more done with those bigger budgets is nicer. As I said in my Flash & HTML5 post last year, “I didn’t get into the web to spend half my time debugging.” There is a palpable sense of frustration among many in the industry right now, precisely because this is not the direction that technology is supposed to take. Tech is supposed to get cheaper and easier to work with over time, but we are seeing the exact opposite occurring.
Your comment also reminds me that I really want to write a post on changes to the sales process, following the recent shifts in the industry. It’s a difficult and delicate subject, but oh so important. I still haven’t honed in on exactly what it is I want to say about it, though.
Thank you for commenting.
-r
An additional worry is that many clients are used to their Flash-based projects “just working” across all these different browsers. The mantra with HTML design these days is that the experience doesn’t have to look or behave the same in every browser… many clients will not tolerate this and will place the blame not on disparate technology but squarely upon agencies and individual contributors. That’s bad news.
I find your comment disheartening, if not entirely surprising. I was taught that pixel-perfection is vital to proper execution of any highly-designed experience. But I see how, with standard browser technologies, that could become prohibitively expensive in many contexts. Again, it feels as though the web is going backwards in some significant ways.
But, highly-performant, feature-rich, pixel-perfect experiences are still quite easy to achieve — in the context of native apps. So that’s where more and more of the interesting work will go.
As I started saying last year, the definition of a website is a place for people to go download your app.
Yep I can testify to this. I did about 4 quotes last year for html5 rich experience. All where rejected or the client went with a flash solution due to budget and browser compatibility concerns. The world may be moving towards html5 but there is no rational argument to can give to a client to pay extra for it.
What about hybrid native apps? Your conslusion is correct for desktop web browse experiences, but not other platforms. Creating native tablet/mobile apps utilizing HTML5 web views completely blows your conclusion out of the water. Native developers (Obj C / Java) are more expensive and less available in most web companies than your traditional front-end Javascript/HTML5 devs. It takes less time to develop apps using HTML5/CSS3 web views and it ports to both Android/IOS devices = very large share of the currrent market. Thus, the current trend of HTML5 is saving companies a lot of money in native app development when compared to paying niche IOS / Java devs to make complete apps.
Hi Stuart:
Thank you for reading the post and taking the time to comment. Yes, you note an important trend of cross-platform mobile apps, which can be executed in HTML5 (as well as Adobe AIR).
But, the trend of HTML5 apps does not counter the conclusions in the post. HTML5 apps on mobile include fewer features than native apps — so by selecting HTML5, you immediately sacrifice a not insignificant set of possible features. As well, while the code you write for your app may be called ‘HTML5′, it’s not actually the same ‘HTML5′ that might run in a viewer’s desktop browser — the code needs to be significantly re-factored for desktop or mobile app (you can’t just take the HTML5 from your desktop website and package it as a mobile app). And, of course, let’s not forget that, native or not, cross-platform or not, mobile apps have far less reach than the web — so either you need to also spend money on a website, or you need to forego those users who do not have your apps installed.
So again, we’re taking about a mix of more money, to produce fewer features, reaching fewer consumers. HTML5 may be more cost-effective than native dev for mobile apps, in your opinion, but it’s still part of this overall trend of fragmentation and increasing costs.
That toyota example is hillarious http://www.toyota.com/itsacar/ Especially funny is the content that sells you on “an optimized browser” whatever the F that means. Whoever sold the client on this one needs their head examined.
It’s a mess right now and it’s naturally going to cost more than necessary… but that’s sort of the same argument against green energy. All the momentum for HTML5 simply helps acceleration.
But, yeah, EVERY one of my “html5″ projects (which, to be fair isn’t all that many, but I’m just one person)… anyway, ALL of them have Flash as a fallback. But, it certainly doesn’t have to be a stripped down version. My work flow is: make the Flash version quickly to get sign off and then build the html version (I mean “versionS”) trying to share what you can. I don’t care too much that all this means more resources are going to programmers… or even that my product is becoming less competitive. If there was a “solution” in here somewhere I’d like to hear it. I think the best tact is to embrace it. Tell clients what they need to know, but then just let them spend money or effort however they want. I do think, though, long term it’ll come around.
Dan–I’ve never heard browserwars were a possible cause to the dot-bomb.
I’ll just repeat it as if it’s my quote to own: Flash dying has been the best thing for Flash devs since Flash itself.
[...] So, supporting all platforms bears increased cost; and ignoring platforms also incurs real costs. As I wrote earlier this year, “a 2012-dollar spent on interactive production will get you less functionality delivered to a [...]
[...] all, it’s one thing for me to continually argue (as I have repeatedly done on this blog, such as this post) that work is getting more complex and expensive; it’s another to have a statistically [...]