hank williams wrote: > Kevin, > > I had a few inline comments on some of what you wrote since I had a > few differences of opinion. > > On 12/18/06, *Kevin Newman* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I think that's great and don't necessarily think Adobe needs to > fix the > problem, since I don't think it's Adobe's problem - I like the > flexibility. > > > I think its definitely adobe's problem to the extent that they offer > products that are client/server systems instead of just client tools. > FDS and Cold Fusion should offer a way to facilitate this most > important of issues. Adobe has defined a significant part of its > business as building servers in the flash ecosystem. I dont think > solving this issue would limit any flexibility. You are right about FDS and Cold Fusion servers - it should be possible for Adobe to create some kind of tools or solutions, even if it isn't hands off - but for the rest of us, and overview or best practices document would be nice.
> > This is a problem for Google and others, to fix, or perhaps one that > there is already a solution for. > > > I dont see why this would be googles issue really at all. More on this > below. > > The problem with Flex/Flash/AJAX/Expression Blend apps, is that > they are > not documents, they are applications. > > > > Actually, many such apps are *both* apps and documents and that is > where the problem is. For example a discussion board is an app that > manages and displays document type data that deserves to be indexed. I guess it could be, but mixing it like that seems odd to me. > > How would Google or anyone else > index something like Microsoft Word, or Adobe Photoshop. > > > > You correctly point out that these do not make sense for indexing, but > these are not the kinds of apps that we are talking about for user > generated content or webapps that have significant indexable data. I guess I see Flex/Ajax/Flash/etc. apps more like extension to the browser, than as "web sites" or content. To me they just extend the way the browser app access and displays information. > > > > To me the answer is as Claus suggests - to build an alternative, > server > side web app, that serves the documents to spiders and bots (BTW, this > can be produced before or after the UI - it's up to the developer > ;-) ). > > The interesting question, and the place that needs focus, is what > is the > right way to direct traffic from those search pages back into the web > app. > > > This it seems is not that interesting a question because it is the > easy part. Flash/Flex apps can easily read data in the URL and go to > the right place in the app which can then use remoting to get the data > in the right format for the app. Yeah, but it has to run to do that, and then the displayed data has to be interpretable by the bot - if that can be standardized enough for a spider to understand what it's got back from the server (maybe an event system that says "hey I'm ready to be indexed", or "read me now" - screen readers have to be able to do this, so I guess it might be possible), that's great, but I don't know if spiders will be that smart, or if companies like google would be willing to build such a bot that can run apps like that. I suppose it would be more ideal than two different types of links into the app (hash # and query ?). Of course the bot would still need to know how to crawl the site (where to get urls) - I guess sitemaps.org could come in handy here. A smart enough bot wouldn't even have to reload the app (if the app don't break at least). > > I think the easiest way to do that would be with a small snippet of > JavaScript that would detect for Flash Player (or whatever the app > requires) then location.replace you into the appropriate location > within > the application (which would need deep linking support, and there many > ways to do that now). > > > This, it seems to me is more complicated than necessary. I do this in > my current app without any javascript snippet (cuz I dont know jack > abou js!). I just read the parameter from the application object go to > the right place in my app and load the appropriate data from the server. Do you do this after the page loads, or when the app is requested? > > What's needed now is a concrete example to follow, or a set of > patterns > or standards, or whatever, that will ease the development of this > second > view of your app's content. > > > I think the server side code to do this is more than just a standard. > I think we need an entry point on the current adobe remoting products > for adding XML to the HTML response of a url with addition field or > query information. For Adobe's products, a tool that would help developers build something like that into their content systems, would be useful. > > It would be nice if Google and Adobe (and whoever else) could get > together and figure out what these standards/patterns should look > like, > but there's no reason the development community can't get this figured > out. :-) > > > > I dont think google needs to do much here. If we can get the server > product to easily allow XML to enhance the HTML response then googles > indexing will just work. I'd love to see this work in a concrete example. ;-) Kevin N.
