Unflash

At Antarctica, for version 3.0 of Visual Net, we added a Flash-based user interface to our traditional HTML flavor. For 4.0, which ships sometime before end-of-year, we’ll be backing it out and sticking to dynamic HTML. It’s the right thing to do, but the choice wasn’t a slam-dunk. Herewith a look at the pros and cons.

Why Flash? · We had some pretty compelling reasons for going to Flash:

• The whole point of Visual Net, as its name suggests, is provide a compelling visual interface to information spaces. Most of the people out there on the Web doing bleeding-edge things in terms of glamorous visuals are doing so with recourse to Flash.

• Another big deal with Visual Net is that you can click on any part of the map and it does smart drill-down to the next map. With Flash, you can use the animation capabilities to give those transitions a smooth video-morph feel.

• Also, our software is always used to hold other people’s data; the objects on the map can be financing deals or parts in inventory or books in a library. Since in Flash, everything’s a movie, you can brand like crazy to make the customer’s objects look the way they’d like.

• Recent versions of Flash include an XML parser. Visual Net can generate XML, so we could parse that and generate the graphics on the desktop. This is architecturally much more scaleable than the Web’s typical server-does-everything model.

We hired a local designer to pitch in on the first Flash-ified version of the product. The results were stunning; areas on the map were shaded oval jelly-beans, it all moved when you clicked on it, descriptive text flickered in and out of existence in a fixed location on the screen. It made a terrific demo.

But we found that real customers doing real installations ended up going for the HTML version every time.

Problems · The excellence of modern DHTML motivated us as much as the problems with Flash, but there were indeed problems; the two that really got in our face were usability and performance.

The usability problem wasn’t anything wrong with Flash intrinsically, it’s just that we couldn’t get it to feel enough like being in a browser. It was really, really hard to get the Back button working properly, and even things like letting people type in a query and launch it by pressing Enter (as apposed to clicking on a button) were a challenge.

Maybe we’re not world-class Flash wizards, but we tried pretty hard and just couldn’t get that smooth clean browser integration. People are just not willing to tolerate the Back button’s not working properly in a browser-based application.

The performance problem was more surprising, because in theory we should have won. You generate XML on your server, you parse it on the client, you generate vector graphics on the client, you’re using less bandwidth and you’re splitting the CPU load between your server and the immensely-fast boxes on most modern desktops. This is what I’d call nice clean architecture.

In fact, it was dog-slow unless you had a really top-end GHz++++ box, and on a complex map, it was slow even then. Flash apps are hard to optimize, and we spent some time on it, but it was embarrassing that the dumb server-does-it-all HTML version was consistently dramatically faster.

The conclusion isn’t “Flash sucks,” I’m seeing more and more good useful Flash content that isn’t skip-this-intro. But for us right now, the alternative was more compelling.

DHTML is Good · A few months back, for good reasons, we had finally decided to give up on supporting the pre-V5 browsers. In parallel, I (partly because of ongoing) had started to become aware how much you could do with DHTML, and how sophisticated you could get, and how portable it could be. I became convinced that it could give us a high proportion of that Flash eye-candy.

(Just to be clear: When I say “Dynamic HTML” I mean sophisticated modern HTML combined with a lot of Javascript and (especially) CSS; you can do an amazing variety of things very cleanly just by twiddling class= attribute values.)

And in fact, our latest trial deployments (not quite based on the released code-base) look remarkably good, if I say so myself. The only things that I really miss from the Flash versions are the animations and the nice partial-transparency tricks (which you could do if IE supported PNG properly).

I’ll admit to having hated Javascript based on the “View Source” effect. For some reason, most JS code out there in production is hideously ugly and egregiously unreadable, I had concluded that that’s just the way it was. If you keep your JS in a separate file so it only downloads when changed, there’s no reason to compactify it, and it ends up substantially more readable than some other scripting languages I could name. There’s some weirdness all right, but as trade-offs go it’s not a bad one.

Now, if the browsers supported SVG...

---