Thursday, February 4, 2010

HTML v Flash

Religious war brewing?

Although Flash certainly is the feature-rich favorite for immediate deployment of complex video/graphical interface content to the web – and due in part to Microsoft's current non-support of HTML5 is the only alternative for truly broad video playback capability – this is the present and not the future.

Microsoft's Explorer team now participates in efforts to improve developing HTML5 standards (since it can't rely on Silverlight to beat Flash, and would prefer HTML5 to another vendor stealing developers to a competing platform). Presumably Microsoft's IE9 improvements will include an effort to rejoin the lead echelon of modern browser experience in offering standards that, not incidentally, will reduce developers' dependence on competing proprietary development tools like Adobe's Creative Suite.

Meanwhile, HTML5 promises to allow vector graphics, video rendering, and all kinds of other things Flash used to be required to do – all without plug-ins.

Adobe arguably can get this developer business, too ... but my own experience with Adobe products poisons me on the idea. Years ago, I hand-coded a page full of resources for people doing research in a specialized professional field and included numerous places one could get information – different government agencies, universities, etc. – and with these provided everything one wanted from links to the online resources available there to links to maps for getting to the physical locations for examining paper-only resources, links to hours and campus maps for finding buildings once one was present, and institutional logos so users could quickly spot the institution they wanted if they already knew what they were hunting for. All this was provided in a table that made it easy to tell what type of content you wold get from a clicked link, based on the horizontal location of the link. Some "web designer" at the institution for which I created this little gem was in the habit of examining contents of the various folders on the server she ran by double-clicking the files – an act that, on her computer, opened the page in an Adobe HTML editor. Then, she would fool with it. Not much – she'd try to move a column in the table, for example, then see it didn't help and put it back – and sometimes not at all; yet, she was in the habit of always saving every document before closing it.

My page – which had been carefully tested to be usable on Microsoft's Internet Explorer, the MacOS 9 browser iCab, Opera, the Firefox predecessor Netscape Navigator, and every other browser I could get my hands on – was continuously broken. Every time she saved it with her Adobe HTML-editing tool, something happened to the page based on her preferences in her editor (e.g., the color changed unaccountably) or based on some little tweak Adobe didn't bother to code to work across browsers, or simply because Adobe's editor wasn't designed to work everywhere, just on browsers Adobe engineers used. No matter how often I replaced the page with an undestroyed version, she managed to screw it up with her Adobe tool for no reason at all. Moreover, she was utterly oblivious to the fact she broke it: "I didn't change a thing," she would say. Yet as soon as I replaced it with my version, it would work everyplace. This circumstance just never lasted.

Eventually I tired of the Sisyphean task of pushing the page back into cross-browser utility, and when I left the institution nobody bothered to maintain it. Why should they? Any browser they used to open it invariably revealed a horribly broken mess of which users could make no sense. Why waste time with tripe like that? It disappeared shortly after the institution "lost" the web designer who broke it; her replacement (justifiably) discarded it as unmaintained, broken garbage.

So, what's the future of Adobe? Who cares!

The future of HTML5 looks solid, as all the major browser manufacturers are working together to make an unambiguous standard that will allow write-once development for any compatible browser. The range of issues to be addressed by HTML5 and other incoming standards seem fairly broad: video playback, 2D animation (WhatWG's work on Canvas), scalable vector graphics, mathematical markup, user-side database storage, 3D (e.g. WebGL), and a host of things that Flash might have been used to accomplish in the past but can be handled more elegantly, and in a way better matched to the rest of a given system's user interface, by careful implementation of standards-based content interpreters on the platform of a user's choice.

Adobe promises to update Flash, to make it a moving target. Of course, if it moves too fast its developers may not be able to follow.

Let's hear it for the future, and open standards.

No comments: