I gave the standard Director-centric response. “It’s a wind up toy.” I said.

“Get over it,” he said, “You are teaching it next semester.”

I installed the app – Flash 3– opened it and, 15 years later, I finally closed Flash CS 5.5 and walked away.

For me, the five years between 1998 and 2003, were the absolute best years. Nobody really had a clue what the app could do and, as is so typical in this business, we made it up as we went along. Branden Hall, some kid out on the East Coast, was doing amazing stuff with ActionScript. Eric Natzke was exploring Flash as an artistic medium. Hillman Curtis was quietly using it as a story-telling medium. Joe Cartoon put frogs in a blender and showed Flash could be a serious animation tool. Todd Purgason was moving Flash into the corporate market. Lynda Weinman was running FlashForward, which became the Flash equivalent of Woodstock. Local Flash User groups were springing up like weeds and the Flash Player was being installed at an astounding rate.

For me, my move away from Flash started, slowly, when Flash tried to go mobile.

In spite of all of the “Whiz Bang Smoke and Mirrors” presentations Adobe dropped on its Fanboyz at Max and elsewhere, they just never seemed to get it right.

My moment of clarity around that point happened in, of all places, Adobe’s Head Office in San Jose, California in 2009. I had just finished a presentation to the Adobe Education Leaders crew and someone in the audience asked me why I didn’t teach mobile to my students. My response? “I would rather drive chop sticks into my eyeballs.”

I went through my reasoning for that statement in typical academic fashion but the bottom line was something I had been feeling for over a year: There was no consistency of the experience. It changed from device to device and trying to develop a Flash movie that did that was futile.

When Adobe announced it was suspending mobile development of the Flash Player it was greeted with the usual storm of hair pulling, teeth gnashing and self-righteous sputtering. The way it was announced was “bone headed” but for me it was something I had sort of expected and I used my Google + page to explain my ambivalence and how I saw it as an opportunity to learn and teach something new. I also felt, in the immortal words of Yogi Berra, that this was “déjà vu all over again”. As I wrote:

“… A good example is the rise of devices and smartphones and, in a certain way, the death of Flash on these devices. Having lived through, and taught through, a few of these things – the rise of the internet, the decline of print publishing and the rise of Desktop Publishing, the rise and death of the Interactive CD, and the rise of web interactivity and motion graphics – the common factor behind this disruption is not a “new way of doing things”. It is a “new way of talking about it.”

That something “new” crossed my radar in the oddest place … a Flash Conference.

Doug Winnie, former Adobe Edge Product Manager, corralled me at FITC 2011 in Toronto, and asked if I was interested in looking at a new product – code name “Helium” – that was in the process of being developed. He sat me down in a corner, flamed up Helium and, as he handed me the laptop, said, “Tell me what you think.”

When I finished, all I could think was, “The magic is back.”

With the rapid pace of technological change within our industry we tend to have a short-term perspective on new technology. We focus on the immediate and the short-term future, which is dangerous but understandable, considering the pace of change we experience and embrace.

What we don’t tend to have is an historical view of this change. This sort of thing tends to arrive quietly, explode across the industry and disruption takes hold until we get a collective handle on the technology. Back in the late 80’s and early 90’s Digital Publishing literally wiped out art departments, type houses, printing shops, highly skilled trades (Film Strippers, PrePress, Typesetting) and, once the dust settled, a funny thing happened – these guys mostly went back to work once they discovered the computer was a tool and that nothing had really changed other than how we talk about it.

Are you seeing a trend here?

The current debate about HTML 5 and Flash, on this site and elsewhere, is nothing more than our dealing with disruption. Edge, through its use of HTML5, CSS3, JavaScript and so on, gives us a consistent experience across platforms ranging from the 32’ monitor on my desk to touch screen devices mounted in the back of taxis in Beijing to the smartphone in my pocket. How can this be a “bad thing”? The other point I have discovered is moving to Edge or other interactive motion graphics technology from Flash is not hard. The Flash skills developed over the years are easily transferrable to Edge. It is the same way of doing what we have always done. It is just a different way of talking about it.

Still Edge is a hammer . Flash is a wrench. HTML 5 is a screwdriver. They are just tools. This is something the HTML 5 zealots seem to overlook. Whenever one of those guys tells me HTML 5 is the way to go I simply flip them a video and ask them to get it to run it in a touch screen mounted on the back seat of a Beijing taxi crashing around the city. You use the tool best suited to the job at hand and if it is Flash … so be it. If it is Edge … then use it. Something else? Knock yourself out because the bottom line hasn’t changed: “Does it work?”

As I tell my students, nobody cares how you did it. They just care that it works.

So where’s the magic I was talking about? We are back where we were with Flash 3. We have a technology that is disrupting our lives and businesses and, this early in the game, we really don’t have a clue how to use it. Standards are in flux . Clients are confused. We are making it up as we go along and that is fine. It’s the way it worked in the past and is the way it will always work.

Deal with it because, in the final analysis, you have to admit …. Damn this is fun.

–

About the Author: Tom Green has been teaching with the Interactive Multimedia Program at Humber College since 1995. He was appointed to his current full-time faculty position in 2004. He is also the author of over a dozen books published by Pearson Education and Friends of Ed, including such best-sellers as Foundation Flash CS5 for Designers, Foundation Flash CS3 Video, and From After Effects to Flash: Poetry in Motion Graphics, and has produced an online and DVD video training series on Fireworks CS3.

Tom is an Adobe Community Professional, a member of Adobe’s Higher Education Leader Program in the post-secondary area, and a member of the Product Advisory Boards for Flash Media Server, Edge and Fireworks at the Adobe Corporation and the Camtasia Studio Advisory Board at TechSmith Corporation. He is also in great demand as a speaker and regularly does presentations at major industry conferences around the world, including D2WC, FlashintheCan, Spark Europe, TODCON, FITC, Adobe Max, Web Design World, and Digital Design World. He has conducted expert lectures at such post-secondary institutions as the Rochester Institute of Technology, Pasadena Community College, the Central Academy of Fine Arts in Beijing, the University of Wisconsin, the Sloan Merlot Consortium, the EMMA Foundation Master Classes for Post Secondary students in Hamburg, Germany and Toronto, and Red River Community College in Winnipeg.

Along with these industry efforts, Tom regularly contributes articles and tutorials to Layersmagazine.com, webdesign.tutsplus, the Adobe Design Center, and the Adobe Developer Center. His personal site is http://www.tomontheweb.ca.

I thought it would be helpful and informative to provide a brief round-up of what some others have saying on this subject over that time. This is not meant to be a comprehensive overview, but instead a representative sampling of what’s being said and written on these subjects.

The Realities of HTML5

I have read two fantastic posts in particular, about nuances in the consideration and adoption of Flash and HTML5. The first, by Noah Costello, specifically addresses how this shift in technologies is impacting interactive production in ad agencies. He addresses the details of actual implications of HTML5 adoption on agency workflows, budgets, and features. It’s just not an easy set of issues to confront:

Truthfully, HTML5 is a bit of a freight train right now.  The technical details don’t really matter, it has so much buzz and momentum that to stand in front of it and try to influence its path is a fool’s errand.  It will take a little time for it to run its course and for everyone figure out where it fits within the world of advertising and digital campaign concepting and development.

…

[Flash] was a great ecosystem for those involved.  Creatives could come up with big ideas and feel confident they were possible, without having to worry too much about the technology.  Developers were pushed to do some amazing work and often did amazing work on their own, which lead creatives to great new ideas.  One developer invents PaperVision 3D, another one figures out Augmented Reality Markers and next thing you know we have a live Big Foot interacting with you live on your webcam (www.livingsasquatch.com).

…

HTML5 cannot do everything Flash can.  In reality trying to create these sites in HTML5 is more like “Mission Impossible” and most of them would need to be re-concepted from the ground up; with creative and user experience design that was tailored to HTML5′s capabilities.  Could the ’Ethan Hunt’ of HTML5 Development pull it off? Maybe in a few cases, but what would be the cost and what percentage of the target audience will be able to view the site?  I know that with Flash sites, most clients were unwilling to allow a site published in the latest version of the Flash player until it reaches higher that 95% penetration.  Will a WebGL site that 50% of your visitors can use really be acceptable?  And we’ll often get briefs for Flash projects that have as little as a two or three week development timeline. Good luck with that in HTML5.

Ironically, most of the cutting edge, Flash-like HTML5 sites you see these days don’t work on tablets or smart phones either.  They either use HTML5 features that aren’t available in mobile browsers (WebGL), offer poor performance (Canvas),  or the layout and user experience design does not work properly.  This is perplexing since the primary argument for dropping Flash is compatibility on Mobile.

The technology aside, there are other fundamental problems with trying to make one site fit all. Screen resolutions are all over the place. Can you really expect to design something for a  22″ desktop screen that will look good on a 10″ tablet (iPad), a 7″ tablet (Kindle fire) and 3.5″ screen (average smartphone)? You also may not want the same amount of content on your mobile site, as lots of people like to find necessary information quickly and prefer more immersive experiences on a large screen when they’re sitting comfortably.

Costello concludes with real-world recommendations for agencies and developers:

 

• Don’t decide on the technology until you figure out your audience. Is the primary target mobile or desktop? What percent of your audience is on HTML5 compatible browsers?
• Figure out your clients goals. Are they ok with you targeting a smaller audience for the sake of industry buzz and awards? Or are they more concerned with overall reach to consumers.
• Creatives concepting HTML5 sites need to learn more about the technology and limitations.  You can’t assume everything you would have concepted for a Flash targeted site will be possible in HTML5.  Especially if it is running on tablets and smart phones.
• If the goal is a highly interactive site on the desktop that will reach a maximum audience, use Flash.
• If a site uses interactive video and/or alpha channel video, use Flash and don’t expect the same type of experience to be possible on mobile.
• If the site only requires basic animations (think animating layers of a photoshop document) and video in contained players, use HTML5.
• Deep content/copy heavy portals, corporate sites, and blogs should be HTML. This has always been a good rule.
• If the same site needs to work on the desktop and tablet expect less (in terms of interactivity, animation, and innovative UX).
• If the same site needs to work on the desktop, tablet, and smart phones, expect a lot less.
• Be careful not to expect a robust HTML5 site be built on a tight timeline. Extra time will be needed for build and more importantly QA/bug fixes. i.e. Don’t plan on approving creative two weeks before a site needs to go live.
• Understand that not all HTML5 features are created equal. Some work on mobile, but not desktop. Some work on desktop, but not mobile.  WebGL is a good example.  Currently it is not enabled in mobile browsers and Internet Explorer on the desktop.

Another post, from just last month, comes from Philip Donald writing about HTML5 misconceptions. In it, Donald gets into how actual feature differences between Flash and HTML5 should influence tech selection for different projects.

Firstly, HTML 5 offers a very convenient audio and video solution with some advanced functionalities. All well and good, but what many people ignore is the fact that these audio and video files are played within the browsers. Each browser has built-in plugins for audio and video but different browsers support different versions of the audio and video. Because of this, it becomes difficult to cater to the requirements of all browsers.

Secondly, the SVG and Canvas elements have definitely made it easier for developers to implement and integrate 2D animations, but it’s been observed that this animation has a detrimental effect on website performance. Also, HTML5 is proving to be weak when it comes to handling 3D animations, resulting in developers not being able to replicate an entire Flash website with similar efficiency in HTML5. There will always be limitations.

Thirdly, you can use HTML5 Rich Internet Applications, but don’t be under the misconception that they can offer you the same brand of efficiency and functionality that Flash/Flex can offer, for example Flash can directly communicate with remote services, whereas HTML5 cannot.

Now that you know what HTML5 cannot do, allow me to offer you a small list of things that HTML5 can do and, in fact, can do very well. This can also help reduce the misconceptions in a big way.

• You can create a single application that works on the iPad, iPhone, Windows etc. In other words, it facilitates platform/device independency — a huge benefit in itself.
• Helps develop a single website that works on the tablet, mobile, and desktop at the same time.
• If used well and the way it is supposed to be used, it can improve website performance.
• Enables the use of audio and videos tags across all platforms, but be prepared to do a bit of hard work.
• Video, audio and images are all written right into the codes, eliminating the need for any third party software.
• Quicker load time as compared to its older version because of WebSockets implementation.
• Offers great vector animations for graphics and light effect, but do not expect the moon, the sun, and the stars when it comes to animations; Flash is way ahead in this aspect.
• Provides appropriate built-in form validation and type declarations to offer specific keyboard support.

HTML 5 definitely has the potential of upstaging Flash in more ways than one, but it is presently a work in progress. Even in its current avatar it helps make mobile phone applications more accessible, and developers are now able to create universal applications for different mobile phones. Additionally, there is no doubt that it offers more flexibility in website creativity. For now, this is enough. What happens in the future is pure hypothesis.

I think that perhaps no post symbolizes the evolution of the online discussion as much as Long Tail Video’s post about HTML5. Whereas 2011 saw a massive (and often, uninformed) push to HTML5 video solutions, Long Tail Video (the makers of the JW Video Player) presents actual details about video playback features and format support, across browser implementations of HTML5 and HTML5 video. And (thank god) they go to the effort of keeping that post current, with new browser releases. This type of information was simply impossible to come by last year, but is essential to have when making tech decisions.

Adobe

The posts above demonstrate, Flash still supports many use-cases better than any available alternative technology. As just one real-world example, Giacomo Guilizzoni (founder of Balsamiq wireframing software, and better known as ‘Peldi’ to many in the Macromedia and Adobe communities) said in a recent interview that, while:

It’s fashionable to criticize Flash and Air these days, but the reality is that for certain kinds of rich, graphic-intensive, cross-platform applications, it’s still the only serious option.

…

We don’t have any current plans to switch to a different platform. A full rewrite is suicide for a startup, and like I said, our customers don’t care right now. Plus, I don’t really see an alternative right now either, HTML5 doesn’t even have full-screen support yet, let alone a good desktop installation experience or serious IDEs for JS development.

However, in the world of technology, many people make decisions not only on where things are (that is, what technology can do today), but also based on perceptions of where things are going. Flash and AIR, of course, are owned by Adobe, who significantly disrupted the markets for both Flash and AIR last November. Today, half a year later, while much of the discussion about HTML5 and Flash has evolved and become more nuanced, what is Adobe’s influence on explicating or defining a direction for web technologies?

One of Adobe’s primary initiatives around HTML5 is called Edge, which is a new HTML5 animation tool. Edge (for which Adobe maintains three separate URLs, here, here, and here on Adobe labs), though, is still not a released product. Similarly, Adobe is now promoting that the next version of Flash Professional will have the ability to export HTML5 animations. As of today, there is still no professional-grade HTML5 tooling from Adobe — everything remains in the future — leaving the community of developers with continued questions as to how these new tools will actually impact their work.

On Flash (and AIR), Adobe has attempted to reduce uncertainty and solidify expectations as to the direction and future support for the platform. Earlier this year, Adobe published a road map for Flash Player and AIR, reiterating their emphasis on Flash and AIR as a solution primarily for video delivery and gaming.

Looking forward, Adobe believes that Flash is particularly suited for addressing the gaming and premium video markets, and will focus its development efforts in those areas. At the same time, Adobe will make architectural and language changes to the runtimes in order to ensure that the Flash runtimes are well placed to enable the richest experiences on the web and across mobile devices for another decade.

There was “a lot of negative discussion [in the community] around the focus on gaming and premium video talked about in the whitepaper,” according to educator and developer Joseph Labrecque, who penned a defense of Adobe’s positioning of the technology in the document. Still, for a roadmap to be valuable, the markets and community must trust that it is accurate — and, in Adobe’s case, that trust was significantly reduced last November. So, for example, in a pair of recent Tweets, author, developer and community leader Phillip Kerman noted his concern that, despite the representations in its product roadmap, Adobe will drop support for mobile AIR (just as it did for mobile Flash Player):

As a case-in-point, earlier this year, Adobe promoted that anyone could send questions to Adobe CEO Shantanu Narayen (one of the top 10 most overcompensated CEOs in America, according to Mother Jones Magazine) by including the hashtag #askShantanu, and he would answer them in a conference keynote. All told, only six questions were posted. The most direct question was tweeted by developer and community leader, Peter Elst, who asked: “with respect, do you feel you’ve taken enough personal responsibility around the massive communication failure in November? #askShantanu”. As Elst elaborated on his blog:

It is in my opinion time for Adobe as a company to clean up its mess and move on, but to do so it needs to come to terms with the present situation and acknowledge its failures. If nothing else, I expect from a CEO to be willing to step up and defend his position.

At the scheduled event, Narayen did not acknowledge or respond to any of these #askShantanu questions — much less the one from Peter Elst. With this style of leadership emanating from the top of the organization, it is unsurprising that the once vibrant community around Flash (and Adobe’s web products, in general) continues to deteriorate. As Adobe Certified Instructor (ACI) Dee Sadler tweeted earlier this week:

• Flash isn’t supported in iOS devices
• Android is dropping Flash support
• Google Chrome support of Flash on the Mac seems to add new bugs that are out of our control in every new release
• Developers aren’t really excited about doing anything related to Flash

Meanwhile…

While the industry discussion is becoming more articulate, nuanced and accurate, this process occurs more slowly in the broader market. The sophistication of the tech discussion in sales and with clients (unsurprisingly) lags behind what developers know and understand. Earlier this year, Yakov Fain asked if “Will HTML Force You to Lie?”

Yesterday, one perspective customer asked me if we have an HTML5 version of this application. I said, “We can create one for you”. The next moment I realized that I lied and added, “I mean, most of it can be turned into HTML/JavaScript, but some heavy duty stuff we’re doing now would be too expensive to re-create in HTML/JavaScript”.

I didn’t start questioning why they even wanted to do a pure HTML5 version. I know what the answer would be: “Everybody goes HTML5, we want it too, and we want it now”. You can’t piss against the wind. You shouldn’t attack windmills unless your name is Don Quixote.

Clearly (and again, unsurprisingly), it will take more time for these discussions to approach reality. The education of clients often presents unique challenges in software; it is even more difficult in light of the legacy of the HTML5 and Flash discussion from the past two years, and will likely remain so for at least the next year or so.

At the same time, the technological landscape in which all of this is occurring is becoming increasingly fragmented, complicated (and expensive). As just one recent example, the introduction of the pixel-rich iPad 3 has led once again to basic questions (without easy answers) about how to deliver images inside of a browser (something that I think we all thought was resolved over a decade ago):

The problem is simple: you need to send smaller images to small screens and larger images to larger screens. Sending a huge iPad-optimized image to a device with a max resolution of 320×480 just doesn’t make sense. At the same time, when bandwidth isn’t an issue, most sites will want to serve high-resolution content to displays that can handle it.

The ideal solution would be to detect both the resolution of the screen and the available bandwidth. Then, based on the combination of those two factors, the server could offer up the appropriate image. Currently that’s not possible, though there are already proposals to extend HTML to handle that scenario.

The Responsive Image Working Group is a W3C community group hoping to solve some of these problems. The group is proposing a new HTML element, <picture>, which will take into account factors like network speed, device dimensions, screen pixel density and browser cache to figure out which image to serve up. Think of it as a much smarter version of the old lowsrc property. So far though it’s all hypothetical

And, as Amir Nathoo writes, if you are hoping to achieve viral success, you really do need to invest in proper experiences on all of these increasing varied devices. 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 smaller percentage of the consumer market than the same dollar spent only two years ago.”

In my inaugural post on this site, I explained that “while there are no clear answers, you can still make informed decisions”. More and more people are learning what variables and parameters influence informed decisions in this climate, and thankfully, some of them are taking the time to share them. In that sense, I think the industry is now moving into another phase. One in which more honest discussions occur, where there is a much less reflexive attitude towards technology evaluation and decisions, and these technologies are increasingly well understood by a wider segment of the industry who, on a daily basis, must confront the challenges of actually executing interactive experiences in a highly complex environment.

And that is most definitely a good and positive trend for the broader health of the interactive industry.

• Purpose: Why are you offering video online? Do you have product demos or marketing content that everyone who visits your online presence can view? Or, do you have training videos, or exclusive content that only specific customers can view?
• Target audience: What devices and platforms are watching the video content? Have you identified a particular audience that needs specific optimized video delivery (e.g. Apple’s HTTP Live Streaming requirements for iOS applications)?
• Production: Is your video content produced with high visual and audio quality? How frequently do you need to deploy new video content to an online audience?
• Resources: What is your budget for online video, from production to post-production to deployment? Do you have managed resources (e.g. internal staff or contracted services) that can handle ongoing encoding and hosting tasks?

The answers to all of these questions determine how your video content will be produced, encoded, and distributed. For my approach outlined here to be worthwhile and meaningful, here’s a sample response that could benefit from an optimized online video deployment:

• Purpose: You have video content that you want to keep within your control and domain. You’d prefer not to have videos in their entirety cached on the viewer’s device or computer.
• Target audience: You have content that you want to optimally display on iOS devices, and play well across desktop browsers new and old.
• Production: You have high quality video content, and you create it on a semi-regular basis (once a month, a week, or daily)
• Resources: You don’t mind paying for premium video services, but you also don’t want a high upfront cost for encoding and hosting.

Note: In a future article, I will position services such as YouTube and Vimeo within a larger comprehensive online video strategy.

Goal: Reduce encoding efforts

As I mentioned in my earlier post, there is no single HTML5 video codec. Over the last decade, most encoding tools have honed their H.264 encoding options and their overall output quality. WebM and Theora encoding tools and options though are still quite limited.  If you stick with H.264, you’ll encode your video content with H.264 Baseline profile for smartphone delivery, and H.264 Main profile for tablet and desktop delivery. Within the next three years, I suspect we won’t need to worry as much as about H.264 Baseline profile as smartphones will universally have the GPU and/or CPU power to handle more advanced video decoding. Apple iPhone 4 and 4S already support H.264 Main profile playback. If you’re really savvy with your deployment, you’ll encode multiple bitrates in both H.264 Baseline and Main profiles for adaptive streaming. On videoRx.com, our automated presets output anywhere from 4 to 16 targets for adaptive streaming.

Goal: Reduce player logic/overhead

The standard mantra is to use the HTML5 <video> tag and only use a Flash-based video player as a fallback where the <video> tag isn’t recognized. I recommend to my clients the exact opposite approach: position a Flash-based video experience first, and fallback to HTML5 <video> support if the viewer isn’t on a platform that supports the Flash Player. With this approach, you can always use H.264 as your single video codec, because Flash Player supports it, and non-Flash-compatible platforms such as Apple iOS do support H.264 natively.

You can still create HTML5 and SEO friendly web content–you’re just going to use JavaScript to replace a <video> tag with Flash <object>/<embed> tags to play the video wherever the Flash Player is installed. This approach is not the same as putting <object> and <embed> tags within a <video> tag. On the contrary, JavaScript is used to swap out the <video> tag even within HTML5 capable browsers, to ensure consistency of H.264 playback. If you only have H.264 content, a non-H.264 compliant HTML5 browser such as Mozilla Firefox will not fallback to a nested <object>/<embed> Flash video player without the aid of JavaScript. MediaElement.js is one such library that will automatically insert an alternate playback engine if you only have H.264 content available. However, MediaElement.js doesn’t detect or implement adaptive streaming capabilities for both iOS and Flash Player. Therefore, if you want to use adaptive streaming techniques, you have to build your own JavaScript library like I’ve done on videoRx.com.

Note: If you’re wondering why I’m positioning the Flash Player as the first tier of playback over HTML5, just look at the lack of true fullscreen playback in HTML5 browsers. Firefox has only recently released its fullscreen API for their latest beta releases of Firefox 10. There are a slew of other features that we don’t have in current HTML5 specifications that the Flash Player has had for quite a while, but I’ll leave that discussion to another article.

Goal: Optimize delivery for mobile and desktop

Finally, encode and deploy using adaptive streaming technologies. While adaptive streaming was once a domain for broadcast and movie distribution companies, today any video content creator can deploy adaptive streaming video with even the most meager of budgets. I’m a huge fan of Wowza Media Server (WMS), which reduces much of the complexity and overhead with streaming management. You can use WMS on the cloud with Amazon EC2 and Amazon S3 storage for a relatively minor cost (or use a AWS-backed  service like videoRx.com to even further minimize hosting costs). While you can use a standard web (HTTP) server with Apple HTTP Live Streaming (HLS) deployment , you need to pre-process all of your video into manifests and timed MPEG TS chunks. Once you’ve committed to that pre-processing workflow, you have to also encode non-HLS H.264 video files available for playback environments that don’t support HLS, regardless of whether you use Flash as a first responder or a fallback technology.

A Comprehensive Solution with AVC/H.264 and Adaptive Streaming

If you follow my recommendations, you’ll end up with a final scenario that includes the following tech setup:

1. H.264 Baseline and Main profile encoded video content in two or more bitrates. That’s a minimum of four H.264 video files.
2. A <div> container with an optional <video> tag for SEO purposes that is replaced with the appropriate Flash-based video player for adaptive streaming, or updated with an adequate source for the <video> tag that uses Apple HLS or progressive download.
3. A JavaScript library that detects if you’re using a browser that’s HLS compliant, and use an appropriate M3U8 manifest file for H.264 Baseline playback on smartphones or a M3U8 manifest file for H.264 Main playback on tablet or desktop computers. If Flash Player is installed (or available for the platform viewing the video), the JS library will write Flash Player embed code for a video player that supports adaptive streaming such Adobe’s free Strobe Media Playback SWF.
4. A Wowza Media Server instance that handles the transmuxing of your H.264 encoded content for Apple HLS and Adobe HTTP Dynamic Streaming (HDS), as well as the creation of M3U8 manifests for Apple HLS and F4M manifests for Adobe HDS.

To see past examples of this approach, you can review the HTML and JavaScript I’ve employed on the videoRx.com samples page.

The world of online video can certainly be intimidating, especially as non-Flash components enter your workflow and distribution. And there are real costs and trade-offs that flow directly from the decisions you and your clients make. I hope this post, and the one before it, help you decipher your options, and devise solutions that work for your needs.

I honestly thought that was a no-brainer, and while I saw support and re-tweets, I also got a little push-back on the notion.

As Twitter just doesn’t permit for thoughtful expression, I wanted to spend a few words on this blog to expand on my meaning. Because, while this is forward-looking speculation (and won’t be proven out, one way or the other, for quite some time), I feel that a discussion like this can help the industry establish realistic expectations of what will be possible in the new web.

So, the question is whether HTML5 will ever offer all of the features that Flash Player 11 offers today.

Can HTML5 Ever Offer the Flash 11 Feature-Set?

I do not believe that HTML5 will ever offer the same features as Flash 11. This is due primarily to three factors:

Maturity of Flash Player 11 Feature Set

Stated simply, Flash is a very mature technology. Across 14 years of enhancements and evolution, Flash today offers a tremendous set of functionality. Too vast to cover with any justice in a post such as this. Whether you are talking about video delivery, audio manipulation, peripheral integration, GPU control, data format support, or any other number of specific and mature features, HTML5 has a very, very tall order in terms of catching up to Flash’s current offering.

The HTML5 Specification

Stated simply, HTML5 evolution is slow. HTML5 has been in discussion since 2004, and is still, eight years later, not a complete specification. This is how open standards tend to proceed, given the number of stakeholders, and the number of stages at which those stakeholders can provide input and influence.

The speed (or lack thereof) with which features are added to the specification, combined with the number of features in Flash 11, means that even if all stakeholders today agreed on the desirability of these features (and that is a BIG if), it would take many years for the W3C to add all of the Flash 11 features to the HTML5 specification.

Now, it’s important to realize that much of what people consider to be HTML5, is actually not HTML5 — but instead, uses and implementations of JavaScript and CSS. In other words, HTML5 does not need to evolve or change, in order for more sophisticated and creative uses of JavaScript and CSS to enter the market.

Still, there is a limit to the nature of features that can be executed with JS and CSS, without additions to the HTML5 specification. And I do not believe that the W3C has demonstrated an ability to move at a sufficient pace to catch up.

The HTML5 Browser Implementations

HTML5 is completely dependent on browser implementations for functionality. The W3C defines HTML5, but each browser vendor writes their own HTML5 interpreter. Each one varies, with discrepancies (some small and some large). A quick scan of When Can I Use’s HTML5 compatibility table should give some indication of what this can mean.

Once a feature is added to HTML5, it still must be added to the browsers, and users must upgrade to those newer browser versions, in order for people to actually use the feature. (The process of introducing a new browser version to a sufficient number of users can take years.)

A feature is not a feature unless a user can use it. It’s one thing for HTML5 to support a feature; it’s entirely another for a user to have a browser in which that feature works.

Taken Together

Taking the above three factors into consideration, I believe it is clear why HTML5 has a very difficult challenge ahead, in terms of matching the feature set of Flash 11. Let’s take webcam support as an example. In this case, the W3C has already engaged in discussions on this type of support, but we are still years away from any practical implementations being in the hands of a wide number of consumers. First, the W3C (which has shown great reluctance to agree on even a standard video codec for HTML5) would have to agree on a specification for webcam support. Then, the HTML5 specification support for webcams would hopefully be picked up by the browser makers (not all of whom can yet support the ‘loop’ or ‘autoplay’ attributes of HTML5 video). This process would take years. And, that is just one (admittedly complex) of the many features that HTML5 would need to add, in order to match the feature set of Flash 11.

What This Means

I believe that, more than anything, this demonstrates some of the impact of the messy nature of these international standards, and identifies some of the tangible trade-offs that consumers will be making in this new world. With HTML5, unlike Flash, it just takes a lot of time and effort to get a new feature standardized, approved, implemented and distributed. And Flash, today, offers a lot of advanced and mature features that are not yet even in discussion in the HTML5 world.

In those areas where developers can really innovate with HTML5, they will. So we’ll see more mature frameworks, libraries, and workflow tools designed to improve HTML5 features and production options. However, in those areas which require W3C and browser-maker consent, HTML5 will continue to lag, for a very long-while.

I hope it is clear, but I feel compelled to add that this isn’t at all to say that HTML5 is inferior to Flash. The subject of this post is a very specific and limited one. Of course, in any real-world discussion, one can not ignore that HTML5 is supported on mobile devices (and it is important to remember that the value of a feature in large part stems from the number of screens to which it can be delivered). And, in my final disclaimer, arguing that HTML5 will never support the same feature set as Flash 11, is not the same as claiming that browsers will never support those features. Just that, if and when they do, it will be with something other than HTML5; HTML5 will not be the medium through which the in-browser equivalent of the Flash 11 feature set is achieved.

All that said, this is speculation. And I would love to see some different opinions in the comments. Again, the goal here is to try to spark a conversation in which the industry works to establish realistic expectations around what HTML5 has to offer.

Now, I’m sure there are plenty of you out there who would respond “there’s no problems, everything’s copacetic.” And, if that’s the case, congratulations! Of course, for most, that’s not actually the case.

In the process of trying to find some good articles for this site, I’m in touch with many of my colleagues in the industry, explaining to them the mission and purpose. And, as a result, I find myself having pretty open discussions about these sensitive matters with some very well informed and experienced people — people who have been building careers and making money with digital tools for interactive production (coders, animators, designers and video engineers) for well over a decade.

In a typical exchange I had just this week, one colleague replied with a series of questions that he would wish to ask the world, in light of the shifts in the industry (and these weren’t questions on small or minor points; these are fundamental questions of tools and workflows). Then he concluded that it’s “just a matter of if I ask it in public.”

Of course, this is entirely understandable.

We all trade on our skills and expertise. Admitting that we don’t know where things are going, or what the right solutions are for right now, can feel as though we are admitting that we are no longer experts, we are not worth the money we charge, and we are not worthy of admiration or respect from our peers.

While this is all understandable, it is not accurate.

Your uncertainty does not stem from your own short-comings. It is not reflective of your skills. It does not mean that you are behind the rest of the industry. It does not mean that you missed the conference where ‘The Answers’ were distributed to your peers.

Instead, your uncertainty is the result of the actions of, and battles between, large, multi-national firms (each of whom is acting in its own profit-seeking interests), as well as the actions and decisions of international standards bodies that reflect a mix of Ivory Tower abstraction from real world commercial contexts, and the specific, narrowly-defined interests of their corporate stakeholders (who, of course, fund the activities of these organizations).

The unfortunate outcome of these battles (at least in the near-term) is a massive degree of uncertainty — more uncertainty that I have ever seen in this industry (I’ve been building websites since 1993, when the public web was just 2 years old).

As many observers already know, one of the main sources of this confusion and uncertainty is HTML5. Now, HTML version 5, as the newest generation of the HTML specification, is a massive (and, in my opinion, long-overdue) upgrade to the standard language of the web.

But HTML5 is simply not what it is commonly represented as — what some very large, powerful and well-resourced firms are spending a lot of money to convince you of. To Apple, HTML5 is ready-for-primetime — as long as you only cater to users of iOS. To Adobe, HTML5 is ready-for-primetime — despite that they do not have one releasable version of any of the HTML5 tooling that they’ve been showing off. To W3C, HTML5 is ready-for-primetime (despite that it is not a complete or final spec) – as long as you don’t need to stream a video file, or play two audio files simultaneously in that experience. To the browser makers, HTML5 is ready-for-primetime, despite that each browser treats HTML5 more as a suggestion than a specification.

Heck, even the term ‘HTML5’ itself is frequently referenced so misleadingly, as to be inaccurate. In business contexts, it’s frequently synonymous with ‘no Flash’ or ‘mobile solution’. In tech circles, HTML5 is often used to mean ‘HTML5, JavaScript, CSS and the browser video renderers’ or simply, ‘in the browser’.

So we have an incompletely defined and supported technology, misleadingly labeled in common usage as short-hand for a set of related technologies — all without a mature set of tooling or professional-grade workflows.

But, none of the firms who are now so heavily invested in the HTML5 future will tell you this. Instead, their (very well-funded, if not particularly well-crafted) message is, simply “use HTML5”.

So, as I say, the first step is to admit that the entire industry has a problem. Once you do that, you will realize that almost all of the questions that you have are shared by a large number of your colleagues. The “experts” do not have magical answers that you do not.

Asking questions — even simple ones — is the entirely natural response to situations such as these. And I would actively encourage you to become more comfortable asking questions in public forums — even (nay, especially) if you are seen as an ‘expert’. Once the community feels comfortable asking these questions in the open, we can finally begin to have an honest discussion about what is actually transpiring in the industry. Otherwise, we’ll be ceding the discussion to the same firms who created this situation, leading to an unnecessarily extended period of uncertainty.

Don’t deny the uncertainty. Embrace it.

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:

1. Certain aspects of the HTML5 specification which are not implemented with 100% consistency across browsers and platforms.
2. 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.

It bothered me afterwards though so I checked my facts and found it again on Flurry’s blog – it’s true, Mobile Apps Put the Web in Their Rear-view Mirror. That’s a big shift, unexpected to many, but you guys are probably nodding to yourselves. You know this stuff right?

Stop.

What if I told you that people who right now are developing standard web apps will actually spend most of their next 10 years writing mobile apps? Too far? Before you judge, consider this:

According to Flurry consumers spend 72 minutes web browsing each day:

How many web sites are competing for that time? I asked Howmanythereare.net and turned up 346M. What about mobile apps competing for those 94 minutes? Well, 400,000 Android apps was considered big enough to make the news.

What the headline should be is that consumers are leaving web developers behind. And so those that can follow quickly have a HUGE opportunity. Forget a few hundred thousand, there are going to be tens of millions of mobile apps available to consumers in the next few years. App goldrush over? Difficult to be visible on mobile? I don’t think so – not even close. The graph is going to look a bit like this where now is 1997 (logarithmic scale):

The number of Internet websites each year since the Web’s founding.

Many will be more advanced than desktop equivalents taking advantage of location data, push notifications, camera and features currently under lock and key in Cupertino, Mountain View and Seattle. Some will be billion-dollar businesses in their own right, mobile first, and maybe mobile only.

Infrastructure will be built to support those apps and businesses behind them: middleware, development tools, libraries, open source projects, cloud services. More billion dollar companies.

Now this really is a cursory review of the numbers but seeing them makes me think we’re sleepwalking into a revolution. We think we know that mobile is big because of the fast adoption so far. But actually we’re underestimating 100x how big this change is and what it’ll mean for developers. I know I did, and mobile is my business. So did the pros I met a few week ago who already write mobile apps for a living. What do you think?

If you’re a web developer and this inspired you to go mobile: we hope you get started with us.

[Ed. Note: This post originally appeared on the Trigger Blog, and was reposted here by permission of the author.]

Installing cucumber.js

In order to get cucumber.js running on your computer there are two pre-requisites that must be installed first, node.js – a JavaScript based application server, and npm – a package manager for node.js that is used to manage JavaScript libraries and their dependencies. The node.js installer now includes npm with the installation so both will be installed at the same time. Download the installer from http://nodejs.org.

Once the installer is done open a Terminal window and type ‘node -v’ and hit Enter. The node.js version number should appear, 0.6.8 at the time of this writing.

Type ‘npm list’ and hit Enter to see a list of the packages that come with the node.js default installation.

If you see lots of red text that says UNMET DEPENDENCY or INVALID the packages need to be updated so all the JavaScript libraries have everything they need to run. Type ‘npm update’ and npm will update all the packages and download any missing libraries. This could take a couple of minutes as npm downloads all of the dependencies for the packages. Once the packages are done updating and you’re back at the CLI prompt type ‘npm list’ again and you should now see a list of packages all green and no more red like below.

Now we’re ready to install the cucumber.js package. Type ‘npm install cucumber’ and npm will download the package. Once that is done go back to Terminal and type ‘cucumber.js -v’ and you should see the version number.

If you see the cucumber.js version then you are ready to start writing some Gherkin features! If you get a node.js error try checking the packages needed by cucumber.js to make sure they were all installed. Type ‘npm list’ and make sure there are no lines that say UNMET DEPENDENCY below cucumber.js. If you do see some then type ‘npm update’ again to make sure it downloads the missing packages.

Project Setup

Below is a suggested project structure for your project. Of course this is an area that is highly based on personal preference and as such this is merely a suggestion to help get you started. The things to note in the structure are the node_modules folder to start. Node.js places all of the packages that you use for a project in the node_modules folder. The Makefile is a file to use with the make command to run your cucumber.js commands. I’ll touch on that some more in the Making a Cucumber section later. The rest is arbitrary but if you change the location or names you’ll need to also update the Makefile to make sure its targets are all correct. You can use the same node_modules folder to get started from the code for this example. I got it from the Express.js sample app on the cucumber-js GitHub site. With the set up in place now you’re ready to write your first Gherkin feature and run it to see it fail.

-project folder
	-client
	-node_modules
	-tests
		-client
			-unit (jasmine, etc, another blog post...)
		-features
			-step_definitions
				-anExampleStepDef.js
			-support
				-world.js
			-AnExample.feature
	-Makefile

Writing Your First Gherkin Feature

Gherkin is the language that Cucumber implementations understand, they’re the entry point to the automated testing code you write which is referred to as the step definitions. Each step definition is in its own JavaScript file and defines the steps of a scenario of a Gherkin feature. Each feature spec is also its own file, ending in a .feature extension. Here is an example of a simple feature.

file: AnExample.feature

Feature: This is an example feature
	In order to learn Cucumber
	As a developer
	I want to make this feature pass

	Scenario: wrote my first scenario
		Given a variable set to 1
		When I increment the variable by 2
		Then the variable should contain 3

There are several parts to the feature definition. All features start with the keyword “Feature:”, followed by a short description or feature name. The lines that follow immediately below are indented by a single tab and always go in the pattern: “In order to…”, “As a …”, “I want to…”. This pattern comes from some of the basic tenets of BDD, which there is a good description of on Wikipedia (http://en.wikipedia.org/wiki/Behavior_Driven_Development). Immediately following the description of the feature are N number of Scenario definitions. In the example above there is only one but multiple scenarios can be expressed for a single feature. Scenarios always start with the keyword “Scenario:”, followed by a short description of what that scenario for that particular feature is about to be described in the following steps. The steps that follow are the most vital part of the feature definition as they directly tie in to the cucumber step definitions you’ll be writing to verify this feature. We will see how exactly those tie together in the next section Writing Your First Step Definition. These steps always start with the keywords “Given”, “When”, and “Then”. Additionally you can use the keyword “And” after any of the keywords. You can read a lot more about Gherkin and its syntax and examples by checking out the book Specification by Example (http://manning.com/adzic/). This example is a very basic one just to show how it all works and comes together. With this feature file in place we can now write the step definition to start testing this feature with cucumber.js.

Writing Your First Step Definition

The step definition code should go in its own JavaScript file per feature. In the code example below the JavaScript file is named after the feature file name with a js extension.

file: anExampleStepDef.js

var aTest = function () {
	this.World = require("../support/world.js").World;

	this.givenNumber = 0;

	this.Given(/^a variable set to (\d+)$/, function(number, next) {
		this.givenNumber = parseInt(number);
		next();
	});

	this.When(/^I increment the variable by (\d+)$/, function (number, next) {
		this.givenNumber = this.givenNumber + parseInt(number);
		next();
	});

	this.Then(/^the variable should contain (\d+)$/, function (number, next) {
		if (this.givenNumber != number)
			throw(new Error("This test didn't pass, givenNumber is " + this.givenNumber + " expected 0"));
		next();
	});
};

module.exports = aTest;

Lets break down this step definition. The function assigned to the aTest variable is the code that will verify the Gherkin feature. The first line of the function is the set up for the step definition, similar to the set up of a FlexUnit or any other xUnit test case. A World variable is defined that accepts a callback that is passed in by cucumber.js. In the World function is where you would set up beforeEach(), afterEach() and all the set up that needs to happen for this “world”. The last line tells cucumber.js its ready to go and passes in the reference to “this”.

file: world.js

var World = function (callback) {
	// set up code goes here

	// last line to tell cucumber.js the World is ready.
	callback(this);
};

exports.World = World;

The next three function calls are where the step definition directly ties in to the feature file. Each of the steps of the scenario that the step definition js file is testing is written with the function calls to ‘this.Given()’, ‘this.When()’ and ‘this.Then()’. The first argument of each function is a regular expression that will match the plain english in its matching step in the feature file. The phrase “Given a variable set to 1″ then translates to “this.Given(/^a variable set to (\d+)$/, function (number, next) {…})”. The callback function that is in the second argument will always have at least a single argument sent in which is the callback function to call at the end of the step, in this example named ‘next’. If there are regular expression tokens, such as ‘(\d+)’ to catch a digit those are sent in to the callback function and can be named arbitrarily and sent to the function call in the order that they appear. That is why the function call has two arguments: ‘function (number, next) {…}’.

With these files in place now we can move on to making a cucumber. But first we’ll have to talk about the Makefile.

The Makefile

Because cucumber.js is a command line interface program it is cumbersome to use frequently when the parameters list is long or they have to change often. The make utility solves the problem and a Makefile are the instructions to make the process of running and making a cucumber more efficient by having predetermined build targets. Below is an example of a basic Makefile to run cucumber.js on the feature in this example.

file: Makefile

cucumber:
		@NODE_ENV=test ./node_modules/.bin/cucumber.js tests/features \
				-r tests/features/step_definitions

.PHONY: cucumber

You can also add additional targets so you can for example run node.js server tests with mocha or run your client unit tests written in Jasmine from the same Makefile. I will expand on those in a later post or you can also check out the Express.js application example mentioned in the cucumber-js GitHub repo README file. The paths in the Makefile file are relative to the location of the Makefile which is the same directory you run the make command from.

Finally, Making a Cucumber

With the Makefile in place we can finally make a cucumber. From the directory with the Makefile, which is usually the project root, open a Terminal. Type ‘make cucumber’ and you should see some output from cucumber.js telling you how many features were tested and how many scenarios were tested, including how many passed and failed.

If you scroll up the output will give you the details about the step that failed.

That’s it! If your code has a bug or error in it it’ll look like above. If it is passing cucumber.js will look like the screenshot below. There’s a bit of set up upfront, but I believe its worth the price of admission and once its set up all you have to type again is “make cucumber” to test your code… and its fast! If you want more information about Cucumber I would recommend the new e-book/paperback that’s available in beta form due out in February 2012 and the Specification by Example book which are both on the http://cukes.info page.

Happy cuking!

Given the current state of affairs, I wanted to assemble some notes on the state of HTML5 video, as a helpful introduction to those of you who need to start conceiving, planning and building solutions that necessarily involve aspects of HTML5 video. I’ve had to consider all of these factors and more as I’ve built my own video encoding and hosting service at videoRx.com over the last two years.

Introduction to the Problems (or Pain)

Many web developers already believe that HTML5′s <video> support can do away with plugin-supported video delivered by Adobe Flash Player or other runtimes. My three biggest concerns with using HTML5 <video> for “real world” video deployment revolve around:

1. Current cross-browser implementations and adoption rates
2. Cross-platform mobile optimizations
3. Codec support

Cross-Browser Implementations

I’ll start with current desktop browser usage statistics. Microsoft Windows is still the primary desktop operating system in use today. Microsoft has decided to only release Internet Explorer 9 (IE9) and higher on Windows Vista, Windows 7, and future versions of the operating system, despite the fact that 46.52% of the desktop market is still using Windows XP, which can only run IE8 or lower. The HTML5 <video> tag is only supported in IE9 or higher. And by most counts, Windows XP has several years left as a viable operating system. As Table 1 illustrates, nearly 30% of desktop browser usage in North America from December 2011 to January 2012 could not interpret the HTML5 <video> tag. By default, then, if you want to reach a significant portion of desktop viewers with browser-based online content, you need to have a solution that more than likely will require the Flash Player. If you don’t believe me, just look at YouTube, which still uses a Flash-based player as the default video player wherever Flash is supported—even when an HTML5 <video> ready browser is detected.

* Hardware acceleration available

** Not available in early versions of Android browser.

Mobile Optimization

While the desktop browser market may not be HTML5 video ready, I frequently hear that one segment of the market is HTML5-ready and has been for sometime now: the smartphone and tablet markets. By and large, it’s true—nearly every Android and iOS device supports HTML5 <video> playback as shown in Table 1. But, HTML5 <video> options here ironically are not good enough for the mobile platforms that so desperately need enhanced attributes. Mobile devices require special video care: specific video formats (H.264 Baseline for widest support), and video formats that are hardware accelerated to avoid unnecessary battery usage. Cross-browser HTML5 <video> support is limited to progressive downloads, which aren’t exactly mobile friendly. Yet most video delivered on the web (and to mobile!) still use progressive download over HTTP as the primary delivery method.

Apple is the only browser vendor to introduce a specification, called Apple HTTP Live Streaming (or HLS), that’s available in all iOS and now some Android devices. But, this specification is not adopted by other major vendors including Microsoft, Mozilla Firefox, and Opera. Google is the only other vendor to implement HLS with the native Android browser, universally in 3.0 versions and with limited support (varying by device manufacturer and carrier) in 2.3 and higher versions. Another streaming specification that’s been introduced is MPEG-Dash, which has many promising mobile and bandwidth friendly features but is not yet adopted by browser vendors. However, a streaming protocol is just one aspect of being mobile (and desktop) friendly. The more important aspect of an HTTP streaming protocol is adaptive streaming, which enables the browser to determine the appropriate video quality (or bitrate) to play. Adaptive streaming requires the content producer to create two or more versions of the video per device target, each version having a specific bitrate that will play well for a given Internet connection speed. Apple requires any iOS application accessing video over cellular networks to use HLS adaptive streaming for any video playback within the application that is over 10 minutes in duration or over 5 MB of data in a five minute period (read more).

Codec Support

Lastly, there’s the video (and audio) codec issues with current HTML5 browsers. IE9, Safari Mac 3.1 and nearly all of the native smartphone browsers support the industry standard AVC/H.264 video codec, as well as the AAC audio codec. However, Firefox 4+, Opera 10.6+, and Chrome 10.1+ support the WebM video codec, a newly open-sourced video codec, and the open source Vorbis audio codec. (Firefox 3.5 and Opera 10.5 browsers also support an older open source video codec, Theora, which is not optimized for high quality video at lower bitrates as modern video codecs are.)

If you want to adhere to current HTML5 video standard(s) and not rely on plug-in based playback, then, you’ll need multiple versions of a video, each encoded with the codecs necessary across all HTML5 browsers. You’ll also need multiples of those multiples, if you want optimal mobile playback with adaptive streaming. Developers focused on “standards only” would have you believe it’s best to encode your video in four or five different versions. This approach adds considerable time and expense to any video distribution workflow for a content producer that has more than just a couple of videos to manage on their site.

Standards versus Business Goals

In many respects, a strict standards approach for online video delivery is not financially responsible for business. With the current state of HTML5 video, there are too many codecs to support, and limited options for delivery protocols. WebM is far from an industry standard, and we’re years away from seeing WebM hardware acceleration across devices and desktop that we currently enjoy with AVC/H.264. While HTML5 is “video ready” for smartphones, WebM as a viable codec option is not. Apple iOS doesn’t support WebM, and for reasons similar to Apple’s resistance to the Flash runtime, I don’t see Apple adopting WebM anytime soon. Simply put, if company X is producing the hottest and best-selling devices to the same folks you want to see your video content, then company X’s implementation is going to dictate how you publish that content. Right now and for the foreseeable future, company X, of course, is Apple. Apple and Microsoft have both rallied behind H.264 as the preferred video codec for video playback, from device to desktop to TV.

If you view the current online video landscape from a business perspective, you likely want to achieve one or more of the following:

• Maximum viewership of your video. You want your video to play across mobile and desktop browsers with a consistent experience as much as possible.
• SEO (Search Engine Optimization) friendliness. You want your video content recognized by as many search engines as possible.
• Efficient encoding workflow. Video, unlike other HTML visual assets, requires substantially more time, effort, and storage. You want a manageable workflow that can reuse assets across delivery mechanisms.
• Wide range of delivery options, from live streaming to protected content. Business stakeholders will increasingly want to monetize their online video content, and HTML5 video doesn’t provide methodologies to limit access to the video source files. Apple HLS and MPEG Dash are the only options to stream and encrypt content, but only the former option is available now and only on iOS and limited Android devices.

The following factors should not, and likely will not, influence the business of online video:

• Standards compliance. In the best of all possible worlds, we’d see a simple <video> tag that works consistently with the same format and delivery options everywhere. We won’t have that option anytime soon. First and foremost, sites that have video content want their target audience(s) to be able to watch the video with as little fuss on both sides of the equation: reduced encoding and deployment effort for publishers, and reduced playback headaches for viewers.
• Open source reliance. While WebM and Vorbis are open source codecs, the industry standard for high quality video production is H.264. It’s consistently used for video from professional video capture to Blu-ray discs to online video. Just as the video disc market couldn’t support HD DVD and Blu-ray simultaneously (or Beta and VHS), there’s likely only going to be one winner in the online video codec battle. While H.264/AAC codecs can incur royalty charges for subscription and pay-per-view use cases, the vast majority of online content is under the royalty-free clause of MPEG-LA‘s licensing terms. And if you’re lucky enough to be one of the few content creators that successfully monetizes their video online, your royalty obligations for H.264 usage to MPEG-LA won’t prohibit you from being successful.

A business goal-oriented approach deals with the problem of viewership and what’s widely available for your playback requirements. Facts support that Flash Player is very viable on desktop and on browsers that don’t play nice with the predominant (read: Apple) mandates of H.264.

H.264, HTML5, and Flash: A Solution to All Online Video Problems

So, here we are. We have HTML5 standards telling us to create three versions of our video (H.264, WebM and Theora) or more if you’re using adaptive streaming and/or H.264 profiles and bitrates specific to smartphone, tablet, and desktop deployment. We have a significant portion of browsers in use today that don’t implement the <video> tag at all. We have a perception that the Flash Player is on its way out, and that HTML5 can do most if not all of the things that Flash can do. The solution to the problem is relatively simple: base your solution around H.264 and forget about supporting WebM and Theora. If you consider yourself a professional web solutions expert and want to offer your clients (and, more importantly, your target audience) the best mobile and desktop experience, you’ll also encode and deploy for adaptive streaming on iOS, Android (where supported), and the Flash Player.

What an unfortunate mess of confounding options that we solution providers must present to decision makers. In my next post, I’ll outline the simplest and most effective solution to reduce the pain of distributing your video online.

With Adobe announcing the abandonment of all mobile Flash Player efforts, developers who formerly specialized in this platform are branching out a bit more and taking up both new and old technologies in exploration of other opportunities. This article is not meant to be comprehensive rundown in any way. I’m simply working through a number of thoughts in regard to certain avenues which I’ve considered approaching.

One of the excellent problems Flash has, is that it is good for such a variety of things. With such a tool (especially if you know it well enough) at your disposal, this makes it difficult to look beyond to other technologies. With that said, most Flash developers do already have a grasp on a variety of other tech simply because Flash is so great at working alongside other platforms. This is good for developers who are expanding their investigations into these technologies; considering what may be, at the least, a passive familiarity with a number of other avenues.

As an author and video trainer heavily invested in the Flash Platform, I fortunately don’t feel the bite as badly as some others in this industry. Since the announcements of November the 9th 2011, I’ve actually signed a number of new contracts focused upon Flash content (though I’m under contract for non-Flash subjects as well, now). With that said, I’m also a consultant and full time software engineer… so I do need to stay ahead of where things are moving so that I can advise others and make intelligent choices for any active projects.

HTML/CSS/JS

This seems to be where most developers are moving. It makes sense in a way since this is often where these developers working in Flash actually began their careers. This is certainly true for myself. In fact, I was championing standards based web design and table-less layouts before it was popular to do so… back in Mozilla Phoenix times… so I am no stranger to this stuff.

While I never completely left the HTML/CSS side of things- JavaScript is something I’ve avoided simply because there was historically very little that could be done with it. Differences across browsers compounded this problem to the point where I just didn’t bother – if it could be avoided. This isn’t the case now, of course; as JavaScript engines have become much more capable, differences across browsers have diminished, and a number of very useful frameworks are beginning to emerge.
http://www.html5rocks.com/

jQuery/jQuery Mobile

For some years now, I’ve used jQuery to take some of the pain points away from any JavaScript work I’ve had to undertake. jQuery provides what I have thought of a nice cushion to the difficulties one would normally experience in using this language – though, in truth… it provides a whole lot more that I’ve yet to take advantage of. With the proliferation of mobile devices, jQuery Mobile has emerged as a complimentary set of libraries when dealing with mobile websites, or even HTML-based applications.
http://jquerymobile.com/

PhoneGap

PhoneGap (Apache Cordova) provides developers with the ability to write a mobile app using web standards and then bundle everything up for distribution to a wide number of mobile platforms… a much greater number than AIR. This is a pretty big draw, and the PhoneGap Build service allows cloud-based bundling of an app to any of the supported platforms. Very convenient all around.

I’ve had terrible luck with all of my PhoneGap experiments so far. I keep telling myself this is because I’m unfamiliar with the technology. Not sure if this is the case or not. Everything just “looks/feels” so much crappier in HTML than it does in Flash. I attempted to port a mobile app I created as an experiment back when mobile Flex became possible for Android and just gave up. I’m hoping that it’s just a reflection of my inexperience in this area since I know people have had great success with it.
http://phonegap.com/

Dart

Dart is a new language being offered by Google. They pretty much want this to take the place of JavaScript due to that languages shortcomings. I haven’t done anything substantial in Dart yet aside from downloading the editor and running through their tutorials and samples. It does seem much closer to ActionScript 3 than JavaScript does… and the editor is based on Eclipse so even that aspect is familiar if coming from Flash Builder or FDT. I’m hoping Dart catches on and that it does become an alternative to JavaScript. In the meanwhile though… it will compile to JavaScript… so that’s something.
http://www.dartlang.org/

HaXe

If I remember correctly, HaXe emerged from the ScreenWeaver project… someone please correct me if I’m wrong. I used ScreenWeaver quite a bit (back before Adobe AIR was a possibility) for specialized projection software systems. It basically created enhanced projectors for Flash content similar to what applications such as MDM Zinc are now doing. HaXe has been on my radar for years – though I’ve never gotten around to actually using it.

The HaXe platform is very interesting because it allows us to develop in one common language… and output to whatever supported platform we wish. Target platforms include; JavaScript, Flash, Neko, PHP, C++, with C# and Java in the works. There is this gnawing in my brain telling me that, in the near future, this is going to be the preferred model of programming. It’s almost like “run once deploy anywhere” – except where that phrase was used to target a single runtime, this newer model targets multiple runtimes, VMs, and environments by adopting them and their standards. Very different way of doing things, but something I feel we are going to see more and more.
http://haxe.org/

Adobe Edge

Adobe Edge is a new motion and interactivity tool from Adobe which can output rich, interactive compositions using standard web technologies like HTML5, CSS, and JavaScript – basically Flash Professional 4 for HTML output. I don’t say this to put down Edge – this is actually a really nice thing. One absolutely great thing about Flash when it was focused on animation and basic activity, was how fun it was to push things, experiment, and see what the technology could do. I get the same feeling from Edge. Is it basic nostalgia or something more substantial? To see HTML do the things only Flash could do even a few years ago – and to do it with such ease and control… is a wonderful thing.

I’m doing a lot with Edge right now. It’s a major focus of mine for 2012.
http://labs.adobe.com/technologies/edge/

“Alternative” ActionScript/Flex IDEs

I like Flash Builder a lot and am quite comfortable in it. I now have a number of reservations around this IDE though (thanks, Adobe!)… I mean, what if they decide they just don’t want to make dev tools at all anymore? On that note; I’m actually floored that they’re trashing design view from Flash Builder. Having always found design view to be very useful in layng out components and configuring item renderers. This affects my workflow and makes Flash Builder less useful to me. For a “creative” and design-focused company, I cannot imagine the internal justification for this.

Anyhow… I’ve installed both FDT5 (free version) and FlashDevelop on my laptop. Even if one of these does not become my primary dev environment for Flash-based work, at least I may be comfortable enough in something else for when Adobe finally does pull a coup de grâce on Flash Builder. as I mentioned above – I’m not leaving Flash and need a dependable environment to work in. Not so sure if Flash Builder will be that environment in the future.
http://fdt.powerflasher.com/ / http://www.flashdevelop.org/

Moving Forward

I fully expected by now to have done some real work in these alternate technologies… but have been far too busy with Flash, Flex, and AIR work to really get involved and commit to anything new. Like all things, it just takes time I suppose.

I remain a huge champion of the Flash Platform and will continue as such in 2012 while looking into other things. I believe one of the best ways of getting some footing with any new tech is to survey what others in the community are up to. transitioning.to is a great example of this sort of effort, but simply speaking to others that are going through these pains as well will go a long way to understanding what might be the smart choices to make. I expect to see a lot of conference talks in the coming year focused on these very topics.

Aside from changes in programming, I’m hoping to swing back into the design side of things a bit more as well. I’ve been in strict development mode for far too long and recent events are a good excuse to strengthen my skills in other areas. Back in graduate school, I began my studies strictly as a designer thinking Photoshop and Illustrator would be the applications that defined my career. It wasn’t until I was introduced to Lingo, ActionScript, and ASP (of all things…) that I shifted to a career in software development. Moving back into design a bit would be good for me.

I believe it is also important to step out of the sphere of creating software for balance and release. In the coming months, I plan to resume recording through my aural project “An Early Morning Letter, Displaced” with a new collection of work. This will be difficult with the rigorous authoring schedule I have committed to for the first few months of the year, but it’s a necessary creative outlet and one that I am very excited about. I encourage anyone so involved in programming, engineering, or anything similar to do something raw and free on the side. I often joke about leaving this field of work to become a gardener or a baker… maybe I’m not joking so much about that any longer.

Happy travels.