Asset Management Tradeoffs With Flex
Adobe’s Flex comes with a lot of power, and along with that responsibilities that web designers don’t have to acknowledge with current art.
Regardless of how a web page’s HTML is generated (e.g., completely static, mixed code a la ASP or PHP, lost in space with .NET, or completely data driven), asset management is straightforward and linear: It shows up when the page is fully loaded.
Flex can manage assets much more intelligently, loading them in the background while other foreground presentations are active. The result of this management is immediately noticeable in more responsive presentations, smooth and quick transitions between and among logical or workflow sections, etc.
In fact, the layout of presentation flow possible with Flex opens up some new opportunities in information conveyance, helping to insure that the viewing customer always knows what it is that’s being offered.
All this neat stuff still comes down a wire, and the choice of embedding, caching or in-line retrieval can often be more an art then a science.
Generally, the small things (e.g., button icons) can be embedded provided that there aren’t too many of them, because the overhead of bringing them down the wire incrementally is often larger than their imbedded size relative to the initial swf file to begin with.
Larger things (e.g., a high resolution JPEG image or Flash movie) are going to take a while to load, regardless of whether they’re imbedded or loaded in the background. The challenge here is to partition the transitions in the Flex application’s flow to minimize the perception of delay.
Of course, if Flex’s SDK needs to be loaded then there will be an initial hit, but response should be fast once loaded and installed.
Bottom line is that designers now have more options and more, well, flexible tools to present information smoothly, quickly and with flair. Try that with static HTML.