Google’s initial announcement was so incredibly vague as to render it all but useless. Developers came away knowing that Google was doing something different with their Flash content, but that’s about it.

While Google’s Dion Almaer suggested that search engines have always been black boxes and that it was up to us to discover what had changed through testing, just about everyone else was crying foul.

Google’s credibility was immediately in question due to the obviously bad advice it contained:

"If you prefer Google to ignore your less informative content, such as a "copyright" or "loading" message, consider replacing the text within an image, which will make it effectively invisible to us."

For the record, replacing fast-loading, accessible text content with a bulky image simply to hide it from search engines is never a good idea.

Google’s list of caveats in the announcement were similarly perplexing:

"Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed."

What types of JavaScript? Established best practice for publishing Flash content is to use the SWFObject JavaScript library to overcome bugs in older browsers, so was Google saying that it would only index Flash content that was authored using broken/outdated HTML-only techniques?

"We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file."

Any experienced Flash developer knows that if you are going to have any significant amount of text in your Flash content, your best bet is to stick it in an XML file and load it on the fly, so you don’t have to rebuild your Flash movie whenever you change the content.

Apparently, not only will Google not see Flash content authored this way, but it will track down the XML file anyway and index it as a separate page on your site! That’s right, Google will helpfully direct people searching for your content to the raw XML file that contains it, rather than your slick, Flash front-end.

All this stuff made so little sense, that many developers questioned whether Google was actually able to index any Flash content of consequence. Within a few days, however, the Search Engine War blog was able to verify that Google was indeed indexing Flash content.

Finally, after several days of developer outcry, Google admitted it had left too many questions unanswered, and four days later, it posted a significant update that is well worth reading if you have any Flash content on your site.

Here’s a quick summary of what we now know:

• The July 1st release didn’t index Flash content inserted with the SWFObject library’s dynamic publishing method, which writes the Flash content into the page entirely with JavaScript. The recommended static publishing method (where two nested <object> tags are included in the page) was indexed. Google is now deploying an update that supports the dynamic publishing method as well.
   
• Text content loaded on-the-fly from an XML file is not yet indexed, but Google is working on fixing this in the near term.
   
• Google will do its best to detect when duplicate content is there to provide an HTML alternative to Flash content, and will only display one of the two versions in the search results. No penalty is applied to a site’s search ranking due to duplicate content.

There are still unknowns here, but that will always be the case with the Google search engine. Though it took a few days, Google is answering what questions it can, and responding to developer concerns with enhancements.

Before very long, most of the text within Flash-based web sites will make its way into the Google search index. Nevertheless, uncertainty will remain over how deeply Google is able to probe Flash content for a while yet. Providing non-Flash alternative content will remain an effective means of guaranteeing your most important content a place in the Google index. It also gives users of non-Flash-enabled browsers (like the iPhone) something to look at.

Though Google’s initial message was pretty half-baked, the follow-up has put most of my concerns to rest. How about yours?

Cutting through the jargon on the press release, the most significant points are that Adobe are removing restrictions on usage of the Flash and Flash video specifications (SWF, FLV, and F4V), publishing the device porting layer APIs, and removing the licensing fees for the next major version of the Flash Player and AIR for devices. Which means that developers will now be able to port Flash to any device, and distribute and deploy it for free. Additionally, the Flash Cast and AMF data transfer protocols will be published.

While Flash Player has long been an almost ubiquitous platform for desktop PCs, this new move aims to do the same for phones and portable devices. Ryan Stewart and Dave McAllister from Adobe have both written blog posts on the announcement.

Essentially, the Flash player is now about as open as it can possibly be without being open source. It’s an interesting move by Adobe, and I’m sure many will be watching to see what comes out of it.

Because Macromedia Adobe will not be offering free licenses for non-commercial users of Flex 2 as it did for Flex 1, I’ve avoided recommending the technology to people despite the steady stream of exciting news that has come with the successive pre-release versions (now Beta 2).

The latest exciting tidbit — which has forced me to grudingly give the platform another look — is that Adobe has developed the Flex-AJAX bridge. The name is slightly misleading, as it’s really more of a Flex-JavaScript bridge, but it does help Adobe fend off some of the perception of AJAX as a Flex killer.

This bridge is an extension library for Flex that, when loaded, allows JavaScript code in a page to communicate with a Flex application, getting/setting property values, manipulating user interface elements, and registering JavaScript event listeners for elements inside the Flex application that would otherwise only be accessible to the ActionScript code within the application. Likewise, the bridge allows the Flex application to reach out into the containing HTML document, get/set form field values, manipulate CSS properties, and register event listeners that will allow the Flex application to respond to JavaScript events.

Where previously Flex was seen as an all-or-nothing platform for web applications, where your Flex application just filled the browser window with a Flash movie containing the user interface, the Flex-AJAX bridge lets you build hybrid applications, with smaller components that can benefit from Flex’s flexibility while the rest of the user experience can continue to be presented using HTML and CSS, with all the added compatibility and accessibility that brings.

To try out the Flex-AJAX bridge, you’ll need the most recent beta release of Flash Player 8.5. You can then check out the simple hybrid store example that Flex developer Christophe Coenraets described in a recent blog entry. The application makes use of the slider component from the Yahoo! User Interface Library to provide some JavaScript-powered controls that allow you to filter a set of results displayed in the adjacent Flex application.

A more detailed example may be found on the Adobe Labs site, which shows off the remarkably simple JavaScript code required to communicate with Flex using the bridge.

I’m still not jumping on the Flex bandwagon just yet, but if the right project came along and the investment were justified… well, you never know.

Macromedia Labs in itself is an exciting change of direction for Macromedia, which plans to use the site to expose developers to experimental technologies, works-in-progress, and other early ideas coming from the software company. With full community features like open discussion forums and a wiki, it will be interesting to see how this openness flies with Macromedia’s nearly-complete merger with Adobe, another traditionally closed software company.

Flex 2 will include Flash Player 8.5, Flex Framework 2, Flex Builder 2, and Flex Enterprise Services 2. Although the updated software will not be ready for release until the first half of 2006, Macromedia plans to release alpha versions later this month, in conjunction with the MAX conference on October 16th.

Flash Player 8.5 will add a new ActionScript Virtual Machine (AVM2), supporting ActionScript 3.0 (AS3) — an updated version of the scripting language that will be compliant with the latest ECMAScript standard, including ECMAScript for XML (E4X). AVM2 will run a great deal faster than the existing AVM, and will support many advanced language features, most notably improved debugging and error reporting.

AVM2 will run alongside the existing AVM, and only Flash movies compiled for AS3 will run on this new VM. The downside of this architecture is that movies and components that use AS3 will not be interoperable with those that use AS2 (e.g. an AS3 movie that loads and displays a nested movie that uses AS2 will not be able to access functions and variables within that movie). For this reason, components compiled for existing versions of Flex will need to be recompiled to work with Flex 2.

Flex Framework 2 will be the upgraded library of classes and user interface components for this new release. It will be updated to take advantage of AS3, with cleaner APIs, and taking full advantage of the new effects introduced in Flash Player 8.

Flex Builder 2, previously code-named Zorn, will be the new IDE for Flex, rewritten from scratch to run on the Eclipse platform. As with the current version of Flex Builder, it will provide a split graphical view (with drag and drop GUI building) and code view (with full code hinting and debugging support). New in this release will be developer productivity features for managing “view states”, discrete modes of operation for Flex components.

While the current version of Flex costs some US$12,000, Flex 2 will cost less than US$1,000 for the basic components described above. Although you’re constrained to communicating with the server via XML data transfer and SOAP Web Services, you can certainly implement anything you can do with AJAX and DHTML, only with a richer GUI. What’s missing from the package is the server-side component of the Flex framework, which has been split into a separate product for Flex 2: Flex Enterprise Services 2.

Flex Enterprise Services 2 will come with the big per-CPU price tag, but will be significantly upgraded from the server-side facilities provided by Flex 1. The main focus of the enhanced package is the transparent availability of server-side resources (such as database records and enterprise services) within Flex applications.

Although the greatly reduced price tag for developers who don’t need the Enterprise Services package is welcome news, Macromedia does not plan to continue offering free non-commercial/non-institutional licenses as they now do with Flex 1. With students and hobbyist users having obtained free licenses and developed applications with Flex 1, they’ll either have to front up for a license to Flex 2, or be left out in the cold. This seems like a very unfortunate move to me, and I hope Macromedia will reconsider.

For more details on Flex 2, check out Macromedia’s introduction for developers.

1. Set up a VNC server. The free VNC Server for Windows (previously WinVNC) will do the trick on Windows boxes, and there’s OSXvnc for Mac.
2. Install and run vnc2swf. You’ll need to set up Python first, but everything you need is linked on the site. Once it’s running, hit F9 to start recording your desktop.
3. Stop recording when you’re done. An SWF is produced, which you can publish on the Web.
4. Use the companion editing tool to chop off the pieces of the movie you don’t want to keep, and then add an MP3 soundtrack recorded separately.

And just like that, you’ve got your screencast! The screencast demonstration on the site is a little tough to follow if you’re not up on your Unix commands, but with a little tinkering at the command prompt you should be able to get it to work on Windows or Mac OS X with relatively little trouble.

Screenweaver was another answer to this question. It began its life as a simple app for creating Flash-based screensavers, and grew into an integrated development environment (IDE) for Flash-based desktop apps. Screenweaver was also a commercial failure, but a small group of intrepid developers have rescued it from binary oblivion to continue its development as an open source project.

The announcement provides a little history on Screenweaver’s origin, as well as a side-project called Screenweaver Core–a library for using Flash within general-purpose programming languages like Visual Basic, C++, and Python on the Windows desktop–which is also being resurrected.

If you’d like to play with the initial open source release of Screenweaver 3, hit the project’s main wiki page, click Download, and grab the precompiled binary. You may also want to follow the link to the documentation, which is not yet included in the download.

The initial plan for the open source effort is to enhance Screenweaver to support synchronous communication between Flash applications built with Screenweaver and other operating system components. The soon-to-be-released Flash Player 8 includes support for ExternalInterface, a new ActionScript API that allows Flash movies to pause and wait for a request (such as calling a JavaScript function in the browser) to complete before continuing.

Synchronous communication is much simpler to manage than previously-supported asynchronous interfaces to the host environment, and developers like Darron Schall (the instigator of the Screenweaver OS project) believe that this type of communication will be key to making Flash desktop application development a popular reality.

For now, it lacks the flat maps, local search features, and other useful bells and whistles of the Google and Microsoft originals, but as a demonstration of what is possible with Flash as a frontend technology, it’s very effective. In particular, the ability to rotate the view is something that is a long way off in pure DHTML interfaces.

I wonder how long it will be before some enterprising folks attempt to produce a 2D clone of Google Earth in Flash. I’d be surprised if Google didn’t buy out such a project, were it to come to fruition.

Main features are a huge reduction in file size (over 2/3 smaller than their MMV2 counterparts), easily styled and best of all easily skinnable (the most annoying feature of the MM components is their difficulty in being skinned)

Take a look at the bottom of this page for demonstrations of how easy the components are to skin!