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!


The Digitonal Ambient Box


The Digitonal Ambient Box

Over the last couple of weeks I have been revisiting my old MAAP player project, bringing it up to speed to take advantage of some new technologies that flash player 11 offers.  Mostly, this was an exercise in keeping up with my talented team and exploring some possibilities for the Flash platform for some upcoming project work, but I also do like to set myself a challenge every once in a while to stop my code chops from atrophying too much in my largely management and creative role here.  Since the MAAP project seems to have fizzled out, I thought I would purpose it to my own musical project, Digitonal.  I’ve been doing quite a lot of ambient stuff recently and thought it would be fun to write something specifically for it.

The primary technologies I’ve used in this rebuild are listed below and it’s been interesting working with these new frameworks which I think offer much to the flash platform.

Starling: A fantastic framework for gpu-accelerated 2D animation, which makes use of the new Stage3D access (formerly known as Molehill).  The smooth animation of the orbs that I’m getting here, and the effortless particle system are both based in Starling and, whilst it has some quirks (largely due to it’s insistence on mirroring the normal Flash display stack) the results you get from it are stellar.  This is pretty much always hitting 60fps without blinking and I know that my previous implementation of this idea had a performance way, way below that.

NAPE: A very promising new physics engine.  I’ve always struggled with the more or less standard Box2D framework and so this is a refreshingly useable alternative which has been a joy to work with.  Strongly recommended for your physics modelling needs.

Tonfall: Andre Michelle’s fantastic as3 audio framework which I’m using here for the sample-perfect looping, pitch control (couldn’t even have conceived of coding something like that myself) and support for WAV samples (which, whilst it obviously places a huge burden on filesize for online delivery, helps raise this into the realm of something approaching what I’d envisage as an artist).

The whole thing took about 2 days to code and I’ll make the source code available on this post as soon as I have some time to refactor so you can point and laugh.  I’m also keeping a very close eye on AIR’s forthcoming Starling support for iOS and I’m hoping to do an iPad port of the application at some point in the near future.

>> Launch the Digitonal Ambient Box (N.B. – the site uses high quality audio samples about 11Mb in total – fast connection and a little patience required!)


So long, and thanks for all the flash

fotb 2011

fotb 2011

I’ve attended every one of the 6 Flash on the Beach conferences. It has been a yearly fix of inspiration, connection to an industry which I’m often isolated from in the corporate environment and straight up good fun. This reached it’s zenith in 2009 where I came out of the Brighton Dome hypnotised and dizzy with the possibilities of the medium. I’ve often equated it to the first time I encountered the web in 1994 which fueled a passion for the creative opportunities for technology that I carry with me now. That was an incredibly important event for me and it also marked the point at which Flash on the Beach had ceased to become purely a technically-focussed exchange of techniques and practices in Flash development, and instead became a creative propagator – a shot in the arm for a jaded developer.

Fast forward to 2011 and it’s very obvious that, a: we’ve come a long way baby and b: that FLASH on the beach is a definite misnomer. For instance, Flex is notable for it’s absence (I don’t think there’s a single session on it in fact) and the talk of RIA’s and the Flash Platform which were in vogue until the Jobsian witch hunt kicked in is not to be found. Flash is talked about only in terms of enhancing web content, and gaming, which is clearly the technology’s stronghold. HTML5, design principles, type, motion graphics, filmmaking, Processing, ofx all merit focus and one gets the impression that showrunner John Davey has been steering towards this point all along. It’s of no surprise to me then when he announces at the end of the conference that this will be the last event under that title.

I did make extensive live notes which I publish here in full (strictly only for the very curious and more for my own record than as a public-facing document), but here are some highlights, links and salient points.
Continue reading

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.