By Paul Anderson
One of the initial surprises at the FlashForward 2002 conference was that fully half of the attendees identified themselves as developers rather than designers. A majority of the audience members claimed to "utilize object-oriented principles in daily tasks." In fact, at first, it wasn't clear that the agenda, focused on Flash MX, had much to offer designers. There were more than a few disparaging references to banner ads and dancing bananas.
FlashForward 2002 was held April 2-3 in San Francisco. The event focus was the newly released Macromedia Flash MX tool. Click here for a Flash MX review.
It turns out that Macromedia didn't wholly invent the notion of Flash as an application platform. Flash developers have historically exceeded the medium's intended uses, and ever since version 5 added ECMA scripting and XML transactions, it has pushed the player's limits. Developers’ problems shifted from spinning and fading to handling asynchronous server transactions. A recurring theme at the conference was the fact that Macromedia has been forced to prematurely support undocumented APIs that developers discovered and zealously adopted.
Morphing into engineers
A more intentional, and pervasive, theme of the conference was the need for proper software development practices. Mark Belanger from Fluid characterized Flash development as great power requiring great responsibility—specifically, for large and complex projects. Several presenters discovered or reinvented the Model-View-Controller pattern. One presentation was almost entirely dedicated to binding event handlers to a custom listener object.
ActionScript, the Flash scripting language, uses an interpretation of the ECMA 262 prototype model. Flash MX adds class registration as well as superclass and inheritance keywords requested by Flash authors. While scripts can still be assigned to animation objects, the trend is now to create Flash components (essentially controls or widgets) as instances of abstract prototypes to keep the logic nonspecific. An anonymous, object constructor syntax makes it easier to pass objects as parameters.
The discussions of object-oriented design otherwise focused on modeling scalable, reusable code. A Flash movie can be separated into logic and presentation components, which, in practice, serve as libraries. Keeping scripts in importable files allows collaborative development and version control. Componentized design was also demonstrated as a way to extend portions of Web applications to handheld devices with little or no added development. (Flash currently runs on PowerPC and the Nokia 9200 series.)
Optimization was another top issue. Loading and caching data only as needed saves bandwidth, short variable names save memory, and limiting the number of active processes at any moment eases CPU demand. A Flash MX form can relieve the server of validation, error handling, and even filtering cached results. New embedding variables let a single Flash movie process a unique data source wherever it's displayed, meaning less production for the author and fewer user downloads.
Fortunately, this interest in software design principles has spurred an interest in interface design as well, from tab ordering to accessibility. The player is fully compliant with Windows interfaces for screen readers, and the IDE coaches the developer in using them.
Roll out the power tools
Beyond design principles, Flash developers wasted no time trying out the new player's uses for applications. The compelling arguments for Flash are its cross-platform reliability, low bandwidth requirements, and fast development time compared to HTML- or Java-based interfaces. There is no comparably widespread medium for interactive video. Flash does its server transactions in XML, so for most applications, some sort of middleware is required, although the next release of ColdFusion will offer a more direct "gateway" to Flash clients. Session Objects, an improved object-based cookie, facilitates state management.
Flash MX also introduces script-based drawing, and the mere eight methods have dramatically shifted Flash authoring from scripted progressions to logical execution. Even the art designers were showing off deluxe algorithmic creations based on only a few kilobytes of code. Removing the need for bitmaps considerably reduces the file size. One compelling demo was a complete drawing application, with save and export, weighing in at a mere 30K. Other practical uses included interactive graphs and charts requiring minimal code.
It's up to the developer to write functions for geometric constructs such as circles and polygons, not to mention 3D modeling. It wasn't surprising that someone had already written an ActionScript library to parse and render SVG, although importing scripts within SVG would be much more challenging.
One popular, but not entirely documented feature, is the Flash player's new ability to exchange data with other Flash applications on the desktop or across a network. Several examples of collaborative clients were demonstrated. Since the player now accepts audio and camera inputs in addition keyboard and mouse, most demos involved messaging, whiteboards, and video chat.
The conference was refreshingly light on product pitches. Mostly it was focused on developers showing off their work. To judge from the backgrounds of some presenters and the topics they covered, Macromedia is making good progress toward bringing its products into mainstream software development.
However, Flash faces two hurdles against widespread adoption as an application platform. The first is perception: Flash is largely associated with superfluous chrome and, ironically, heavy bandwidth. The other is that programmers without previous Flash experience will not easily grasp or accept a motif in which "movies," "clips," and "frames" are the base objects. The new Flash IDE wisely has a developer mode that conceals most of the animation features, but it would be better to offer an alternative model in the language itself.
Also, if Flash is to be an embedded mini-browser for tasks that Web browsers do inefficiently, Macromedia and other evangelists should take care to distinguish between appropriate uses for Flash and content that should remain based on HTML and other text-based protocols. Adobe's PDF has already established a beachhead for binary documents, but that's no reason to embrace added complexity. A surplus of unselectable text and browser-proof links will not enhance the user experience.