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.
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.
4 thoughts on “Version targeting lessons from Flash”
Comments are closed.
Interesting comparison! It is nice to see that this model can work, though Flash is quite a different entity.
I think the comparison falls apart around the fact that, as you say, Flash has no real competitors (though if any Microsoft employees responsible for Silverlight read this, they may feel offended) and can update whenever they want, to their own specs not those provided by the W3C.
The lack of competitors means that when you create a Flash website, you only need it to work in Flash, not in Silverlight or any other potential competitor which may or may not implement it better. Where in Flash development you have one target, web development has a few, all of which are moving targets. Progressive Enhancement is never going to occur in Flash because you are targeted to Flash Player n only. Where we build sites that work in IE6, they can be spectacular in Firefox.
Of course, your point about uptake of the latest Flash player is encouraging, noting the apathy surrounding upgrades to IE7 and the ever present IE6 still trying to nudge the majority share of browsers. With full backwards compatibility big corporations with legacy systems will be more willing to upgrade as they can guarantee their systems aren’t going to break. This can only help those who want to use the latest and greatest features.
The only worry is that Flash development has it’s barriers to entry, and those to creating a web site are that much lower. This is why Flash developers will always push to use the latest version, as they already invested in it. This is the point in which the majority of the web may freeze in the year 2007, as it will be easy, it already is easy, for those who aren’t full time developers, or even interested to the level as those in this debate are, to continue to produce sites that render correctly in IE7.
Nice points, Jonathan, and an interesting perspective. Thanks.
@Phil – Thank you for the considered feedback!
You make a good point about Flash’s high barriers to entry ensuring it attracts a customer base who are committed to maximising their investment by using modern development techniques.
It occurs to me also that developers getting started in Flash (even hobbyists) are likely to start out using modern techniques simply because they are using a modern version of the authoring tool.
By comparison, a novice HTML developer might not be using an authoring tool at all, and their only guiding principal might be to ensure a site works in the most popular web browser (Internet Explorer), which as we know will soon default to an outmoded rendering engine.
It will be interesting to see how the
X-US-Compatibleinstruction is implemented in future versions WYSIWYG software such as Dreamweaver. Will Dreamweaver omit the new meta tag altogether, target the most recent version of IE, or opt for “edge” rendering? If they choose to target the version of IE that is current at the time of each Dreamweaver release, it will be comparable to the Flash authoring tool targeting the current Flash player, ensuring that over time steady progress occurs even amongst web authors who have never heard of version targeting.The direction taken by manufacturers of authoring software could play a very significant role in determining how version targeting is implemented by non-standards aware web authors.
PS: No, I don’t count Silverlight as a serious competitor to Flash! I had my doubts when Silverlight was launched, and it seems to have gone nowhere fast since then…
I’ve been pulling my hair out trying to research flash version market penetration and finally found a good, third-party resource. Here is a link:
http://www.statowl.com/flash.php
For Jonathan, they also have a Silverlight support page:
http://www.statowl.com/silverlight.php
@Richard – Stat Owl is a very cool resource, thanks for sharing!