It was in this context that Adobe Flash (formerly Macromedia Flash, and before that FutureSplash) first came to prominence. The Flash plugin worked identically in all web browsers, offering a way free from the browser wars and liberating developers from the tit-for-tat power struggle between Netscape and Microsoft. Build once, view anywhere. Bliss! Not only that, Flash (along with its sibling Shockwave) brought rich interactive animations to the web, a temptation that was too great for web designers to ignore.

Like many other web designers I took to Flash like a duck to water, and by 2001 was employed as a full-time Flash developer. It was an exciting time to be part of the Flash community. Improvements were being made to the Flash platform at a pace that put native browser technologies to shame, and in the wake of the browser wars much of the web’s most innovative work was created with Flash. If someone referred to a site as “slick” or “cutting-edge”, you could bet they were talking about a Flash site. Sure, the Flash authoring tool and browser plugin were proprietary technologies, but that seemed a small price to pay to be at the bleeding edge of web design.

The fall from grace

Of course nothing lasts forever, and by the time I struck out on my own as a freelancer in 2004 Flash was starting to lose its shine. The web standards movement was gaining momentum in a big way, and JavaScript powered web apps were grabbing the limelight from Flash applications. Fast forward to the present day and Flash’s utility has been further eroded by the arrival of HTML5, CSS3, and other New Exciting Web Technologies.

It is not only web developers who have fallen out of love with Flash, lured away by newer, shinier technologies. Over time the general public have come to view Flash as a bandwidth hogging “skip intro” technology, and a platform for invasive banner advertisements. I too have become increasingly disillusioned with the way that Flash is used as tool for creating slick “here today, gone tomorrow” marketing micro-sites, most of which are overblown advertisements and lack any real substance. I became a web designer because I want to build websites and applications that enrich people’s lives, not shallow marketing gimmicks.

My frustration with Flash isn’t only philosophical, it stems from practical considerations too. Functionality that most web developers would consider intrinsic to the user experience is missing from Flash, or difficult to implement without jumping through hoops. When I develop Flash applications a large percentage of my time is spent trying to achieve functionality which I would take for granted if I were developing an HTML/CSS website:

• The absence of page refreshes means that bookmarking and deep linking are achievable in Flash only with the help of convoluted workarounds.
• Searchability is compromised by the fact that Flash content is not exposed to search engine spiders.
• The browser scrollbar doesn’t respond to changes in Flash content the way that it would to changes in HTML content. Often Flash developers resort to creating their own scrolling functionality from scratch, which is why Flash sites often feature tiny textfields controlled by custom built scrollbars.
• CSS support is only partially implemented, and styles can only be applied to text fields.
• Interface conventions on which users rely are missing in Flash, for example the Ctrl+C key command won’t copy selected text from a Flash movie and instead the user has to evoke Flash’s contextual menu using a mouse right-click. And if you’ve ever tried to save an image from a Flash website to your hard drive then you will have experienced a similar moment of frustration.
• Perhaps worst of all, Flash is excluded from the wealth of plug-n-play APIs that allow websites to interact with third party web applications (Google Maps, Facebook, YouTube and so forth). In some cases workarounds may exist that allow third party functionality to be integrated into Flash applications, but once again Flash developers are required to jump through technical hoops to achieve functionality that is available to everyone else with virtually no effort.

Apple v Flash

I can’t talk about Flash’s decline in popularity without mentioning Apple’s role in its vilification. It wasn’t until Apple chose to omit the Flash Player from its iOS devices that anti-Flash sentiment truly crossed over into the mainstream. Steve Jobs’ threw fuel on the flames in April 2010 when he criticised Flash for being an insecure, buggy, closed platform.

I personally think Apple’s decision to exclude Flash from iOS devices was motivated as much by economic incentives as it was by performance and security considerations – the ecosystem of free online Flash games poses a direct challenge to Apple’s app store – but that is beside the point. By banning the Flash Player from their devices Apple have pushed the Flash debate into the public consciousness, and made Flash an untenable proposition for many website owners.

The impact on my own business has been tangible: during the past year almost every project brief I have received has stipulated iOS compatibility as a mandatory requirement. Most of my clients own an iPhone or iPad, and understandably find it unacceptable if their website doesn’t function in mobile Safari.

So long and thanks for all the Flash

All these factors make the case for developing a site in Flash extremely difficult to justify. Sure, Flash still has a place – creating web based games, for example – but for the vast majority of websites native browser technologies simply make more sense.

So at the start of the year I decided it was time to stop offering Flash development services to my clients. My decision to ditch Flash should come as little surprise given the negative publicity that has surrounded the Flash platform the past few years, and frankly I should have pulled the plug sooner. Nevertheless, Flash has been a part of my toolbox for over a decade, and until a few years ago as many as half the sites I developed were built in Flash. So for me it is kind of a big deal.

The sentimentalist in me is sad to bid farewell to Flash, but for the most part I am relieved. For far too long I have been sitting on the fence, advocating open web standards on the one hand, while continuing to build Flash sites for many of my clients. With Flash out of the picture I can devote myself to what I’m really passionate about: building websites using open standards and native browser technologies.

In AS3 this can be achieved using the bufferTime property, which I set to 20 seconds:

var nc:NetConnection = new NetConnection();
nc.connect(null);
 
var ns:NetStream = new NetStream(this.introVideoConnection);
ns.bufferTime = 20;
 
var video:Video = new Video(320, 240);
this.addChild(video);
video.attachNetStream(ns);
 
ns.play("myvideo.flv");

But when I tested the results on a remote server I discovered that Flash was waiting the entire 20 second duration before starting the video stream, despite the fact that the flv had fully downloaded in just a few seconds.

After scratching my head for a few moments I realised that the problem had to be the high bufferTime. Normally playback would start as soon as the entire video was loaded to memory, regardless of the bufferTime value, but that doesn’t appear to be the case when the bufferTime exceeds the video duration.

Setting the bufferTime to less than the video duration worked as expected: Video playback began as soon as the buffer was full.

Demo

Click and drag your mouse on the image below to erase it. Press the reset button to start over.

Download

Download FLA (includes code comments explaining how everything works)

Credits

My effect is based on the masking techniques shared by surferboy in an Ultrashock forum discussion and a Flash & Math tutorial explaining how to use Flash’s drawing API to draw using the mouse.

The gorgeous photographs used in this demo are by wabberjocky and ex.libris and are available under a Creative Commons license.

Version targeting in Flash

Version targeting in Flash works in much the same way as it will in Internet Explorer: each Flash movie contains embedded information telling the Flash Player which version of Flash it was created for, and the Flash Player itself contains multiple rendering engines to handle legacy content.

This approach to backwards compatibility has been a feature of the Flash Player since its earliest incarnations. The latest version, Flash Player 9, supports content produced for FLV (Flash video), SWF9, SWF8, SWF7, SWF6, SWF5, SWF4, SWF3, SWF2, and FutureSplash. That means that Flash content created in 1995 still renders perfectly in 2008. Flash developers can have a great deal of confidence that an application they create today will continue to work in the future without any need to revisit it*.

Why have Adobe worked so hard to ensure the Flash Player is compatible with legacy content? I think the answer lies in the commercial nature of Flash. Because Adobe relies for its livelihood on the continued patronage of website developers, they need to keep that customer base happy. Flash would never have gained traction if developers were forced to rework their legacy websites every time a new Flash Player version is released – I can’t imagine anyone paying $700 for software that generates code that breaks every eighteen months!

Does backwards compatibility hamper progress?

Let us consider my concerns about version targeting, and see if they have been borne out in Flash: Has backwards compatibility hampered progress in the Flash industry? Has it slowed adoption of the Flash Player? Has it stalled advances in Flash technology? I think the answer to these questions is “no”.

One metric we can use to gauge the rate at which advances in Flash are taking place is to look at Flash Player adoption rates. A fast adoption rate by end users is a sign that users are encountering Flash content targeting the latest Flash version, and are upgrading their player in response. Even before the introduction of an automatic update feature, adoption rates for the Flash Player were very high. From the time a new Player was released, it would achieve 55%-65% market penetration within 6 months. This is a good indication that Flash developers are quick to take advantage of new features in Flash.

Another measure of technical progress is the rate at which new features are added to the Flash Player (as opposed to the Flash authoring tool, where some changes will be merely cosmetic). During the past four releases there have been three complete overhauls of the Flash programming language, the introduction of powerful video functionality, bitmap effects (motion blur, dropshadows, etc) and filters, to name just a few new features. Because version targeting ensures there is no pressing need for Flash developers to upgrade, Adobe needs to continually improve Flash’s feature set to give its customers a compelling reason to purchase an upgrade license. Rather than stymieing progress, version targeting actually encourages technical advances in Flash.

A personal perspective

I worked as a full-time Flash developer for four years, and Flash development still accounts for about half the work I do. Until this week I hadn’t given much thought to the impact of version targeting in Flash, but on reflection I see that it has compelling benefits for end-users, seasoned developers, and Flash novices alike.

Flash has a very healthy development community keen to push the boundaries of their medium, and even though version targeting enables many developers to work at a lower level, I don’t see any evidence that this skill gap impedes advances in the field. I myself still publish content targeting Flash Player 8, and am familiarizing myself with the new ActionScript 3 programming language in the meantime. I certainly don’t feel that I am holding anyone back by learning at my own pace!

I also consider that version targeting goes a long way towards easing the Flash developer’s workload. If I build a site targeting Flash Player 8, I know without testing that it works in Flash Player 9 too, and vice versa. I know too that I will never need to “fix” that site to comply with a future Flash Player release. This forward compatibility is something that I take for granted when I develop a Flash site, and the idea of ‘fixing’ my legacy projects every couple of years seems totally absurd. Yet for some reason this “break and fix” cycle is considered perfectly normal for HTML websites.

What’s good for the goose

Of course, comparing Flash Player with a web browser is not like comparing apples with apples: Flash and Internet Explorer have very different business models; Flash has no serious competition whereas Internet Explorer is part of a busy browser ecosystem; Adobe is free to introduce new features to Flash as it sees fit whereas Microsoft is beholden to various working groups; the upgrade cycle of Flash is driven by web developers rather than software vendors. What works for Flash may not necessarily work for Internet Explorer.

Yet I believe there are enough similarities to draw a comparison. Flash shows us that under the right conditions version targeting can actually be beneficial for everyone involved in the development, delivery, and consumption of content for the web.

Footnotes

* There is only once exception I can think of: new ‘sandbox security’ restrictions introduced in Flash Player 7 caused some older Flash applications to break.

If you work with Flash at all, by now you will have heard of Papervision 3D, the open source project that has turned the Flash world on its head by introducing a 3rd dimension. I had a quick play with Papervision 3D a few months ago and found it surprising easy to pick up. It is now in public beta so I decided to dust off my old project and rewrite it in Actionscript 3.

3D image gallery demo

Inspired by Antti Kupila’s stunning 3D interface for last.fm, I created a simple gallery of album covers using Papervision 3D. For the reflections of the album covers I have used Pixelfumes’ Reflection class.

View demo

View my 3D image gallery

Download source

If you’re curious to see how I put this demo together, take a look at my Flash source files.

Using Papervision 3D

The biggest challenge for me was porting my code to Actionscript 3, as it was the first time I had written AS3 code. But as far as Papervision 3D itself, it really is a piece of cake to get your head around. The documentation that comes with Papervision 3D is a bit hard to follow, but if you download the zipped version of Papervision 3D from Google Code it contains a bunch of great examples which help to introduce the basic concepts.

The cool thing about Papervision is how it can be adapted to all kinds of 3D applications. My main interest is in the possibilities for creating 3D application interfaces, but people have also created 3D games, models and animations. Expect to see a lot more 3D Flash in the next couple of years!

If you want to see the flicker bug in action, visit the homepage of the Adobe website using Safari 2, and open one of the dropdowns from the main menu. You will notice a brief flicker as you move your mouse over the links overlapping the Flash movie.

Another long standing quirk that I notice has been fixed in Safari 3 is the “dropdown stays open” bug. In worst case scenarios this bug would lead to dropdown menus which refuse close without refreshing the page.

As someone who regularly uses both Flash and Suckerfish dropdown menus, these two bugs have been nagging me for quite some time, and I’m pleased that Apple has finally kicked them to the curb. The only bad news is that Safari 3 is only available to users of OS X 10.4.9 or higher, so it will be a while before we can kiss Safari 2 goodbye once and for all.

Silverlight is Microsoft’s new browser plugin for Rich Internet Applications, and since the unveiling of the latest alpha version it has been dubbed a “Flash killer” by many commentators. Silverlight is a Flash competitor to be sure, but a Flash killer? I think that may be overstating the case.

Amongst all the hype about the death of Flash I have also found a handful of articles that cast doubt on Silverlight’s chances of success, but on the whole I think they miss the mark somewhat. Two criticisms leveled against Silverlight are its lack of availability on the Linux platform, and potential indifference from end users, neither of which I see as the major challenge to Silverlight adoption.

Let’s consider the issue of Linux support. For a long time Flash support for Linux was very poor, yet that did little to hinder the adoption of Flash on other platforms. Even if Microsoft themselves don’t deem it worthwhile porting the Silverlight plugin to Linux, there are already independent developers working at the task, and it’s just a matter of time until the OS is catered for.

As for the issue of end user adoption, to my mind what is actually more crucial is Silverlight’s acceptance by developers and designers. It is not a question of users seeing no need to switch away from Flash, but rather website developers feeling compelled to make the switch to Silverlight. If developers take Silverlight to heart, get excited about the platform and promote it in the web community, its adoption rate could be very fast. If that happens, end users will have no choice but to follow. After being welcomed to three or four websites with the greeting “you need to download the Silverlight plugin to view this site”, only the most stubborn user would still resist. On the other hand, if web designers and developers fail to become excited about the potential of Silverlight it will gain only a negligible market share, and end users will remain blithely unaware of its existence.

In my opinion this is the real challenge Silverlight faces, capturing the hearts of web designers and developers, especially those who currently work with Flash.

Microsoft certainly have their work cut out for them. If Silverlight is going to “kill” Flash, it stands to reason that the current field of Flash developers will need to abandon Flash and defect to Silverlight. Flash has a 10 year history and a robust developer community who will be unlikely to jump ship unless Silverlight proves to be a vastly superior product.

The other scenario in which Silverlight might “kill” Flash is if the flood of Silverlight applications is so enormous that Flash’s current market share seems insignificant by comparison. For this to happen, Silverlight will need to appeal to developers who are intrigued by RIAs, but don’t see Flash as a compelling proposition. However I expect Microsoft will face stiff opposition on this front too. After all, whichever way you slice it Silverlight still relies on a proprietary browser plugin, which is precisely what turns so many web designers off Flash to begin with. Silverlight does offer a “language neutral” scripting interface, as opposed to Flash’s reliance on Actionscript, which ought to ease the transition for newbies, but whether this is sufficient to eclipse its single vendor affiliation remains to be seen.

Regardless of whether Silverlight proves to be a runaway success, the next few years are bound to be a very interesting time for RIAs!

In the past it would have taken a lot of repetitive Photoshop work to apply these sort of visual effects to images, and god forbid you ever redesigned the site and had to remove the effects from every single image. swfIR answers that problem by applying effects in automated, non-destructive fashion.

swfIR is the brainchild of Dan Mall from Happy Cog, and is designed with progressive enhancement and standards compliance in mind. Each ‘swfIRized’ image must be wrapped in a span tag and have an additional css class applied to it, but otherwise the original markup remains untouched. JavaScript is then used to replace the HTML image with a Flash movie into which the original image is loaded, and visual effects are applied.

The technique is not without its drawbacks however. One thing I don’t like about it is that the image replacement does not occur until the window.onload event is triggered, which means that the unstyled image must load into the page before it is replaced. I wonder if the replacement should be triggered using a JavaScript event that is fired when the DOM has loaded, not the entire page. Apparently there are small Camino/Mac rendering bugs too. I understand that the swfIR developers are working on these issues, so it will be interesting to see what they come up with.

I’ve always thought it a shame that Flash hasn’t played a bigger part in the emergence of Web 2.0. AJAX is the technology that’s grabbed the headlines, yet Flash is purpose built to create cross-platform Rich Internet Applications (RIA’s). Sure, some of the big Web 2.0 player such as YouTube and Google use Flash Player to deliver their videos, and Yahoo Maps is a Flash app, but yourminis is far and away the most comprehensive Flash RIA I’ve seen. I was quite amazed to see how many public APIs Flash can successfully hook into: YouTube, ebay, Amazon, Yahoo Maps, Flickr, Digg, delicious, Gmail, iTunes – even Dilbert!

yourminis has a slick ‘aero’ style interface, which can be customized with the user’s own ‘desktop wallpaper’. This is bound to make it appealing to a young user base who might be turned off by the corporate look of NetVibes. In fact it is actually possible to embed yourminis widgets in myspace profiles – or on any other webpage for that matter.

The one thing that’s noticeably absent at this stage is a yourminis API. Despite the swag of official widgets already on offer, this is going to slow down its evolution. Supposedly the API will be released in the very near future, and it will be fascinating to see what Flash developers do with it.

Lately I’ve been underwhelmed with Flash sites, but yourminis is a fantastic example of Flash the way it ought to be done. I hope that we see more sites like it in the future.