Phil Torrone inteview on New Riders. He focuses on the Flash part of Macromedia MX, particularly on devices, and talks about FlashForward, what people are asking, how to proceed in this area... useful meta-information.

Dave Winer asks What does the Google API mean for regular folks?

Caveat: I don't know what I'm talking about. That won't stop me from having opinions though.... ;-)

I see it as a nested series of implications:

• It's nice to be able to show current top links about a particular topic in a page
  
  
• It will be more fun when the additional Google services open up: newsgroups, news images, whatever else they have cooking
  
  
• It means we can find out things about things that find out things... you can go to a place that learns from the world about a particular item
  
  
• It's a cool service available across the web... it validates the concept of retrieving things on demand, of different computers talking together -- it validates the concept of a live network
  
  
• It will be even cooler in applications than documents. It will be even cooler in applications than documents. It will be even cooler in applications than documents.
  

I'm a big fan of Google. I use other ways of finding things too, but a lot of what I end up doing each day is learning things, finding things, pointing to things. I navigate through the collective knowledge. The Google API seems an elementary thing -- you're offering the data on request without a particular presentation cluttering it up -- but it seems significant both in what it directly enables and what it implies developers will be able to do with other types of services too.

Weblogs ... On Video? focuses on one part of Economist's View of Blogging article. I could see how it would be easier to speak something to your webcam for later retrieval by others. But how would you scan something like this? Text is great because you can adjust your reading speed and depth very quickly... if someone made a video-enhanced Flash-based blog, then how would a viewer navigate and evaluate within that stream...?

Samuel Wan offers a Flash-based XML visualizer and more. I haven't used it yet, but you apparently enter well-formed XML into the applet and it creates a hyperbolic tree display of the data. (Someone was asking about hyperbolic trees recently, but a quick groups.google.com search does not show where...?)

Back to Google APIs, I guess the point I was trying to figure out yesterday was that, aside from the refresh and client-side interactivity advantages of pulling the data from a Flash applet, the server can deliver the page *before* completing negotiations with multiple web services... you don't have to wait for all data to arrive before delivering the original page.

Because of Flash's security model your applet would still be requesting the distant data through your own server, rather than directly, but you'd be handling the multiple requests as separate processes without formatting costs, rather than waiting for all data to arrive before formatting and serving anything.

Dave Winer on the Google API, with an early example of its use. More info at Google blog and Rael Dornfest's article.

I haven't gotten into this area yet, but from what I currently understand it is easier for a web application to query Google and get parseable results... instead of getting hits embedded within an HTML display we can instead request cleaner data from Google.

Where does this fit with Macromedia MX? I'm constrained in what I can say about upcoming releases, but the current Macromedia Flash MX can offer some advantages, within some constraints. The Macromedia Flash Player only talks to its hosting server for security reasons (it plays behind the firewall, and could otherwise invisibly guess paths to protected information). You can use various approaches on your server to request live data from Google which is then available to your SWF.

But take a look at Dave's weblog query example again. It looks like he's calling three source of live data: recently changed blogs, a Google query, and a NYTimes feed. Once the server retrieves all this data, it can then make a customized HTML page. I don't see obvious signs of caching here, which implies that the server is doing a lot of work.

Suppose the live Google search was done in a Flash applet. The server would still retrieve the data from Google for the applet, but wouldn't have to create markup for it, wouldn't have to merge it into other markup. The server could focus on ferrying the data itself, and let the display work be done on the viewer's machine. Such a Flash applet could have additional buttons for "UserLand" or "flash crack", and the new query could be submitted live -- all the server has to do is ferry along the new request and data, and doesn't have to do any additional formatting work at all, doesn't need to change any other aspect of the page.

Rephrased, web services can be useful in server-side creation of static HTML pages, but client-side interactivity with live data requests can reduce the overall server load and increase the speed of immediate viewability.

But I like the Google example at weblogs.com... it shows a new and different way of looking at information. The information presented is still up to the designer, and the user can't interact, but, but it's fascinating. Reminds me of of search engine voyeurs, such as the Ask Jeeves Keyhole, it's a way to see what everyone else thinks is important, right now.

I've got a gut feeling there are ways that Macromedia servers and authoring tools can help with this type of immediacy, but I know for a fact that a smart client-side applet can make things more efficient for both the visitor and the server, too. Finding what else is out there is important, and it's cool that Google has apparently taken a step to make this easier.

Tim O'Reilly, in Inventing the Future [via Robert Occhialini] , hits on many of the same themes driving Macromedia MX... pervasive connectivity, serendipity through expimental combinations, better ways to find things and tie engines together, the implications of digital copying, the new power from requesting various resources from distant machines.The final part on meta-spiders is especially interesting, even though I don't understand it yet. 8)

I particularly like this paragraph, "But the most interesting part of the story is still untold, in the work of hundreds or thousands of independent projects that, like a progressively rendered image, will suddenly snap into focus. That's why I like to use the word 'emergent.' There's a story here that is emerging with increasing clarity."

There isn't a single planned answer for all situations, as today's Hailstorm announcement confirms. Learning the future is a decentralized activity, and that's why I'm bullish on many developers, in their own communities, quickly developing appropriate applications.

Shawn K of Wicked Intellect offers a beta implementation of Flash XML-RPC for Blogger. I'm embarrassed this wasn't on my radar until now. But hmm, I wonder what advantages this offers over an HTML interface for this particular task...?

Anil Dash discusses MX-like issues in Stories and Tools. I call them "documents and applications", because most pages don't seem to have much of a plot, but his phrasing is more elegant. He links to DomAPI, which I've seen before, but will study now. In the comments Robert Occhialini brings up the critical point that Flash MX is only the very first part of the Macromedia MX initiative. I'll have to re-read both... doesn't matter so much if we reach different conclusions, but it's good to hear from folks who are identifying the same problems.

(Holy smokes, Robert found this experimental blog too. I'll have to learn what I'm doing here.... ;-)

More FlashForward comments, from Jarle Bergersen. Big takeaway was the lack of wireless connectivity in the hall. I'm hoping we can get this set up at Macromedia Conference 2002 in Florida this October, but haven't heard word yet. If this request comes in to the organizers through multiple channels then that could help increase the priority of wireless connectivity at the conference. Esther Dyson recently had a high-profile article about how such connectivity can change conferences. Anything that keeps us away from a Q&A session with five-minute-long non-question declamations is A-OK by me.... ;-)

While watching reaction to MX last week, I realized that ColdFusion and Flash communities reacted in different ways. ColdFusion developers routinely said "Hey, Broadmoor is cool, the page doesn't refresh!" and were eager to get in and study Flash. So far, in Flash communities a recurring thread has been "I want to use PHP (ASP), I don't want to buy ColdFusion."

Tonight I realized that one reason is because the ColdFusion developers see a better way to deliver things they're already doing... from firsthand experience they know the costs of having the server generate a series of static webpages for each interaction. For Flash, most haven't seen the power and economy that ColdFusion offers over server-side scripting languages, and few so far have seen the types of applications that can be built with the upcoming communication server. It's much easier to go for something when you can directly see the benefits.

I'm not sure what to do about this yet... I've seen enough people compare ColdFusion to scripting and realize that their software costs are quickly surpassed by labor savings, but I'm not sure how to effectively bring this point across... maybe each person needs to find it out for themself, with some Darwinian selection happening? Dunno.

San Francisco burritodelivery.com is cool, but could use a Flash interface for a PDA form factor. Compare it with Waiters on Wheels... Burrito Delivery handles a range of customization options, where WOW deals with commodity items. I also get the sense that there are real people behind Burrito Delivery.

But both could benefit from being applications which live on the client, rather than documents generated by the server. The Burrito Delivery interface could be rephrased into something which fits into a series of screens on a PDA, couldn't it...?

Wired's IPod article discusses how people are hacking the hardware/firmware to get the features they need. Once you get a good display, input, memory, processor and connectivity, having a layer for customized applets seems vital. The other part is customizing what these applets have access to... customization and connectivity on the server. The big computer talks with the little computer.

Pollsters ask people 8-17 years old "If you could have only a TV, a radio, a telephone, or the Internet, which would you choose?" Telephone gets 21%, television 26%, Internet gets 33%. Why the new shift? "Interactivity seems to be the primary differentiator between the two mediums... Internet for kids is a lot more than just a medium; it's a communications tool."

Oddpost runs only in IE/Win. They shoulda used Flash.... ;-)

(They do bring up that important point about separating data from presentation, however... unlike other browser-based email managers they just send the changing data, rather than generating an entire new page on the server. This reduces transmission costs, lessens the load on the server, and client-side interactivity is zippier than just server-side interactivity. I'd bet someone will bring similar capabilities to a wider audience via Flash.)

Swiveling Clie device is cool, but that PalmOS doesn't have the Flash Player or wireless connection yet. Still, I could see carrying something like this around, if it let me connect to the world efficiently.

btw, here's the current status for Flash on various devices. The Flash Player 6 SDK will be available to device manufacturers too, but like the SWF6 file format SDK it's getting locked down now that the authoring and player environments have shipped.

Key tactic: You should be able to interact with the world despite not sitting down at a desk. (Hmm, that sounds funny.... ;-)