Version targeting lessons from Flash
In my last post I outlined some of the problems that might arise from the proposed version targeting changes to Internet Explorer 8. My major concern was that by removing the motivation for web authors to update legacy sites, version targeting might hamper the adoption of modern web development techniques. During the week I have given some more thought to this issue, and it occurred to me that in Adobe Flash we have a fantastic real-world test case from which we might learn if version targeting is a viable strategy for a web browser.
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.
* 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.