I've been having some interesting debates with other web developers and some self-proclaimed SEO gurus about a new Flash accessibility programming method that we just blogged about: http://labs.blitzagency.com/?p=171
The title of the blog post is Search Engine Optimization for Flash Websites because well, lets face it, that title attracts more eyeballs than "Flash website accessibility".
I've read the Google webmaster guidelines cover to cover, and I believe that what we are doing does not go against Google's recommendations, but I 'd love to hear other peoples opinions -- especially Google's own!
What we are doing is in the true spirit of good web development -- separation of content, presentation, and behavior. By doing so, it allows is to make our Flash websites much more accessible to those without the Flash plugin, and the 10-million plus vision impaired (in the US alone). We believe that by making a site accessible, it also makes it search engine friendly, and that's not a bad thing. None of the techniques or text we are using are designed in such a way as to trick or deceive the spiders. The text on the page == the text in the Flash movie. We are simply exposing the same separated content to everyone.
I was just reading the post "Best uses of Flash" over on the Official Google Webmaster Central Blog, and it reminded me of this earlier post. Any responses from Google insiders would certainly be appreciated.
> I've been having some interesting debates with other web developers > and some self-proclaimed SEO gurus about a new Flash accessibility > programming method that we just blogged about:http://labs.blitzagency.com/?p=171
> The title of the blog post is Search Engine Optimization for Flash > Websites because well, lets face it, that title attracts more eyeballs > than "Flash website accessibility".
> I've read the Google webmaster guidelines cover to cover, and I > believe that what we are doing does not go against Google's > recommendations, but I 'd love to hear other peoples opinions -- > especially Google's own!
> What we are doing is in the true spirit of good web development -- > separation of content, presentation, and behavior. By doing so, it > allows is to make our Flash websites much more accessible to those > without the Flash plugin, and the 10-million plus vision impaired (in > the US alone). We believe that by making a site accessible, it also > makes it search engine friendly, and that's not a bad thing. None of > the techniques or text we are using are designed in such a way as to > trick or deceive the spiders. The text on the page == the text in the > Flash movie. We are simply exposing the same separated content to > everyone.
> I was just reading the post "Best uses of Flash" over on the Official > Google Webmaster Central Blog, and it reminded me of this earlier > post. Any responses from Google insiders would certainly be > appreciated.
> On Jun 13, 12:09 pm, Jason Grunstra wrote:
> > I've been having some interesting debates with other web developers > > and some self-proclaimed SEO gurus about a new Flash accessibility > > programming method that we just blogged about:http://labs.blitzagency.com/?p=171
> > The title of the blog post is Search Engine Optimization for Flash > > Websites because well, lets face it, that title attracts more eyeballs > > than "Flash website accessibility".
> > I've read the Google webmaster guidelines cover to cover, and I > > believe that what we are doing does not go against Google's > > recommendations, but I 'd love to hear other peoples opinions -- > > especially Google's own!
> > What we are doing is in the true spirit of good web development -- > > separation of content, presentation, and behavior. By doing so, it > > allows is to make our Flash websites much more accessible to those > > without the Flash plugin, and the 10-million plus vision impaired (in > > the US alone). We believe that by making a site accessible, it also > > makes it search engine friendly, and that's not a bad thing. None of > > the techniques or text we are using are designed in such a way as to > > trick or deceive the spiders. The text on the page == the text in the > > Flash movie. We are simply exposing the same separated content to > > everyone.
I don't know if Google or anyone else for that matter could be any more clear.
So, until these issues are fixed I wouldn't expect an answer from Google. So far, I see no optimized Flash only hidden html. For more information, check out "Prioritizing Web Usability" by Jakob Nielsen: http://www.useit.com/prioritizing/
> Either way, the site in question is still returning one set of URLs to > the search engines and another to users and that is called cloaking.
+ That's just for deep-linking, google wouldn't be able test query strings mixed with flash anyways.
> - The ALT attribute provides "alternative" content and not the DIV > Content in the DIV is hidden from users.
+ So what if he placed a plainly viewable button (on each page) that could display the text that the flash is in front of (maybe hide the Flash Object)? He couldn't be accused of anything then.
> - As you can see Google suggests sIFR and not swfobject!
> I don't know if Google or anyone else for that matter could be any > more clear.
> So, until these issues are fixed I wouldn't expect an answer from > Google. So far, I see no optimized Flash only hidden html. For more > information, check out "Prioritizing Web Usability" by Jakob Nielsen:http://www.useit.com/prioritizing/
> On Jul 9, 2:32 pm, MrGamma wrote:
> > Honestly... it's all possible with javascript... javascript has the > > unique abilty to remain backwards compatible too...
> > Why encapsulate everything... when you can connect with everyone?
beussery, I think you're mistaken. It doesn't return a different set of URLs at all. It's the same exact URL no matter what type of user views the page. Furthermore it's the same content as well. There is no cloaking at all, and there is no attempt being made to send different content to different clients.
The only difference is that the URL has data after the hash/anchor, which is used for to tell Flash what page the user is viewing and consequently allows you to send a deep-linked page to a friend, or to bookmark it. This is no different than query string parameters.
Again, it's about giving the users the same user experience that they come to expect in their web browser from a non-Flash site.
And just to reiterate with pittsburgh_joe said "How is sIFR different from SWFObject?"
The page you linked to talking about sIFR has this to say:
A technique like sIFR still lets non-Flash readers read a page, since the content/navigation is actually in the HTML -- it's just displayed by an embedded Flash object
That is _PRECISELY_ what our method is doing. No more, no less. I'm not sure how you can see it any other way.
And you're right, I was talking about searchenginewatch, but that thread was locked, so I came here to have an open and honest discussion with the development community without the need to worry about censorship.
> I don't know if Google or anyone else for that matter could be any > more clear.
> So, until these issues are fixed I wouldn't expect an answer from > Google. So far, I see no optimized Flash only hidden html. For more > information, check out "Prioritizing Web Usability" by Jakob Nielsen:http://www.useit.com/prioritizing/
> On Jul 9, 2:32 pm, MrGamma wrote:
> > Honestly... it's all possible with javascript... javascript has the > > unique abilty to remain backwards compatible too...
> > Why encapsulate everything... when you can connect with everyone?
Actually sIFR only alters the font that is seen by the user. Search engines don't see fonts. They see text.
>From the sIFR site on how it works:
1. A normal (X)HTML page is loaded into the browser. 2. A javascript function is run which first checks that Flash is installed and then looks for whatever tags, ids, or classes you designate. 3. If Flash isn't installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you've designated as something you'd like "sIFRed". 4. Once measured, the script creates Flash movies of the same dimensions and overlays them on top of the original elements, pumping the original browser text in as a Flash variable. 5. Actionscript inside of each Flash file then draws that text in your chosen typeface at a 6 point size and scales it up until it fits snugly inside the Flash movie.
So sIFR uses the _DATA_ in an (X)HTML tag to inject that data into Flash, which then displays that SAME EXACT DATA in Flash.
How is that any different than using (X)HTML data as a data source for an entire Flash website?
SWFObject input: <h1>Hello World!</h1><p>This is my website.</ p><p>Thanks for visiting.</p> SWFObject Flash output: Hello World! This is my website. Thanks for visiting.
So you see, they really are no different.
I could easily write some javascript to pass the innerHTML of my pages main div element into the Flash as a parameter which would then use that XML (XHTML == XML) to render the content in Flash. But it would just be an unnecessary step since that same content is already being pulled in by Flash.
In fact, if one were to take the argument "of showing exactly the same to everyone" literally, one could even argue that Flash would be the preferred rendering environment for all data. This based on the grounds that every browser renders HTML a little different (and very different from how Google sees it), whereas Flash renders the data identical in all browsers/systems.
So to me, this is basically a discussion about the definition of data, and to some degree - about the double standards that exists around data-delivery. Is it not so that search engines already accept parallel data-sources, for instance from RSS-feeds? Google even encourage webmasters to prepare separate sitemap-data structured in a single XML-file. This is surely parallel/duplicate data, often stripped and optimized, and nowhere near how the full page-view renders out in a browser. The reason it's ok, is because it comes from the same data-source - and this is exactly what Flash-developers have been doing for a long time now.
We've been using techniques like this since the late 90's for most our Flash-work, and long before any Google webmaster guidelines entered the stage. I did a demo back in 2004 on these concepts, at a new media seminar at The University of Oslo: http://lillestroem.uio.no/intermedia/dd/10.mp4 (scrub halfway into the stream to get to where I'm showing it). The site I'm demoing dates back to 2001/2002.
> Actually sIFR only alters the font that is seen by the user. Search > engines don't see fonts. They see text.
> >From the sIFR site on how it works:
> 1. A normal (X)HTML page is loaded into the browser. > 2. A javascript function is run which first checks that Flash is > installed and then looks for whatever tags, ids, or classes you > designate. > 3. If Flash isn't installed (or obviously if javascript is turned > off), the (X)HTML page displays as normal and nothing further occurs. > If Flash is installed, javascript traverses through the source of your > page measuring each element you've designated as something you'd like > "sIFRed". > 4. Once measured, the script creates Flash movies of the same > dimensions and overlays them on top of the original elements, pumping > the original browser text in as a Flash variable. > 5. Actionscript inside of each Flash file then draws that text in > your chosen typeface at a 6 point size and scales it up until it fits > snugly inside the Flash movie.
> So sIFR uses the _DATA_ in an (X)HTML tag to inject that data into > Flash, which then displays that SAME EXACT DATA in Flash.
> How is that any different than using (X)HTML data as a data source for > an entire Flash website?
> SWFObject input: <h1>Hello World!</h1><p>This is my website.</ > p><p>Thanks for visiting.</p> > SWFObject Flash output: Hello World! This is my website. Thanks for > visiting.
> So you see, they really are no different.
> I could easily write some javascript to pass the innerHTML of my pages > main div element into the Flash as a parameter which would then use > that XML (XHTML == XML) to render the content in Flash. But it would > just be an unnecessary step since that same content is already being > pulled in by Flash.
> > sIFR alters the font of text seen by both the search engine and the > > user. SWFObject uses the DIV to hide text from users with Flash.- Hide quoted text -
