Flash MX and the Bigger Picture: Lightweight Internet Applications
Pages: 1, 2
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:
<payments>
<account>1234567890</account>
<session>JD83NDMCK9JDL0KSJLL</session>
<payment>
<payee>40</payee>
<amount>127.90</amount>
<date>08-17-2002</date>
</payment>
</payments>
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.)
This scenario also benefits from the Flash MX environment's persistence between transactions to intelligently manage the application's state and local data persistence. Instead of popping open that JavaScript window that may or may not work, the client application could lock itself when inactive for an extended period of time and return to its original place in the session with a password.
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 <textarea> exist. Internet Explorer for Windows includes a basic HTML user interface widget that can be embedded into Web pages. While somewhat useful to those with that configuration, it precludes an estimated 10 percent of users who do not. This solution is also limited to HTML and is not very extensible for more focused tasks. Solutions using Java applets exist, but at a cost. Could Flash MX be used to develop a better solution? Examples such as Stuart Schoneveld's Rich Text Editor illustrate Flash MX's potential to do so.
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.
Conclusion
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.
Showing messages 1 through 2 of 2.
-
hybridize
2002-12-30 11:53:12 anonymous2 [View]
-
Rich Media Client
2002-09-09 01:10:56 janmetpet [View]
We have been bugged long enough by a primitive interface, provided by the web. It's time for rich media clients for applications. Documents can still be brilliantly served by HTML. You have to rethink your model though, because a rich client requires a paradigm shift. You have to take into account new security issues, but it's worth the switch!
For instance the MX player still isn't very efficient in parsing and handling XML , and doesn't handle documents in memory very well.
HTML presentation is limited , you can't navigate an imported HTML doc if is isn't xhtml.
You can't establish a secure socket connection directly.
There's no direct access to memory and you have to roll your own task scheduling methods.
I think that the best route is hybridize the development of such apps using Flash and a container environment ( the browser , an HTA , C++/VB wrapper ). This method exploits Flash's strengths as a UI layer and interactive visualization medium while providing a more robust alternative runtime for offloading certain computation and memory intensive tasks. It's alot like the concept of hard & soft layer development.