Last fall I asked a question that I'll probably keep on asking in various contexts: Can rich Internet apps be web-friendly?. In response, Macromedia chief software architect Kevin Lynch created an example showing how the state of a Flash app could be exposed on the browser's URL-line, and thus made available for bookmarking, deep linking, and scripted integration. There was also some follow-up discussion on integrating this technique with the browser's navigation history.
Yesterday I had a long conversation with Kevin in which I learned, among other things, of further efforts to improve the web-friendliness of Flash. Here, for example, is a display that shows how my last 15 weblog posts have been received by readers of the Macromedia XML News Aggregator:
If you right-click on this Flex-generated display widget, you'll note that it has a non-standard View Source option. If you click it you'll get a File Not Found error, because I'm hosting the display widget here on my blog and not in its normal context. When the widget is served from the Macromedia site, though, the View Source option produces this MXML source code. And the ActionScript reference from within that MXML source is also linked. Daniel Dura is the Flash developer who adapted Mike Chambers' View Source hack as the Flex component that's used in this example.
As many have observed over the years, the View Source principle has been a wellspring of innovation. When people can see how things are done, and can easily imitate those things, progress kicks into high gear. Of course viewing the MXML and ActionScript source behind a Flex application doesn't mean you can imitate it. That currently requires an expensive server-based setup, something that OpenLaszlo does away with. I'd love to see Macromedia find a way to similarly democratize Flex development.
If you visit the news aggregator from which I've extracted this display widget, you'll see more web-friendliness. In a blog item about the aggregator, Kevin notes that its developers -- Christian Cantrell and Mike Chambers -- have used the application to prototype and demonstrate two-way integration between JavaScript-driven features of the DHTML web page and ActionScript-driven features of the Flex widgetry. Specifically:
Clicking on the feed names loads new HTML content in place on the page as well as updates the chart in Flash. Clicking on bars in the Flash chart also communicates out to the page to load new HTML content in place below, all without refreshing the whole page. [Kevin Lynch: ActionScript/JavaScript integration]
Nice!
While we're on the subject, I'll greedily toss a few more items onto the wish list:
Pervasive deep linking.
If I link to the aggregator, it defaults to the Macromedia category and to Kevin Lynch's blog. You can navigate to the Technology category, and thence to my blog, but there are no URLs exposed for these, so I can't link from here to there. In this case it's not a Flash issue, it's a DHTML issue. But the principle is exactly the same. Toolkits and frameworks for building rich Internet apps ought to make support for deep linking a no-brainer for developers. It should be the rule, not the exception.
Straightforward component extraction and reuse.
I love the fact that I was able to extract an instance of the aggregator's display widget and repurpose it here on this blog. There is some degradation, of course. Clicking on the chart's bars doesn't synchronize to the corresponding blog entries because I haven't recreated the necessary context. But I'd argue that the widget degrades gracefully and remains useful.
Figuring out how to reuse the widget, however, required a bit of spelunking as well as some educated guesswork. Part of what made View Source so compelling was the ability to carve hunks of HTML out of pages, splice them into other pages, and have things generally just work. Clearly that won't always be possible in mixed environments like the Macromedia news aggregator, where the application combines static HTML, AJAX-style dynamic HTML, and embedded dynamically-generated Flash componentry. Nevertheless, I was able to reuse that Flash component. Here too, toolkits and frameworks could anticipate such reuse and organize applications in ways that encourage it.
Former URL: http://weblog.infoworld.com/udell/2005/06/01.html#a1242