So the big news in the Flash development world is Google's latest announcement that they have improved their indexing of Adobe Flash files. But what exactly does this mean to developers?

Google has been indexing Flash since 2004

Well, the news isn't exactly as groundbreaking as some first thought. For starters, Google has already been indexing flash files since 2004. Google's spiders have been able to view any static text information since shortly after Macromedia released their Flash Search Engine SDK. The difference with this latest update is that Google's mystical little crawlers can now access dynamic text as well as recognize URLs in that text.

Because it deals with their algorithms, Google is very close mouthed about the specifics of this change. But of the three technical limitations they (Ron Adler, Janis Stipins, and Maile Ohye) cite, two of them stand out conspicuously.

1. 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.

2. 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.

No JavaScript?

The first isn't too bad at first blush, but it raises quite a few questions. Best practices for embedding Flash has involved the use of JavaScript for years now. Most developers use scripts like SWFObject to do the dirty work and take care of IE's old problem with Eolas and the ActiveX warning. So does using this method cancel out Google's new ability? Or would a simple noscript tag be good enough for their bots? And what about libraries like SWFAddress? Which would you choose between, having Flash indexed in this new way, or deep linking, bookmarking, and analytical functionality?

Dynamic without being flexible

The second caveat is much bigger and makes the new indexing possibly pointless, some would say worse than pointless. What is the point of dynamic text if you can't load dynamic data? And does "external sources" cover Json and other text files? How about Remote Objects? Google simply doesn't tell us enough.

What's more, as some of the anti-Flash crowd (I'm looking at you Reddit) have pointed out, is that this might encourage old, bad habits. If keeping your data separate from your presentation loses out to SEO, than the myth that Flash pieces aren't maintainable starts to become true.

And then there's this point:

At present, we are only discovering and indexing textual content in Flash files. If your Flash files only include images, we will not recognize or index any text that may appear in those images. Similarly, we do not generate any anchor text for Flash buttons which target some URL, but which have no associated text.

So does this mean that URLs appearing within the Flash are only indexable if they are spelled out explicitly, or that they need to be labelled? Once again, we simply don't have enough information.

A step towards a more open Flash player

But for me, whether this proves to be a boon or a bust, the big news isn't Google's update, but the change at Adobe that instigated it. In yet another step that may eventually lead down the garden path of an open source Flash player, Adobe opened up the player up to Google and Yahoo in order to facilitate this change.

Adobe has provided Flash Player technology to Google and Yahoo! that allows their search spiders to navigate through a live SWF application as if they were virtual users. The Flash Player technology, optimized for search spiders, runs a SWF file similarly to how the file would run in Adobe Flash Player in the browser, yet it returns all of the text and links that occur at any state of the application back to the search spider, which then appears in search results to the end user.

More to come

And here's the kicker. This is just the start:

We are initially working with Google and Yahoo! to significantly improve search of this rich content on the web, and we intend to broaden the availability of this capability to benefit all content publishers, developers, and end users.

I'm not sure how far behind the curtain Adobe will eventually let us look, but they're not through just yet. Until they do, we're very much in the dark regarding the specifics of Flash's new searchability. If I can find the time, I intend on doing a little experimenting to try and fill in some of the blanks that Google left out. I'll post my results if I do.

But what does this mean for marketers

The jury is still out on exactly how this affects web strategy. There's simply not enough information available to make a judgement call. In the meantime, Flash implementations that were a bad idea yesterday because of SEO, should still be treated like a bad idea today.

 

 

Some recent discussions have gotten me thinking about what is and isn't a good use of Flash. I thought I might illustrate what isn't a good use of Flash, as it's a bit easier to nail down. Mind you, some of these "rules" aren't specific to Flash. Some of them are just basic usability and UI. Without further ado, I give you the Flash Commandments:

Thou Shalt Not Get Between The User and Content

Yeah, you with the splash page - I'm looking at you. If you're trying to decide whether to give the user the option to skip anything on your site, you probably need to rethink whether to even have that element at all (Actually, this day and age you should be rethinking your career while your at it). It's obviously not necessary; otherwise why give the user the option to pass by it. Users come to a site to buy products, gather information, and enjoy content. Don't stand in their way. Don't waste their time. That one extra click you put in front of them could be the one that broke the camel's back and sent them back to the search page to look for a site that will give them what they want in a more straight forward way.

Google is Thy Search Engine, Thou Shalt Not Have Navigation Without Keeping It In Mind

Google might know and record the sordid details of your browsing history, but it can't read the contents of your swf. Flash navigation is usually a bad idea. If for some reason you find a good excuse for Flash navigation be smart about it. You can write your navigation as a bulleted list in standard html for instance, just like Google's mysterious algorithms supposedly like it. Then you can parse the navigation data and send  it to Flash via JavaScript, using a tehnique similiar to Mike Davidson's sIFR. This way the user gets the rich Flash experience and Google's spiders get exactly what they're looking for. You'll still want to make sure it degrades gracefully in case the user doesn't have Flash or JavaScript. You'll also want to offer the user the right-click functionality there are used to via Flash's context menu.

Thou Shalt Not Embarass The User

No one wants to unexpectedly announce what page they're looking at to the entire office or library. Don't surprise the user with blasts of sound. Allow the user to choose to hear your content, either with a volume control set automatically to mute, or by requiring them to actively choose to play your content. Exceptions can of course be made, especially in cases like children's sites, but always weigh the consequences. You can never know what type of sound output the user has. "Welcoming" users with loud, blaring noise will see your bounce rate skyrocket.

Honor Thy Father and Mother

This one is a general rule of thumb for all UI, but since Flash developers seem to be more guilty than most about breaking it, I've included it here. Designing a creative and fresh user interface is great, but before you start congratulating yourself for thinking so far outside the box, ask ol' Mom and Dad to give it a spin. Any user interface you design will always be intuitive to you - it better be, you made it. But even if you haven't personally designed it, as someone who lives and breathes the web you're full of thousands of UI assumptions that the average and not-so-average user simply won't see. That's why it's a good idea to sit down with the people that will actually be using your application. Sure, it might be frustrating. But it's even more frustrating to be made to feel dumb and useless by some designer or developer's poorly thought out UI. If the user can't figure out your UI, it's never their fault. It's yours. You're the one that wants them to use your application, after all.

Thou Shalt Take Advantage of Thy Medium

This is the sin of which the now infamous Dilbert.com is most glaringly guilty. For those who don't know, Dilbert raised the ire of the geek-o-sphere when they "updated" their simple and usable UI to a Flash-based kludge. In their example, what reason was there for using Flash that could not have been better filled by other technologies? The developer did not even taken advantage of the most basic of Flash benefits, the stateful nature of the framework. The entire page is reloaded when the user requests the next or previous strip. What's more, the strip is loaded twice each time. First a static .gif is loaded, then the container swf, which then requests the image again. Judging by the load time, the image doesn't appear to cache. So not only is there no benefit gained from choosing Flash, it's actually to the detriment of the experience. The only "advantage" of using Flash that I can see is some over-the-top rollover animations, that I personally find more distracting than engaging. The moral of the story is, use the right tool for the right job. Don't use Flash unless there's a reason to use Flash.

Thou Shalt Separate Thy Content From Thy Presentation

While this rule is obvious to other types of developers, I've met far too many Flash "developers" that don't understand this basic concept. The all too popular notion that Flash pieces are hard to maintain has nothing to do with Flash's capabilities, and everything to do with individual developer and designers' implementations. Arguably, Flash content can be the most dynamic content on the web. Flash can take a great variety of data and asset formats and display them in endless ways. The only limits are the imagination and the laziness of the person building the application. Yet, Flash's reputation as an unmaintainable platform persists thanks largely to designers masquerading as developers. If you're going to call yourself a developer, start acting like one. Keep your data elsewhere, be it images, text, path names, whatever. Over the long run, the major cost of applications isn't in their initial development, but in their maintenance. If you do your job right, you shouldn't ever have to open your authoring files after the project has been delivered.

I'm now finished my first official project using Papervision. Even though there's been the expected learning curve while learning a new library, the project went smoothly. Prototyping and concepting were a breeze. I hit all my deadlines and milestones, with time to spare. The entire project schedule, I compiled, viewed the piece in Firefox, and saw something like this:

So you can imagine my surprise and dismay when, on a Friday afternoon a little before launch, we moved it over to the dev server and the page where it would live and saw this:

Now I've seen some weird behavior between browsers, but never anything like that - and especially not in Flash!

Then things started to get really strange. Trying to get some insight on what might have happened, I decided to check it out in Safari for the Mac. I soon wished I hadn't...

So, after I had a wee little cry, I started combing the Papervision forum over at Nabble. But no one had ever run into a similar problem. The basic gist behind the magic of Papervision - and most 3D libraries for that matter - is that it takes bitmaps and skews them along an imaginary surface using a matrix. I had the cubes in my pieces separated into 12 of these surfaces, two for each side. The first issue was clearly showing a gap where these surfaces were suppose to meet seamlessly, and the second was doing the opposite, only showing the content on the edges themselves. 

Panic was just starting to set in when Pavel, my partner in crime and Pivot and Levy's resident server-side guru, found something. When he changed the background color of the div where the second issue was occurring to black, the issue went away.

"Ok, it's a transparency issue. Now, where have I run into the most issues with transparency?" I said. "Hmm, I bet it's that pesky little attribute, wmode." I replied. Sure enough, I had copied and pasted a embed tag that had declared the wmode as transparent. So, I figured I'd just set it to the default and go about my weekend.

"Not so fast!" said Mr. wmode. That merely balanced out the rendering problem between browsers. Safari now had the milder, although still debilitating, first issue, instead of the mind-blowingly horrific second one. And Firefox and IE now always had it, no matter what color the background. It was progress, at least. Although at the time I didn't know in which direction

So I cried some more. But then I ran through my code some more as well, looked over every object and property, trying to find anything that might affect transparency. I paused over the MovieMaterial objects that I used to take the Flex components behind the app and populate them to surfaces of the cubes. One of the properties of the MovieMaterial Class is "transparency", but I had it set to false. After all, the surfaces of my cubes didn't need transparency, so why ask the player to try and render different opacities. But I was desperate, the same kind of desperate the makes you look for your keys in the freezer, so I switched it to true and pressed the Run button. 

Bam! Eureka! Bug fixed.

There are two morals to this story. One, even cocky Flash developers need to check their apps in other browsers. And two, always set your MovieMaterial to transparent when using the Papervision3D library.