Flash – A call for sanity

or, I can’t believe I still have to discuss this shit…

Herein, are some notes, a slidedeck and some source code relating to a talk I gave for Academy Class this week, regarding Flash’s place in the web and beyond.  I was driven to put the talk together due to the sheer amount of misinformation, misrepresentation and outright idiocy that seems to still surround the use of Flash as a rich media technology.  The fact that we are still having to have this conversation depresses me hugely and I find the constant placing of ideologies (like open – not a synonym for ‘better’ btw) ahead of a sensible assessment of the appropriate technology to deliver a project successfully really tiring.  The lecture was well attended and the post-talk debate stimulating and balanced so I do believe that there is still a life for Flash.  Key points to take away:

1. Flash, and any other plugin runtime, exists to augment the browser’s native capabilities uniformly across available platforms.  If the browser can handle it, then there is no need to use flash.

2. HTML5 development is NOT stable across all the platforms that a typical commercial build needs to target.  As developers, we expend a huge amount of resource in hacking legacy support into our web applications.  The most stable code is always optimised for it’s runtime – if the runtime (i.e. browser) is fragmented, then it’s very hard to do this.  Rich media builds are often complex and Flash should be regarded as a viable technology for rich media heavy lifting.

3. Not everything has to be built for mobile and not everything should.  Mobile is an inherently different use case to desktop browsing and ‘compatibility’ is not a virtue in of itself.  Know when to support it, when to degrade down to it, when to branch the experience completely for mobile, and when to ignore it.  The lack of mobile support for flash is a red herring.  It’s not built for it and that’s ok.  Desktop experiences are still the most consumed digital content by some margin.  Mobile web browsing does not, and probably should not in many cases, need to be a rich experience.  We have apps for that!

4. As the browser’s capabilities have evolved, so have the flash platform’s.  It is vital that the developer community place pressure on ‘bad’ legacy flash code, particularly in rich media advertising which is still largely built to old specifications, and to educate and advocate for the platform’s capabilities and best practise.

I hope that this will be the last pro-flash post I have to make.  I hope that we can appreciate the multi-faceted toolbox of frameworks and runtimes that we use to create our fantastic medium objectively.  I hope that I don’t have to do this all again next year…

Slideshare deck
PDF with notes coming soon
Source code for the air mobile demonstration  (I’ll add some more comments etc soon)

A case for Flash advocacy

I write, slightly incredulous that we’re still having to cover this topic in 2012, in response to an article that my learned colleague Jason Langdon published last week about the future of the flash platform and the apparent lack of advocacy by it’s parent company, Adobe. Whilst I don’t agree with everything he says – Flash is far from a de facto standard for rich media delivery and there are many areas of rich interaction on the web where it has rightfully been superseded by the browser runtime itself (photo galleries, straightforward video and audio playback etc) – he nonetheless raises some important points that the Flash developer community and Adobe need to address if the technology is to have a future.

The problem, however, is that it’s very hard to have a rational discussion about the platform without the conversation immediately denigrating into blinkered ideology and zealotry….and that’s amongst the developer community – speak to clients and the situation for Flash is even bleaker. The staggering amount of misinformation about the capabilities of the technology, it’s reach, it’s consistency of execution across an ever-more fragmented browser landscape and the efficiencies (or lack thereof) of developing in it make. We recently attended a talk on HTML5 held at the Google Campus in Old Street where the key example of how HTML5 had replaced Flash for rich site development, didn’t work on the iPad, on mobile browsers or in many older desktop browsers. It is disingenuous to say the least to make such a claim, particularly given that the ‘death of flash’ was largely predicated on it not being implemented in the browser on iOS.

Still, there is cause for concern about this misinformation being the prevailing attitude and I certainly agree that Adobe has done little to stem the tide. Here’s some points to consider:

1. Developer tooling

Flash Builder was a weak product and most flash devs that I know use third party tools like Flashdevelop and FDT. The lack of a decent debugging tool looks like it’s finally been addressed in Monocle, but I have grave concerns around the game-dev-centric nature of the mooted improvements to the platform. If Adobe would spend less time on failed designer-centric workflow tools like Catalyst, and more time on proper application development tools, frameworks and libraries, it would be a much more attractive platform. In fact, if I were Adobe, I would be aggressively targeting budding iOS/Android developers with an accessible IDE, framework and component library (a la jQuery Mobile) for mobile application development, alongside tools for debugging and packaging apps simply.

2. Performance

It cannot be denied that the Flash Player runtime is not optimal compared to many other runtimes. The roadmap appears to be leaning toward a re-written VM and overhaul of Actionscript which would go some way to helping restore developer’s confidence in targeting it. A re-brand may also be worth considering at this stage.

3. Honesty

There isn’t actually any reason why Flash should be in trouble. The runtime is still widely supported (95% of global clients), simple to deploy to and is more powerful than ever. It’s current predicament seems entirely down to Adobe’s failure to handle the PR of the platform and to be seen to be reactive rather than standing firm by it. In acknowledging the platform’s weaknesses and playing to it’s strengths instead of thinking that you can just ignore it’s critics or whitewash over what are often fair comments, you can give the platform it’s space to succeed. Literally, take it out of the ‘race’ for front end dominance and let it find it’s space as the best method of cross-platform rich application development.

On this point, Lee Brimelow said it best at FOTB last year: Flash’s role on the web was *always* to enhance the capabilities of the browser. If the browser can now handle it natively, then flash doesn’t need to be there…but there are always other things that developers want to be able to do that even the latest browser builds can’t manage consistently (DRM, geocoding, microphone/camera access to name just three). It’s shouldn’t be HTML5 vs Flash, but HTML5 PLUS Flash.

4. Rich banner advertising

We recently received specifications for rich banner adverts in flash from Doubleclick which comprised code snippets (the clicktag) and a guide to implementation written in AS1. Banner creation makes up a considerable amount of bread and butter work for many agencies and freelancers, and it also often delivered by design creatives without such an extensive knowledge of good practice or the issues above. There are well known conflicts between the different versions of the AVM in flash player which provide legacy support for the older flash specifications. If your browser or application is crashing due to flash, the very likely culprit is a flash advert rather than a well built application. This is something that both the rich media networks, the major commissioners for advertising creative, creative agencies and Adobe themselves must address urgently. There is still a good use case for Flash in advertising but it will only harm the platform if not implemented to a contemporary standard.

Ultimately, flash professionals love the platform because it is fast, intuitive, powerful and very flexible and I concur with my colleague that the way it is being treated in the marketplace leaves much to be desired. It is our responsibility as a community to continue to support and advocate for it (and that includes maintaining our opensource projects and shouting from the rooftops about our successes) and to continue to place pressure on Adobe to treat the platform well and not sideline it into oblivion due to a perceived pressure from the market.

n.b. I’m hoping to give a flash-centric lecture in ‘response’ to the HTML5 lecture we saw at creative class later this year. Follow me on Twitter to keep in touch!


Partisan technology reporting

Rory Pyatt linked me up to an article on Techcrunch today about HTML5 vs native application development. It annoyed me, a lot, for a number of reasons. Here are a few:

#1 and this is the biggy – HTML5 is not an application development framework and it is not “in competition” with native platform technologies. If you really need help in deciding which technology framework to build your application on, then you haven’t thought enough about that application’s architecture, ux or strategy. Hence my vehement hatred of the “let’s do in HTML5” thing that technologists often hear from buzzword-wielding product owners without fully understanding what that means or why it might or might not be appropriate. Without wishing to add to the reams of debate on the HTML5 branding issue, HTML5 is still, essentially, a MARKUP specification. That is all. Even if you add the “and related technologies” tagline, it’s still mostly covering the UI alone, and not an application framework.

It amazes me the imbalance of coverage on HTML5’s usefulness as an improved semantic markup spec versus canvas and video (and related techs like CSS3, webkit transitions and javascript frameworks, particularly the latter which have been around long before HTML5)

#2 That article is, like most tech news lately, deeply partisan and not doing anyone any favours. Apple have become the Fox News of technology and Steve Jobs is their Bill O’Reilly (ok, that’s a bit inflammatory but I hope you see my point). This shouldn’t be a battle between advocates of native application development and advocates of the front end stack. What then happens is that the methodology is placed before the actual needs of the customer, the application or the platform. This will be a common theme for many working within complex organisations.

#3. The political manoeuvring of the big tech companies is largely PR and market positioning, and not a crib sheet to the future. Whilst we should always listen to what the industry and it’s analysts are saying, our primary responsibility at the creative coalface, is to the message we are communicating and to the end-user. We will build in whichever technology delivers the best experience. Besides, a developer will have a short career if they are not pragmatic about their toolkits, particularly given how fast things can change. Seb Lee-Desisle’s recent blogposts about flash vs HTML5 should be required reading on this point.

I think the most telling line from that article is Hewitt’s tweet: “I want desperately to be a web developer again, but if I have to wait until 2020 for browsers to do what Cocoa can do in 2010, I won’t wait.” If you wish to be a web developer again, then I’d suggest building experiences within the web toolkit. Cocoa is not designed for the web. It’s designed for it’s own platform. That’s a little bit like me saying I’d like to build Half Life 2 in VRML. If you are building native platform experiences (like the awesome, paradigm shifting music applications that we’re starting to see on the iPad), then native platform it is, along with the considerable resources it requires to do so. If you are building a glorified RSS reader, then HTML5 is your friend…and there are many wrappers available to push to the appstore if that is part of your business strategy.

tl;dr: you don’t use a hammer to fix a pair of glasses – the world is a developer’s oyster at the moment. Use all the technologies – use them wisely.

HTML5 – the cat is amongst the pigeons

This post was originally written for the internal Sky Creative Technology blog.

Last night, Google put up a blogpost on it’s Chromium blog which may have wide-reaching implications for the way in which we publish video. In this post they outline their plan to drop support within the HTML5 <video> tag for the much-utilised H.264 codec in the Chrome browser, in favour of the open-source WebM and Theora codecs. This effectively means that future versions of Chrome will not be able to playback h.264 encoded video, except in 3rd party plugins (such as Flash).

For a major browser vendor, with it’s product in the ascendent, to suddenly drop support of the most widely used video codec on the web, however might not be as crazy a move as it first appears. Google are most certainly playing a long game over standards, and it’s a ballsy move for sure…but h.264 is not, and never has been free to adopt, and businesses, particularly those which might make commercial propositions out of their video content, are exposed to a liability by using it. Google clearly believes that a long-term adoption of an open-source standard is a better bet, than just going with what’s being used. This is similar to the replacement of GIF by PNG a few years ago. We might not have agreed at the time, but the better standard won out. They are also not alone – Firefox also does not support h.264.

This is, obviously, a gift for Adobe. Whilst the browser vendors beat their drum over open-source, licensing and standards, Flash will, for now, be the only sensible method of deploying cross-browser (excluding iOS), hardware accelerated (very important in the adoption of HD video) video. Plus, they will be supporting WebM in the near future. The much-trumped future dominance of the HTML5 video tag may have been a little premature. I suspect that our workflow for now will be h.264 video into flash, with fallback to HTML5 for iOS devices…and not a lot else, until the desktop browser standards war settles down.

WebM is a promising technology, but I don’t think it’s there yet. There’s no hardware acceleration for it at present which will be problematic for HD publishers, and a quick test in our dev team shows serious processing overhead on the client PC when playing back a youtube webM video. My biggest concern is that no production workflow for broadcast currently has WebM on their radar. I’m confident that few people outside the open-standards geek corps will have even heard of it. No commonly used production tools support it, and, of course, there is the small matter of our legacy video that is currently deployed. Fortunately, we haven’t done a massive amount of HTML5 video deployment in our team…apart from device specific work (such as the iPad version of skycreative.tv) which won’t be affected by this change.

Of course, our users and clients don’t really care about standards and technology platforms. When they click on a video, they expect it to play on the device of their choosing. In the short term, this is almost certainly going to create a lot more work for us as we struggle to support multiple platforms and multiple standards – the expectation of the end user is that they receive the content they have requested. We will have to work out how we are going to deliver that.

Whichever way you look at it…begun this standards war has.