On July 1st, Google announced that, using technology provided by Adobe, it had enhanced the Google Search Engine to index the text embedded within Flash movies. What followed was bad advice from Google, second-guessing by web developers, and finally a few straight answers.
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:
<object> tags are included in the page) was indexed. Google is now deploying an update that supports the dynamic publishing method as well.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?
via Comments on:
On July 1st, Google announced that, using technology provided by Adobe, it had enhanced the Google Search Engine to index the text embedded within Flash movies. What followed was bad advice from Google, second-guessing by web developers, and finally a few straight answers.
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:
<object> tags are included in the page) was indexed. Google is now deploying an update that supports the dynamic publishing method as well.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?
via Comments on:
Today Adobe announced the Open Screen Project which aims to bring the Flash player to as many different devices as possible.
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.
via Comments on:
Today Adobe announced the Open Screen Project which aims to bring the Flash player to as many different devices as possible.
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.
via Comments on:
We’ve extended the deadline for this competition by two weeks.
You asked for more competitions, so here’s another one!
We’re giving away two copies of Adobe CS3 Web Premium (kindly donated by Adobe) to the authors of the best articles about Adobe Flex and AIR submitted over the next four weeks.
That’s right — you could WIN a copy of the ultimate graphics package for web developers, Adobe Creative Suite 3 Web Premium, just by submitting an article about Flex or AIR. Worth USD $1,599, the package includes the latest versions of Photoshop, Illustrator, Fireworks, Flash, Dreamweaver and a host of other tools that form the industry benchmark for creating web graphics.
How To Win
Submit your article to submit (at) sitepoint.com.
Some tips on writing for SitePoint:
For more tips, please read our Write For Us page and our author submission guidelines (PDF).
Oh, and another thing…
Even though there will be only one winner for each of the topics, we may choose more than one article for publication. In fact, if they’re all good, we may publish the lot! So even if you don’t win, your article may still make the front page of SitePoint!
That is all. Get writing and good luck!
via Comments on:
Microsoft’s recent decision to change the way ActiveX objects are handled in Internet Explorer, following the patent law suit by EOLAS, has created a serious problem for the developer community.
All ActiveX controls in Internet Explorer — including Flash and Shockwave — will need to be activated by a mouse click (or by hitting Tab and the Enter key) before the user can interact with the control. This is bound to impair the user experience of any web site that embeds Flash, and it’s up to the Flash and HTML developers to clean up the mess.
You can bypass the activation requirement by using an externally linked script, such as JavaScript, to embed the ActiveX content. Solutions are currently available for Flash, such as FlashObject and UFO.
These work well for embedding new Flash content using JavaScript. But what about existing object tags, which will need to be rewritten, or browsers with JavaScript disabled? These situations require an alternative solution.
The ObjectSwap solution presented in this article takes all these issues into account. It captures all existing object tags and replaces them with … themselves. This forces an automatic activation in Internet Explorer, while leaving other browsers alone. Similar solutions have been developed in parallel, but this article will concern itself only with ObjectSwap.
Although this solution was developed primarily with Flash in mind, it should also work with other ActiveX controls, such as Shockwave. The script affects all the object tags in the page, but the developer can choose to exclude a specific object by setting its class name to "noswap".
Implementation
ObjectSwap was written with a view to make implementation as easy as possible, with minimum disruption to existing code. The only change you need to make to your HTML page is to link the script in the <head> tag for every page that includes ActiveX objects, like this:
<script type="text/javascript" src="objectSwap.js"> </script>Once you’ve done that, you can keep on using your favourite technique for embedding ActiveX content. For Flash, that means either the Adobe/Macromedia default setting using object/embed tags, or the standards-compliant technique that uses only the object tag (better known as Flash Satay).
Flash Detection
So far, so good. But since we’re already using JavaScript, why not avail ourselves of the opportunity to add some Flash Detection to the mix? We can achieve this by adding a new param definition to the Flash object, for example:
<param name="flashVersion" value="7" /> The script looks for this param and, if it exists, will transform the object into a div that displays the alternative content. This content is not generated by the script, but instead must already reside inside the object tag, and display alternative text, images, links to the Flash installer, and so forth. Internet Explorer normally ignores this content if Flash is present. This is also true for other browsers when you use the Flash Satay method, so you can simply add the content anywhere in the body of the object.
On the other hand, if the object/embed method is used, gecko-based browsers like Firefox and Netscape will display the alternative content alongside the embedded movie. The solution is to enclose the content within HTML comments, which will be stripped by the script when the content is displayed. There should be a space or a line-break between the comment tags and content, to avoid conflicts with any IE conditional comments that happen to be inside the object tag:
<!--
<p>You need <a href= "http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash">Flash</a> to view this content.</p>
-->Of course, you can also choose to ignore the Flash detection option, or use Adobe’s express installation for Flash 8 instead.
Browser Support
The activation issue of ActiveX objects affects only Internet Explorer, so most of the code will also affect only IE. However, the Flash detection code needs to work with other browsers as well. This means that the objectSwap function will be called for all browsers to perform the Flash detection service, if required, but will only execute the object swap on IE, leaving other browsers unaffected.
This is all you need to know to start using the script. You can download the script and examples here.
However, if you’d like to know more about how ObjectSwap works, the following sections will reveal the inner workings of the script.
First, the script cycles through all the object tags in the HTML source code and retrieves their outerHTML values:
var objects = document.getElementsByTagName('object');
for (var i=0; i<objects.length; i++) {
var o = objects[i];
var h = o.outerHTML; Since Internet Explorer does not include any of the object’s param tags in its outerHTML (or innerHTML), they need to be extracted separately into a string:
var params = "";
for (var j = 0; j<o.childNodes.length; j++) {
var p = o.childNodes[j];
if (p.tagName == "PARAM"){
....
params += p.outerHTML;
}
}The generated "params" string is spliced into the outerHTML code:
var tag = h.split(">")[0] + ">";
var newObject = tag + params + o.innerHTML + " </OBJECT>";And, finally, the new generated HTML replaces the original:
o.outerHTML = newObject; Hiding the Objects
There are still a few things to be done. First of all, we want to prevent the objects from loading twice — once when they’re initiated in the HTML code, and again after they’re swapped. We achieve this by writing a new style sheet to the document before the page loads. The style uses display: none to take the objects out of the document flow, delaying their loading until the swap is complete:
document.write ("<style id='hideObject'> object {display: none;} </style>");After the swap, the style is disabled and the objects are allowed to load:
document.getElementById("hideObject").disabled = true;Detecting Flash
As it cycles through the parameter list for each object, the objectSwap function checks for the existence of the flashVersion param and, if it’s found, executes a Flash detection method:
if (p.name == "flashVersion") {
hasFlash = detectFlash(p.value);The method looks for Flash in two types of browsers. First, it checks whether the plugin is present in the navigator.plugins array, which applies to gecko-based browsers:
detectFlash = function(version) {
if(navigator.plugins && navigator.plugins.length){
var plugin = navigator.plugins["Shockwave Flash"];
if (plugin == undefined){
return false;
}If a plugin is found, the code still needs to check for the installed version. This is achieved by retrieving the third item in the plugin’s description property and checking it against the passed version parameter:
var ver = navigator.plugins["Shockwave Flash"].description.split(" ")[2];
return (Number(ver) >= Number(version))Next, the script checks for the plugin in Internet Explorer. In JavaScript, it achieves this by trying to create a new Flash ActiveX object with the passed version. If JavaScript is unable to create the object, it will throw an exception, which is why the entire expression must be enclosed inside a try-catch block:
} else if (ie && typeof (ActiveXObject) == "function") {
try {
var flash = new ActiveXObject("ShockwaveFlash.ShockwaveFlash." + version);
return true;
}
catch(e) {
return false;
}
}Just in case some other browser has a different way of handling Flash, the method returns true at its end, as a safety net. If the browser doesn’t have the navigator.plugins array, and is not Internet Explorer, it will still try to display the Flash movie.
Back at the objectSwap method, if the script doesn’t find the correct version, the object’s id is retrieved (or a new one is assigned) and added to a queue:
if (!hasFlash){
o.id = (o.id == "") ? ("stripFlash"+i) : o.id;
stripQueue.push(o.id);
Later on, the queue is passed to the stripFlash method:
if (stripQueue.length) {
stripFlash(stripQueue)
}Stripping Flash
This method cycles through the ids in the queue and retrieves each object’s innerHTML:
for (var i=0; i<stripQueue.length; i++){
var o = document.getElementById(stripQueue[i]);
var newHTML = o.innerHTML;For the object/embed method, where the alternative content has been hidden from Firefox and Netscape with comments, regular expressions are needed to strip the comments from the innerHTML, so that the new content can be displayed in the browser:
newHTML = newHTML.replace(/<!--s/g, "");
newHTML = newHTML.replace(/s-->/g, "");Another regular expression is used to neutralise the embed tag by replacing it with a span:
newHTML = newHTML.replace(/<embed/gi, "span");In order to transform the object into a div, the easiest thing would have been to change the object’s outerHTML. However, that doesn’t work in Firefox; instead, a new div element is created and assigned the same innerHTML, id, and className as the object:
var d = document.createElement("div");
d.innerHTML = newHTML;
d.className = o.className;
d.id = o.id;Finally, the object is swapped for the new div:
o.parentNode.replaceChild(d, o);Initiating the ObjectSwap
ObjectSwapmust be executed after all the objects have loaded, by binding theobjectSwapfunction to thewindow.onloadevent. The catch is that other linked scripts in your page might have their functions bound to the same event; the last script to do so will override all the earlier bindings, causing the other scripts to fail. This is resolved by catching existing functions bound to the event, and calling them as well:var tempFunc = window.onload;
window.onload = function(){
if (typeof (tempFunc) == "function"){
try{
tempFunc();
} catch(e){}
}
objectSwap();
}Naturally, this will fail if following scripts use
window.onload, so you must ensure that either this script comes last, or that the following scripts use a similar technique.Conclusion
ObjectSwapoffers a complete, one-step solution to the problem resulting from the decision by Microsoft as a result of the EOLAS law suit. A single JavaScript file linked from the<head>tag of your page is all you need to avoid Internet Explorer's activation requirement. What's more, you can take advantage of the situation and enhance the user experience by adding some simple Flash detection to your page.%MINIFYHTMLeec5a1944edf40855f0cf10f3643193a22%%MINIFYHTMLeec5a1944edf40855f0cf10f3643193a23%via Comments on:
Adobe’s (formerly Macromedia’s) Flash application is, according to them, "The industry’s most advanced authoring environment for creating interactive web sites and digital experiences." However, many users have trouble structuring their site efficiently within Flash.
When Flash is opened, a blank canvas appears, and a single layer with multiple blank frames displays, waiting to be used, as you can see in the image below. There’s little guidance on how to proceed, and many different directions that one can take. So it’s easy to see why users can become confused.
Over the past six years of working with Flash and helping others with their own Flash projects, one thing has become clear to me: no two Flash web sites are laid out the same. Sadly, over 90% of the Flash sites I’ve seen are not structured efficiently; some are horribly inefficient. While there may be no one right way to structure a Flash web site, some ways certainly are better than others.
Keep in mind that when I say "structure" I’m not talking about how your web site looks; we don’t care how your web site looks, at least, not in this article. Structure is about setting up your Flash site with Keyframes, ActionScript and MovieClips, and controlling the Flash playhead. Good structure can make your site load faster, make it easier to manage and update, and keep unexpected things from happening. A bad structure can increase load times, make it painful to make changes in future, and cause unexpected headaches. The principles explained in this article apply to all Flash site designs.
In this article, we’ll develop a navigation system. Though it might seem trivial, this will serve as a good example for this article and the techniques can be applied to any project you’re working on, be it a full Flash web site, a Flash poll, or a Flash RSS reader. Incidentally, I’ve created all of these in the last month, and all exhibit the structure that we’ll see here.
Now is a good time to go ahead and download the necessary files so that you can follow along. That code archive contains a Flash FLA file, an XML file, a CSS file and a PNG image.
Once you open the navigation.fla file, you’ll immediately notice how empty it looks. This file contains but 2 layers spanning 4 frames. Almost all my Flash ‘creations’ have a similar structure: typically no more than 5 frames and a handful of layers. If your Flash structure looks like the one shown in the image below, you’re doing something wrong — it’s a good thing you’re reading this article.
Let’s start with a tip: Never use Scenes. Scenes can cause unexpected results from the playhead. The playhead doesn’t really move from scene-to-scene gracefully. Depending on your Flash site, you may or may not notice this. But, if you’re playing a music file and your playhead moves to another scene, you can witness problems as the song skips. For this reason, you won’t find more than one scene in our file.
Let’s examine each frame one by one.
Frame 1 is always — and only — used for setting global variables. This works well, as the playhead hits this frame first, sets our globals and moves on to the next frame. We never return to frame 1, ever. It’s important always to control the Flash playhead and know where it’s located at all times. Now, let’s look at the code:
var xmlFile:String = "navigation.xml";
var cssFile:String = "navigation.css";
var nCounter:Number = 0;
var yPosition:Number = 0;
var nTotalButtons:Number = 0;
var astrImages:Array = new Array();
var astrText:Array = new Array();
var astrLinks:Array = new Array();
var image_mcl:MovieClipLoader = new MovieClipLoader();
var mclListener:Object = new Object();
// Formats our textField
var my_css = new TextField.StyleSheet();
// fun with filters (new in Flash 8)
import flash.filters.DropShadowFilter;
var distance:Number = 2;
var angleInDegrees:Number = 45;
var color:Number = 0x000000;
var alpha:Number = .8;
var blurX:Number = 2;
var blurY:Number = 2;
var strength:Number = 1;
var quality:Number = 3;
var inner:Boolean = false;
var knockout:Boolean = false;
var hideObject:Boolean = false;
var filter:DropShadowFilter = new DropShadowFilter(distance, angleInDegrees, color, alpha, blurX, blurY, strength, quality, inner, knockout, hideObject);
var filterArray:Array = new Array();
filterArray.push(filter);Here we see our global variables: some strings, some numbers, and some arrays — your typical variables. But, wait. Some not-so-typical variables are also present: a MovieClipLoader, a StyleSheet and a Filter.
The MovieClipLoader class allows us to implement listener callbacks that provide status information while SWF, JPEG, GIF, and PNG files are being loaded into movie clips. This is a lot handier than the dated loadMovie() class, which failed to provide us with any information on how much of our file had already been downloaded. We’ll use the MovieClipLoader class later to load our button image.
The StyleSheet class lets you create a StyleSheet object that contains text formatting rules for font size, color, and other styles. We’ll use this StyleSheet in frame 4 to format the text on our navigation buttons.
Filters are new to Flash 8; they allow us to add some cool effects to our objects. For example, we can apply drop shadows, blurs, glows and bevels to objects. We’ll apply the drop shadow filter to our text field later. Some will say, "Big deal. If I want a drop shadow I could use Photoshop or Fireworks for that." You could, but then your text would no longer be dynamic, as ours is.
Keep in mind that all the components that make up our Flash site don’t reside in Flash. Perhaps I should have used an exclamation point instead of a period for that last sentence? Let me say it again, "All the components that make up our Flash site don’t reside in Flash!" This approach allows for easy modification later. If, for example, I no longer like the image chosen for my buttons and I want to swap it out, that’s no problem. Or maybe I want to have the button say something different, or perhaps I want to add or remove a button later. Neither will be a problem; in fact, I won’t even have to open Flash to make these changes. That’s very handy indeed, especially when you’re creating a project for someone who doesn’t have Flash, or much in the way of technical knowledge.
Before we move on to frame 2, notice our 3 arrays. These arrays will store the data for our buttons. Once our XML file has been parsed successfully, each array will be filled in with the proper data. This happens in frame 2.
To recap, what was the main purpose of frame 1? If you said, "Global variables", you get a gold star. If not, run down to Starbucks and get some coffee and come back.
The main purpose of frame 2 is to gather external data — typically, literal files in the form of XML. If you haven’t looked at our navigation XML file, this would be a good time to do so. This article is not intended to teach you XML, so just take a look at the structure and what’s in there. We have a total of 4 buttons; each button is assigned an image, some text and a link.
A note to all you non-Flash 8 users: you won’t be able to use a PNG image. You’ll have to use the provided JPEG image and make the changes in the XML file. Previous versions of Flash are only able to load JPEG files.
Now, let’s look at the code in frame 2. I’ll break it down as we go.
var xmlData:XML = new XML();We start by instantiating a new XML object and call it xmlData. The XML object contains all the methods and properties we will need in order to work with XML data in Flash.
xmlData.ignoreWhite = true;Flash will read all spacing contained within the XML file, including empty text nodes. As this is not the desired result, we simply tell Flash to ignore white space.
xmlData.load( xmlFile );This line loads an XML document from the specified URL. Remember, xmlFile was declared in frame 1 and set to "navigation.xml." Because our FLA file resides in the same directory as our XML file, we need only give the name. Had our XML file been located in a directory other than the one that houses our FLA file, we’d have included a relative path.
The load process is asynchronous; it does not finish immediately after the load() method is executed. When the load() method is executed, the XML object property loaded is set to false. When the XML data finishes downloading, the loaded property is set to true, and the onLoad event handler is invoked.
xmlData.onLoad = loadXML;Here we set the onLoad event handler to call our function loadXML. Let’s look at the function:
function loadXML(loaded) {
if (loaded) {
var xnRootNode:XMLNode = this;
trace( xnRootNode );
// number on buttons
nTotalButtons = xnRootNode.firstChild.childNodes.length;
// fill arrays
for (var i = 0; i<nTotalButtons; i++) {
astrImages.push(xnRootNode.firstChild.childNodes[i]
.childNodes[0].firstChild.nodeValue);
astrText.push(xnRootNode.firstChild.childNodes[i]
.childNodes[1].firstChild.nodeValue);
astrLinks.push(xnRootNode.firstChild.childNodes[i]
.childNodes[2].firstChild.nodeValue);
}
//everthing is loaded; we can move on
gotoAndStop(3);
}This function runs only when the XML file has finished downloading and the loaded property is set to true.
If the XML file has completed loading, we execute the following code:
var xnRootNode:XMLNode = this;We create an XML node variable (xnRootNode) and set it equal to this; this being the XML data that was just loaded.
nTotalButtons = xnRootNode.firstChild.childNodes.length;At this point we need to talk about searching our XML to locate the values we need. This is a good time to revisit our navigation XML file.
<nav>
<button>
<image>button1.png</image>
<text>Articles</text>
<link>articles.swf</link>
</button>
<button>
<image>button1.png</image>
<text>Books</text>
<link>books.swf</link>
</button>
<button>
<image>button1.png</image>
<text>Blog</text>
<link>blog.swf</link>
</button>
<button>
<image>button1.png</image>
<text>Contact 'company name' today for a free estimate</text>
<link>forum.swf</link>
</button>
</nav>In order to retrieve values from an XML file, we step through the family tree until you find the desired value. So in our code, xnRootNode.firstChild.childNodes.length;, the first child, is <nav> and it has 4 child nodes — you guessed it, they’re our 4 <button> nodes. So nTotalButtons is now equal to 4.
Next we use a ‘for loop’ to gather all the data from each of our buttons and add it to our arrays.
astrImages.push(xnRootNode.firstChild.childNodes[i]
.childNodes[0].firstChild.nodeValue);astrImagesis our array for images; the push method adds our XML value to this array.xnRootNode.firstChild.childNodes[i].childNodes[0].
firstChild.nodeValue;This may look scary at first, but let's break it down.
xnRootNode.firstChildis<nav>, its first child is the first occurrence of<button>and<button>'s first child is<image>. So far, so good, but what is<image>'s first child? If you said, "button1.png" then pat yourself on the back: that's correct. Even the text value within the node is considered a child node in Flash. Lastly, we use the nodeValue property to retrieve the node value of the XML object, in this case "button1.png." Have a look at the image below, as it may help.
%MINIFYHTMLeec5a1944edf40855f0cf10f3643193a25%We continue to fill in all our arrays, then move on. Only after our XML data has completed loading and has been pushed into our arrays are we ready to move the playhead onward. Now, we move to our next frame.Frame 3
Frame 3 is used to load our CSS file. Have a look at our navigation.css file:.buttonStyle {
font-family: tahoma, verdana, arial, helvetica;
font-size: 16px;
color: #000000;
text-align: center;
}It looks like any other CSS file. We use CSS to set the formatting on our buttons, which just keeps with our paradigm of keeping everything external and dynamic.
Now that our CSS has loaded successfully, let's move on to frame 4.
Frame 4
Before we look at the code for frame 4, let's review. When our Flash file loads, it hits frame 1 and sets all the variables that we will need throughout our site. Next, in frame 2, we gather external data. We got a little bonus and learned how to import XML code which we then parsed and stored in 3 arrays that we'll use in frame 4. In frame 3, we imported the CSS that we'll use in frame 4.
What I want you to notice is that we're at our last frame and, at this point, nothing has been built. Up to this point we've only gathered the data that we'll need. We are now at frame 4, where the playhead will rest indefinitely and our Flash file will take form.
We start by tracing our arrays just to reassure ourselves that we have everything we need. If you're not familiar with the
trace()function, then you won't get far in Flash.Trace()is used to display messages in the Output panel while testing your SWF file. Do a CTRL + ENTER right now and it should pop up the Output panel, displaying the data from our arrays.for (var i = 0; i<nTotalButtons; i++) {
navHolder_mc.createEmptyMovieClip("navButton"+i, i );
// make new MovieClip and set to newly created button
var navButton:MovieClip = navHolder_mc["navButton"+i];
// load images
image_mcl.loadClip( astrImages[i], navButton );
}Recall that
nTotalButtonswas set in frame 2 and is equal to 4 -- the total number of buttons. Also notice thatnavHolder_mcis already on our canvas in thenavHolderlayer.Now, we use a 'for loop' to create our 4 buttons. Within
navHolder_mc, we use thecreateEmptyMovieClip()method to create a movie clip that will hold our buttons.var navButton:MovieClip = navHolder_mc["navButton"+i];This creates a movie clip called
navButtonand sets it equal to your newly created movie clip. This just makes life easier: we can simply refer tonavButton, instead ofnavHolder_mc["navButton"+i], now.image_mcl.loadClip( astrImages[i], navButton );We tell the
loadClip()method to load the button image (from our array) into the newly created movie clip.Now, remember that
image_mclwas defined in frame 1 as a MovieClipLoader, and MovieClipLoader allows us to implement listener callbacks that let us know when our image has completed loading.mclListener.onLoadInit = function(target_mc:MovieClip) {The
onLoadInithandler is invoked after the actions in the first frame of the clip have executed, so you can begin to manipulate the loaded clip. This handler is called after theonLoadCompletehandler. For most purposes, use theonLoadInithandler.At this point, we have a new movie clip for our button with our image loaded into it. Now let's set some properties.
target_mc.linkURL = astrLinks[nCounter];This attaches a variable called 'linkURL' to
target_mcmovie clip;target_mcis automagically set to the object that called this function; in this case it's our movie clip button. Don't believe me? Trace it!Note: 'Automagically' is a technical term for when something happens automatically without you doing anything and you can't really explain how it happens! Feel free to use it around the office -- it will catch on.
Next, we set
linkURLequal to the first link in our array.target_mc.onPress = buttonClick;This attaches the
onPressevent handler to our button. In other words, when the button is clicked, it will call thebuttonClickfunction.var buttonImgHeight:Number = target_mc._height;
var buttonImgWidth:Number = target_mc._width;We define a couple of variables: one stores our button's height, while the other stores its width.
target_mc._y = Math.round( yPosition );
yPosition += buttonImgHeight+3;We move our button's vertical position (y position) down by 3 pixels each time we create a new button.
target_mc.createTextField( "buttonText", nCounter, 0, 0, buttonImgWidth, buttonImgHeight );This creates a new, empty text field within our button movie clip. The
createTextField()method takes 6 parameters:createTextField(instanceName:String, depth:Number, x:Number, y:Number, width:Number, height:Number);Now that we have created a new text field (
buttonText), we're going to assign it a few properties.target_mc.buttonText.border = false;
target_mc.buttonText.selectable = false;
target_mc.buttonText.wordWrap = true;The border property for our text field is currently set to false; however, during development I often set this to true, as it makes positioning things a little easier. In addition, we want our text to wrap, but we don't want it to be selectable.
target_mc.buttonText.styleSheet = my_css;This line assigns our CSS style, which we imported already. Notice the next line:
target_mc.buttonText.htmlText = "<.buttonStyle>"+ astrText[nCounter] +"</.buttonStyle>";Here, you can see how to implement our CSS style. Recall that
.buttonStyleis defined in our external CSS file. Also notice that we're using thehtmlTextproperty -- not just text.target_mc.buttonText.filters = filterArray;This line assigns our filter to the text field. Recall that we created a drop shadow filter back in frame 1. If you don't have Flash 8, you won't be using any filters.
These next few lines of code are pretty cool; they come in very handy when trying to align text vertically.
target_mc.buttonText.autoSize = true;
var nMiddle:Number = ( buttonImgHeight/2 );
target_mc.buttonText._y = nMiddle - ( target_mc.buttonText._height/2 );We first set the
autoSizeproperty of our text field to true. This allows the text field size to match the height and width of the text that's placed in it. Next, we find the middle of our button and store it innMiddle. If we dividebuttonImgHeightby 2, we should find the middle of our button. Now we can set the y position of our text field to be in the middle of our button. To do so, takenMiddleand subtract our text field's height divided by 2.Now we've vertically aligned our text in our buttons dynamically.
nCounter += 1;We increment
nCounterby 1 for each button that's generated.image_mcl.addListener(mclListener);The
addListenermethod attached to our MovieClipLoader object allows it to receive notification when our image is fully loaded.The last bit of code is our button click event handler.
function buttonClick():Void {
trace( this.linkURL );
}This function executes when a button has been pressed. We run a trace on the button's
LinkURLproperty, which we set earlier. If you CTRL + ENTER to pop up the Output panel, then proceed to click some buttons, you should see the associated SWF file displayed in the Output panel.This is as far as we'll go in this article. If we were to continue, the next step would be to load the SWF file using another MovieClipLoader, just as we did earlier for the image files. However, we've now done enough to get the point. What is the point? Well, let's review.
The Big Picture
We've achieved a lot in this article. We've learned how to import XML into Flash, then parse it and store it in arrays. We learned how to import CSS and assign it to text fields to apply formatting. We also have learned how to use the new filter feature in Flash 8 to apply a drop shadow effect. All this is good, but it's not the main point.
What I want you to take away from this article is the way in which we structured our Flash site. Everything that makes up our Flash site resides outside Flash: our external XML file holds the text that's used for the buttons, the image that's used for the buttons, and the link reference for the buttons. Our external CSS file holds formatting information for the buttons.
Keeping everything outside Flash allows our site to be completely dynamic -- we can make changes at any time and not ever have to touch our Flash file. As a bonus, it also keeps our SWF file extremely small and fast loading.
Also, we were in complete control of the Flash playhead the entire time. We moved the Flash playhead to the next frame on our own terms, not Flash's, which can help to avoid a lot of frustration. Many errors are made in Flash because developers allow the playhead to run wild. We never allowed that to happen; we systematically controlled the playhead. Frame 1 set global variables, then we stopped at frame 2, where we loaded in XML data. Once complete, we stopped at frame 3 and loaded CSS data, and on completion, we stop at frame 4 and build our application.
I hope the principles presented in this article will allow you to better structure your next Flash site.
via Comments on:
Ever since Macromedia announced Flex 2 and made available pre-release versions, I’ve been gritting my teeth as more and more cool news has surfaced about what Flex 2 will be capable of.
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.
via Comments on:
Ever since Macromedia announced Flex 2 and made available pre-release versions, I’ve been gritting my teeth as more and more cool news has surfaced about what Flex 2 will be capable of.
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.
via Comments on:
Macromedia’s recently-announced Flex 2.0 platform (see Flex 2.0 announced with more affordable pricing) is now available to download in alpha form from Macromedia’s newly-launched Macromedia Labs site.
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.
via Comments on:
Macromedia’s recently-announced Flex 2.0 platform (see Flex 2.0 announced with more affordable pricing) is now available to download in alpha form from Macromedia’s newly-launched Macromedia Labs site.
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.
via Comments on:
Macromedia today announced Flex 2, a major new release of its framework for building Web applications with rich, client-side Flash interfaces. Earlier this week, I had the opportunity to speak with Macromedia about the details of this upcoming release.
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.
via Comments on:
Macromedia today announced Flex 2, a major new release of its framework for building Web applications with rich, client-side Flash interfaces. Earlier this week, I had the opportunity to speak with Macromedia about the details of this upcoming release.
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.
via Comments on:
Particularly if you installed the beta, but also for vastly improved performance, you’ll want to grab the final version of Flash Player 8 as soon as possible.
via Comments on:
Particularly if you installed the beta, but also for vastly improved performance, you’ll want to grab the final version of Flash Player 8 as soon as possible.
via Comments on:
Thinking about producing a screencast? Will quick and dirty do the trick, as long as it’s free? vnc2swf could be just what you need:
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.
via Comments on:
Thinking about producing a screencast? Will quick and dirty do the trick, as long as it’s free? vnc2swf could be just what you need:
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.
via Comments on:
All the work that’s going into Flash Web applications that look like desktop applications begs the question “Why not just make desktop applications in Flash?” Macromedia tried to answer this with Macromedia Central, which starved for developer adoption and is now given away for free.
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.
via Comments on:
All the work that’s going into Flash Web applications that look like desktop applications begs the question “Why not just make desktop applications in Flash?” Macromedia tried to answer this with Macromedia Central, which starved for developer adoption and is now given away for free.
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.
via Comments on:
Flash smartypants Paul Neave has taken the public APIs of Google Maps and Microsoft Virtual Earth and built his own Flash interface to browse the satellite imagery offered by both of these services. And, may the JavaScript gods forgive me, it’s far smoother and more pleasant to use than either of the services’ respective Web interfaces.
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.
via Comments on:
Flash smartypants Paul Neave has taken the public APIs of Google Maps and Microsoft Virtual Earth and built his own Flash interface to browse the satellite imagery offered by both of these services. And, may the JavaScript gods forgive me, it’s far smoother and more pleasant to use than either of the services’ respective Web interfaces.
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.
via Comments on:
The guys over at Beam Jive have released a major component set for Flash MX 2004 containing over 30 components. Whilst the set is a commercial component set, it’s only 80 Euros, and they are fantastic to say the least
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!
via Comments on: