why is worldKit Flash?

why is worldKit Flash?

It’s a question I get asked, with reason. It’s proprietary, only somewhat open, and it’s future is unclear. It’s widely abused in obnoxious design heavy websites. And the refinement of DHTML and Ajax techniques, notably demonstrated in Google Maps, seems to make Flash unnecessary.

Yet, right now, it is the by far the best option for worldKit. The Flash Player guarantees a consistent environment across the widest spectrum of Browsers and OS. Try viewing Google Maps in Opera, and you’ll see that they’d have to go through even more hair pulling to cover whatever tweaky flavor of dhtml it supports. A worldKit map works identically practically everywhere (there have been some problems with font support on Ubuntu linux. and Macromedia hasn’t released a player for 64 bit linux).

Even if DHTML was supported consistently, Flash wins on image manipulation and vector graphics. The Flash Player is highly optimised for image manipulation, which allows for fluid zooming in worldKit, rather than step wise zoom in gmaps. Gmaps can draw vectors for driving directions, but with an incredible server side hack. Lines are draw by a server process, and overlayed in the browser, cleverly exploited for nonsense with Google Draw.

If browsers ever catch up, say with native SVG, then that’s great. worldKit is entirely OOP Actionscript, so rewriting in Javascript will be no big deal. And there are open source flash compilers and players, if these got attention perhaps many objections would dissipate.

The Flash and AJAX seemed to get good discussion at OReilly’s AJAX summit. The conclusion, basically the right tool for the right job, that these two are complimentary, and they can easily coexist, is right on. In the worldKit geocoder, it’s natural to use the browser for form based interaction, and AJAX for queries on the geocoder REST services. Interaction between the browser and Flash Player is easily accomplished by Javascript.

flickr notably announced and released mods to use AJAX rather than Flash when viewing photos. Flash was clearly overkill, and in fact less useful (couldn’t right click to save the image). Still, I don’t expect them to recode their Slideshow Flash app .. there’s no reason to change it, and would probably be a hassle to do so.

Tangentally, it was a Greasemonkey user script which generated that change, lickr, by Neil Kandalgaonkar, the same developer of the Google Draw hack. Neil writes some interesting points on the greasemonkey developer list. He’s of course chuffed they took his work on board. But..

I’ve been talking with Eric Costello of Flickr. Sometimes it’s hard to
tell which one of us works there. Arguably, Greasemonkey has made the
distinction irrelevant, except for how we’re compensated.

I wasn’t getting paid anyway, but if this is subsumed into Flickr, I
won’t get credit.

With the proliferation of APIs, and the boundless opportunities of Greasemonkey, independent developers are adding value to commercial services and not seeing anything in return. No surprises there. But if a service can produce a business model that rewards value added by its developer-users, they might have a leg up on other open systems.