I've been pondering this for a while (well, for almost ten years, to be quite honest).

This month, aggregated stats for all our users (inc. b2b) show IE6 dropped below 7%. Google having dropped (or being on the road to drop) support for YouTube and a number of other applications, a fraction of these 7% users will probably feel compelled to get their web right, so, I guess the time is right.

Hence ZoomViewer 1.5 (due April 1st :-)) will branch and will be the last version officially tested and supporting IE6. Once ZV 1.6 becomes gold (sometimes in May), e-commerce clients will still have the opportunity to pick the latest-IE flavor, but only security maintenance will go on that branch, and new versions of tools/templates/markup will possibly not work with it.

I thought I would mention that I'm not going to remove IE6 specific code in the trunk - just that I won't test it anymore, or fix bugs specifically for it. Which means on the contrary that it might continue to work.

This kind of decision is not as easy as web 2.0 fashionistas and pissed web-developers would like to present it. Dropping ~5% of your user base out of the blue is not exactly something that you do for mondane reasons and expect to please a sales-manager. Not to mention these 5%, unfortunately, are highly representative of the sad fact that a lot of corporations are still forcing employees to use IE6 (official reason: intranet applications have to be redeveloped - un-official reason: corporate sysadmins are lazy asses more often than not). And it's never a pleasant experience having to explain to a client that the application you developed "is not working for them and that they can't test it, but that it will work everywhere else".

Either way, that's it: that ~5% is not worth it, compared with the amount of manpower, sweat, blood, excruciating pain, and sacrificial white rabbits required to maintain IE6 support.

Notes

For these who wonder why a Flash application would have to "support" browsers: ZoomViewer (or "ZedVee") is itself a full-fledged web-browser, able to render markup in a language we created (the "Zoomable Markup Language"), and that exposes a javascript API, pretty much like an iframe (eg: contentWindow and contentDocument). Exposing that javascript API on the object node (and associated contentDocument) with true and uniform DOM Level 2 compliance on it (including real W3C events support) do requires a shit-load of dabbling, per User-Agent specific. Pretty much, I like to sum-up what we do as "Practically extending the web by allowing new XML idioms to be rendered and interacted with in a standard manner, allowing for the exploration of new web navigation paradigms" - but that will be the object of a forthcoming post.

Meanwhile, here are two short examples illustrating what I mean (hit the "S" key to see ZML markup):

(note that both these examples make use of our css-transitions implementation)