|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
Flash MX and the Bigger Picture: Lightweight Internet Applications
Flash in Action
Let's look at some examples of Flash in action. Earlier I reviewed my experiences with an online banking application that I find quite useful, but which suffers from some quirks that degrade the overall experience. How does this application change if we apply Flash MX and its application features?
First, embedding the application in an HTML page yields only one URL for my one user session. Like framesets before it, this does eliminate the "bookmarkability" of all screens other then the initial startup screen. The ability to search content within the application is limited at best. However, in the case of our banking application, this is quite all right and most likely preferred. These are design decisions that need to be carefully considered.
This application would make efficient use of bandwidth, once streamed to the client. There is an initial use of bandwidth at startup that is likely to exceed the size of a single HTML. (Depending on the sophistication of the application and with careful design consideration, this can be marginalized.)
Once streamed to the client machine, the application would only need to pass simple messages to the banking system's backend. For instance, making a payment may generate an XML message to securely pass to the backend, like this:
When you factor in the weight of each page in a browser-based solution you can see how it is worth the initial startup cost. This is less than 1K compared to the 25K to 60K that a typical HTML page would consume. This also translates to reduced loads on the bank's servers.
In more advanced scenarios, lightweight applications such as this one could be downloaded and used without the browser. And when a new version of the application is available it could be pushed down to users. (This technique is referred to as application provisioning.)
The state and data management of Flash could enable the application to queue messages if a connection was not present. It could enable a detailed dataset, such as payment history, to be retrieved in one request and displayed by the application in summary. A user can then request to see an entry's full detail without a trip back to the server. These are just a few of the ways these capabilities could be used in developing a more efficient, streamlined solution.
Now, let's briefly consider a more utilitarian use of Flash's application capabilities, which addresses one of my longest standing pet peeves: in-browser HTML/XML editing. Despite being a common requirement, few options other then manually editing markup in a
The momentum is beginning to build for Flash applications. Real applications are beginning to be deployed. Macromedia has cited examples such as E*Trade's stock quote system and prototype applications such as Philip Chung's news feed visualization.
While I propose what may be a radical notion to some, with additional consideration the value of lightweight Internet applications starts to become apparent. I am not proposing that the browser is dying, but rather that it would be enhanced by an application-centric complement. Flash MX and its underlying SWF format are ready to provide such a solution today, though some have misgivings because SWF is a proprietary format held by one company--Macromedia. However, few viable alternatives currently exist to address this emerging need. More consideration is needed to apply these technologies to improving user access and experience of these online services. In writing this I hope that I have done so.
Timothy Appnel has 13 years of corporate IT and Internet systems development experience and is the Principal of Appnel Internet Solutions, a technology consultancy specializing in Movable Type and TypePad systems.
Return to Web Development DevCenter.