Skip navigation

it has become (at least for me) somewhat easy to share information within flash sites with engines. this article is directed to the ones who know what they are doing within the flash platform, touches some issues that where a menace in the early days.

object and embed tags are way outdated, but it’s still used for easy inserting flash apps into pages. either way if you are developer you should know by now that the easy way usually doesn’t work.

there is no search engine and never will be that can read inside dynamically loaded content by flash, and it’s not a good practice to embed all the content into a flash site because you might end up withe a flash file bigger then the moon. they are not reading it because the request and the data is made to travel from and to the server and flash player (and bits and pieces of the browser). on the behalf of the engine programmers it’s an almost impossible task to create a way to index data normally loaded by a flash application.

search engines where made to crawl trough html. they have their own way of requesting all the information that is referenced via links on a page. exposing those links and content is the key to making a flash site fully SEO compatible.

it is necessary at this point to have a content management system or framework capable of returning two types of data (you can simulate it manually if the site is not that big, exempli gratia 3-4 pages). even the most crazy flash site can be tiled into some sort of sections or pages. from those pages you can construct a sitemap.

the site map should be fixed and put down with as much care as possible. there is a very real potential for ramifications if the site map does not reflect the strategy of the site. the next step should be the creation of some sort of algorithm that reinforces that particular sitemap. some thing of a class that loads the pages and initializes them completely or partially separate way. is like, if you want to load a product page, the app does not display or wait for the homepage to load before loading the actual requested page. the good thing is that you can base your navigation inside the site on this.

the next step should be the creation of a html document set with links towards each other reflecting the initial sitemap. the container tag will then be replaced with the actual swf. within this tag is where your html alternative comes. when the replace is not possible (i.e. no flash) then this content will remain visible. the html pages should contain the same data as the flash “pages”. while each html page is representing a page in the flash site, you can parse an identifier via flashVars to the flash movie and force it to load the page consistent with the content in the current html. i am using swfObject, it’s a very str8 forward little script. this basically replaces a target tag, identified by the “id” property, with the embed or object tags containing the shockwave flash object.

it’s just more natural to have the SE bots read plain html. the other advantage is that with a bit of styling the content could also serve as an alternate site for devices incapable of running flash.

and, yes, you have to forget the noembed and noscript tags. at this point the become completely obsolete. noscript might still have a use but frankly, i don’t give a damn about people running browsers with js turned off. the age of paranoia is over. the only browser with somewhat founded risks whould be IE but that too has become secure enough.

if you haven’t done it already you should link the content from your DBs to the html pages. probably i failed to mention that working with embedded content on a full flash site is a shameful fail. the only thing you should embed are fonts and some graphics for the UI.

now you have to create a little java script for the to handle fragment ids (the stuff after the “#”). that: if the fragment changes then calls a registered function of the flash (ExternalInterface.addCallback()) that forces the page defined by the fragment to load. now you set up your flash to change the url fragment (navigateToUrl()) each time a page is loaded or displayed (you might want to rig it parallel to the external callback and implement a test if the page is already displayed then just do nothing, parallel because AS3 is a few hundred times faster the JS + communication between the 2). now if you use the step buttons on the browser, it should cycle trough the urls with the fragments you have visited without reloading the whole app (except safari, it reloads the entire page, but it also works).

2B continued with code examples.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: