As the Internet continues to evolve into an "Internet operating system"--programmable interfaces, ubiquitous access, and distributed computing resources--the document-centric browser is an awkward solution to a growing number of emerging needs. The browser is not dying by any means; it just needs a mate. And an ideal partner would be an Internet-application-runtime engine to provide optimal user experiences. Flash MX player and the SWF file format shows the potential to serve as such a complementing mechanism.
In this article we'll look at current browser-based solutions, review the capabilities, then discuss ways that a lightweight Internet application using Flash MX player and SWF can improve a user's experience.
The browser has served us well and continues to do so. (Long live the browser!) So why do we need an application-centric complement to it? Evolution. The capabilities of Internet technology and how we use it continue to morph and unfold as the dominant technological platform by which we communicate and do business. The browser has been an integral part of that platform by providing a means to publish document-centric resources and basic interactive applications in a simple, open, and cross-platform way. However, the emergence of the transactional Internet, via Web services, beckons new and richer ways for users to more efficiently use this part of the Internet.
Let's consider Internet banking, an online service that I, like many of you, use on a weekly basis. I truly appreciate how it has made my life much easier and more organized. I'm frankly not sure how I would operate without it.
As an experienced developer, I know the interactive team at my bank's service really couldn't have done much better because of the browser's low intelligence and functionality. (I'm pleased that they refrained from frames, expiring pages, or using Java's mutant stepchild, the applet.) Still, it leaves me wanting something more elegant for the task. We have to do some pretty silly things to provide rich application features. If you've developed "fat-client" applications in Visual Basic and Powerbuilder as I did earlier in my career, you know that these issues were not acceptable by users then and could be easily remedied if they came up at all.
The fact of the matter is the browser is not a panacea for all solutions. Browser-based applications require a connection and a server to operate. Bandwidth use is highly inefficient, which adds latency to the application's response and erodes the user's experience. The browser uses a page-centric model with poor support for "tightly coupled" screens, functions, and interactions; and only recently has it begun to add the most rudimentary features for direct data transactions.
Again, my intention isn't to degrade the browser (even though it may sound like it!), but to demonstrate how the Internet could benefit from an application-centric browser.
These experiences have led me to consider Macromedia's Flash Player and its underlying SWF format to provide a means of delivering lightweight Internet applications. While Flash and the SWF file format descend from being a multimedia/animation player, recent iterations have introduced increasing amounts of application features such as embedded forms (scripting language, object, and events model), user interface components, and XML feeds. The addition of these features provides developers with the means to take various inputs, such as scripting logical operations on the client-side and communicating with backends across the Internet.
In many ways Flash MX promises to do for Internet applications what Visual Basic did for Windows applications in the early '90s. Flash MX encapsulates the most common, low-level functions that can be scripted with relative ease by a developer. These applications are small and compact because they share a preinstalled core engine. According to Macromedia, Flash enjoys 90% plus market penetration though the latest MX player has just surpassed 30% as of June 2002.
Flash is not perfect, but it's the best, current solution for developing and deploying cross-platform, lightweight Internet applications.
SWF Is Not Flash (and Other Vectored Thoughts) -- With increased interest in SVG, some are saying Flash technology might be on its way out. "Not so fast," says Jacek Artymiak. Flash has more to offer than many realize.
SVG On the Rise -- Scalable Vector Graphics (SVG) are working their way into the fabric of the Web and mobile devices. SVG Working Group member Dean Jackson outlines SVG's progress and builds a case for its growth in popularity.
I was disappointed with the initial debate, and sometimes the uproar, surrounding Flash MX and the SWF format that had focused on its multimedia functionality, particularly vector graphics, and its support (or lack thereof) of all open specifications. To some degree, I think an important aspect of Flash was overlooked in these posts--its ability to serve as an Internet application runtime engine.
Comparing SWF and SVG is not like comparing apples and oranges, but rather apples and a fruit basket. The argument over which is the better vector graphics or multimedia platform is increasingly one of splitting hairs, as the two will become essentially more similar over time. Simply put, we would all be better served by considering the functional issues facing Internet applications today and discussing how Flash MX could be a tool to address them more effectively.
Nonetheless, the notion of Flash as something more then a multimedia or vector graphics format is beginning to take root. The recent release of the Flash Communications Server demonstrates such potential. See Scripting Collaborative Applications with Flash Communication Server MX by Jon Udell for an overview.
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.)
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.
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.
Copyright © 2009 O'Reilly Media, Inc.