Flash se ha hecho mayor
Creo que -¡por fin!- ha llegado el momento de poder decir bien alto que FLASH/ACTIONSCRIPT ya no tiene nada que envidiar a HTML/JAVASCRIPT/AJAX.
Bajo mi punto de vista se ha dado el paso definitivo con la aparición de SWFAddress. Ya que, con esta clase actionscript, y con la programación javascript y php que incorpora, se consigue que en una página web programada íntegramente en flash/actionscript los contenidos sean totalmente accesibles para buscadores (SEO).
Además, también aporta otras funcionalidades como:<ul>- cambiar el título y la url de la ventana del navegador para cada nueva sección o contenido,
- que los botones de back y forward del navegador funcionen,
- que los diferentes usuarios puedan acceder directamente a una sección escribiendo su url. [/list:u:c4b7247bed] Si a esto le añadimos, que el "contenedor html" (object/embed) que contiene el SWF no tiene porque tener una altura prefijada, sino que fácilmente (más información) podemos hacer que se vaya cambiando en función del tamaño de los contenidos que tenga que mostrar en ese momento. Conseguimos que ya no se tenga que utilizar los poco usables scrolls de página hechos en flash, sino que se pueda utilizar el scroll propio del navegador.
Y finalmente también añadimos las clásicas ventajas que ya tiene flash/actionscript en cuanto a:
[list:c4b7247bed]- no tener problemas con diferentes navegadores,
- tener la posibilidad de incorporar cualquier tipografía y con buena legibilidad,
- subir archivos al servidor,
- poder gestionar los procesos de carga (de contenidos de texto, imágenes, peticiones a servidor,...),
- posibilidad de hacer peticiones a servidor sin tener que recargar toda la página (como AJAX),
- capacidad de crear de forma sencilla contenidos interactivos,
- capacidad de visualización a -verdadero- fullscreen.</ul> Obtenemos finalmente un "framework" muy interesante, que para muchos proyectos puede resultar muy atractivo. Y que, bajo mi punto de vista, ningún programador web serio puede descartar de buenas a primeras.
Eso sí, todavía creo que tiene un problema, ya que no deja de ser una tecnología desarrollada con un software propiedad de Adobe. Aunque esto esperemos que a la larga también se consiga solucionar.
Ejemplos de sites que incorporan algunas de estas nuevas funcionalidades:
http://www.nikeskateboarding.com/ (seo + flash_resize)
http://kashiwasato.com/ (seo)
http://nike.com/jumpman23/m4/ (fullscreen + 3d)
Espero vuestras opiniones.
almostdesign
Supongo que una web como la que comentáis funcionaría así:
-Existe un xml de la cual tiran 2 webs, una en flash y otra en php.
-Mediante SWFOjbect hacemos que la versión flash se cargue sobre la versión php, ocultándola.
-La versión php lee, en servidor, un xml y manda al cliente un html. Éste html indexa determinadas fotos.
-La versión flash se carga en cliente, luego lee el xml y, según los datos de éste, carga determinadas fotos.
En ambos casos las "determinadas fotos" serían las mismas, con lo cual lo único que se cargaría por duplicado sería el archivo/s flash (swf) y el html proporcionado por php.
En el caso que comenta xavi si sería un problema, puesto que tiene que cargar un xml muy pesado, pero probablemente sería correcto para una web donde el grueso de kbs sean las fotos.
xavib
Estamos trabajando en una producción flash en la que el diseño de partida no tiene en cuenta en absoluto estos aspectos (y misteriosamente al cliente le importa un comino) pero cuando hablamos de SEO, flash y optimizar tiempos uno acaba tratando flash prácticamente como si fuera HTML.
Dices que esos KB no llegan al navegador... quizá recibes el resultado generado de la consulta pero esa consulta supone el envío de unos datos que tienen un peso y que suponen una transferencia.
En el asunto que tenemos entre teclas nos encontramos ante la duda de cargar del tirón el XML de productos (es el archivo más relevante, de algo más de 1MB) o ir cargando bajo demanda (hay puntos en los que se muestran 30 productos) y tras unas cuantas pruebas lo más óptimo fué lo primero, por evitar carga de proceso en el servidor y por tiempo de espera.
Por eso entiendo que hacer la consulta desde 2 sitios supone doble transferencia... si a eso le sumamos 2 veces la misma imagen, etc. es algo que en algunos casos hay que tener en cuenta.
Lo que no sé es hasta qué punto nos ayuda la caché del navegador, pero en la próxima producción tendremos que duplicar contenido así que usaremos un proxy o algo así para ver cómo respira.
Por lo demás, estoy por escribir a Google para ver qué pasa con el doble contenido y hasta qué punto lo consideran abuse.
juandelgado
xavib
si haciendo una lectura a un XML desde php y desde flash a la vez ese XML se carga una o más veces.
La diferencia aquí es que cuando lo lees con PHP, esos kb no llegan al navegador. Otra cosa es que para mostrar una web HTML y Flash tengas que leer el XML 2 veces con PHP, una para mostrar un xml para Flash y otra para mostrar la parte HTML.
Yo creo que la mejor opción serían plantillas XSLT en el cliente, pero eso tiene sus problemas (diferencias entre navegadores, por ejemplo).
Como bien dices, a una web pequeña no le afecta prácticamente. Yo estoy por terminar una web así y no lo tengo especialmente optimizado.
Salud
xavib
almostDesign
Esto me interesa mucho. A ver si alguien sabe sobre el tema.
Me apunto. Precisamente estos dias estoy yo documentándome sobre estos asuntos y todo lo que Google (y su sistema de relevancia) devuelve es de 2005 y 2006.
Hasta qué punto está cambiando esto? Realmente el riesgo es poco?
Luego, una vez superado el poder mostrar diferentes páginas con diferente contenido sin tener que hacer esperar mucho al usuario... cómo se soluciona el doble contenido cuando hay carga gráfica o de datos "considerable"? No significa duplicar el tráfico? De alguna forma me parece poco óptimo, pero realmente no sé como funcionan los entresijos de los protocolos y los navegadores como para saber realmente si haciendo una lectura a un XML desde php y desde flash a la vez ese XML se carga una o más veces.
Quizá es un poco extremo y en realidad para un cliente mindundi no hay problema, pero para el que se está comiendo 200GB de transferencia significa mucha diferencia.
Que suba el post! ^_^
athomix
TXOPEone
y una pregunta....
Google no considera páginas 'doorway', todas las webs generadas por detrás para ser leídas por los bots?
Si esto es así, no quedarían estas páginas en flash penalizadas? o ya no es así.
Saludos.
Me parece que un buscador va a tratar la indexación una página html con flash o javascript de la misma manera que cualquier otra sin. Osease, creo que no las trata ni como doorway ni como cloaking a no ser que tengan todos los números de serlo.
Aunque no se hasta que punto, hay ciertas partes del código y resultado de una página que podría comprender y comparar haciendo un poco de datamining.
almostdesign
TXOPEone
y una pregunta....
Google no considera páginas 'doorway', todas las webs generadas por detrás para ser leídas por los bots?
Si esto es así, no quedarían estas páginas en flash penalizadas? o ya no es así.
Saludos.
Esto me interesa mucho. A ver si alguien sabe sobre el tema.
guille
Yo creo que no. En los proyectos que he hecho, no ha habido problema.
Por ejemplo, mira la indexación en Google del último proyecto que hice: site:www.annasodupe.com
Quizás alguien con más experiencia y conocimientos en este tema nos puede explicar mejor por qué es así.
txopeone
y una pregunta....
Google no considera páginas 'doorway', todas las webs generadas por detrás para ser leídas por los bots?
Si esto es así, no quedarían estas páginas en flash penalizadas? o ya no es así.
Saludos.
guille
Gracias Ernieb por el comentario.
Y sí, si que la podría haber hecho en XHTML. Pero yo tengo el problema, o la ventaja, que desarrollo mucho más rápido en actionscript (porque todo está programado) que no en XHTML. Me resulta más sencillo de montar y además me permite ciertos acabados/interactividades que con XHTML creo que no son fáciles de conseguir.
ernieb
Guille, enhorabuena ya que encuentro una web muy limpia y bien realizada. Y desde luego, es muy acertado el haberla realizado "tal y como la has planteado".
Sin embargo, una cosa que si que veo es que esta web podria haberse hecho en XHTML, ¿no? Vamos, que tal vez en este caso el empleo de Flash es un poco gratuito (desde mi punto de vista al menos).
No se que opinaras...
De todas formas, lo dicho: buen trabajo.
guille
Buena, parece que ahora si que ya funciona la web: http://www.annasodupe.com
almostdesign
Isma
<div class="quote">
almostDesign
<blockquote>
De todos modos, me gustaría preguntarte algo. ¿Qué tecnología has utilizado para convertir los datos del xml a html?</blockquote>
</div>
Si te puedo responder yo...
Con SimpleXML de PHP puedes hacerlo. Simplemente en otra capa haces la llamada a una función que te hayas creado para leer el XML y mostrar el contenido un poco bien presentado. Yo lo suelo hacer mediante 'heads', listas y anclas, lo más accesible posible.
Preguntaba porque hay varias maneras de hacerlo...
Yo en mi web lo tengo hecho mediante XSLT, pero no se si eso es lo más correcto (la hoja de estilo xslt se aplica en servidor mediante php).
ozke
Athomix
Si HTML no ha desaparecido es gracias a CSS, JS y porque no, gracias a Flash.....
Hostias, he cazado esta frase "escaneando" el post y me he quedado lelo.
Q leches usamos si desaparece HTML? Texto a piñón?
Asciiart al ataque!
guille
Eso es. Yo también lo hago así.
Es muy sencillo leer XML con PHP. Lo único que hay que vigilar es qué version de PHP se tiene instalado en el servidor.
Además, al estar todo ejecutandose en el servidor, no existe carga y el tiempo de lectura es muy rápido.
isma
almostDesign
De todos modos, me gustaría preguntarte algo. ¿Qué tecnología has utilizado para convertir los datos del xml a html?
Si te puedo responder yo...
Con SimpleXML de PHP puedes hacerlo. Simplemente en otra capa haces la llamada a una función que te hayas creado para leer el XML y mostrar el contenido un poco bien presentado. Yo lo suelo hacer mediante 'heads', listas y anclas, lo más accesible posible.
almostdesign
guille
En el fondo, son los mismos contenidos (que están en un XML) mostrados con flash o bien mostrados con html.
Te has quedado sin ancho de banda...
De todos modos, me gustaría preguntarte algo. ¿Qué tecnología has utilizado para convertir los datos del xml a html?
juandelgado
El efecto Domestika, te has quedado sin ancho de banda : )
guille
Este post ya hace días que anda medio muerto.
Pero bien, justo he acabado un site que incorpora alguna de las mejoras que comentaba en este artículo y os lo quería enseñar.
El site es: http://www.annasodupe.com
Si entrais directamente lo veréis tal cual un usuario normal (con flash).
Pero si desactivais la opción de "javascript" en el navegador, vereis los contenidos tal cual los ve un buscador.
En el fondo, son los mismos contenidos (que están en un XML) mostrados con flash o bien mostrados con html.
athomix
Orange, intentaba aclarar las preguntas de Txuma. Mi posición y mi previsión.
Claramente opino que Flash va aumentando sus posibilidades y "haciéndose mayor", mucho más deprisa que html, junto con css o js.
Tengo mucho respeto por html y sus capacidades que no son pocas. Dije limitadas, en relación a las que empíricamente pueden ofrecer otros formatos que se están abriendo, e interesando en sucederlo como estandar de la web, como pdf que ya es un estandar de facto.
Tampoco separo CSS de html, al contrario, ya son inseparables como del resto de "herramientas", porque el usuario cada dia es más exigente y los dispositivos más flexibles, o las comunicaciones más rápidas.
No soy Rapel. Ni idea de que pasará en el futuro. Beta era mejor que Vhs, pero no sobrevivió. Basic mucho sencillo y flexible que Cobol, y creo que aún coletea, como AS400. Png probablemente es mejor que jpg pero triunfó el último.
Es sólo una opinión. Tampoco soy un techie, ni un erudito.
Lo único seguro es que sumas 2+2 y nunca da 4. :D
Y por supuesto si alguien cree lo contrario puede exponerlo y convencerme.
orange
Sinceramente (y lee lo que voy a escribir con cariño por favor), cualquier postura "integrista" de crítica a Flash o HTML me parece que se basa siempre en una falta de conocimiento profundo de alguna de las dos "tecnologías" (y separar HTML de CSS, como si fueran dos cosas distintas, ni te cuen. Piensa en estándares y mete todo en el paquete).
Me parece flipante tener que defender a estas alturas las "bondades" de Flash para unas cosas y HTML para otras.
Tan chorra me parece decir que Flash es una mierda que no vale más que para hacer intros en las páginas como los que dicen que los estándares son un atraso y que no se pueden hacer páginas ni medio decentes con ellos.
athomix
En este trabajo todo esta relacionado -mezclado- y es difícil resumir las impresiones de muchos años (que pueden ser equivocadas), en un mensaje.
HTML tiene una base demasiado elemental y por tanto muchas limitaciones, y tras diversas mejoras todavía necesita apoyo.
Sin CSS (ni programación) habría que escribir los estilos en cada hoja. ... eso no es demasiado productivo y evidentemente hubiera pasado por encima del estandard cualquier otro elemento con mayor capacidad. Ley de vida.
Otra gran incapacidad es la recargar toda la página con cada petición al servidor (y la necesidad de hacer peticiones al servidor para la mayoría de las cosas). Muchas webs no existirían.
Desde hace años puedes descargar archivos pdf, doc, swf, directamente y sin necesidad de html. No han remplazado a HTML (todavía) por sus tiempos de descarga, pocas aportaciones efectivas y falta de acuerdos y estándares.
En cuanto a la accesibilidad, buuuf... Primero la confusión entre usabilidad y accesibilidad (cuando en ingles accessibility significa lo mismo).
Segundo, parece que el único fin de la accesibilidad (prefiero el término usabilidad porque creo que lo engloba todo) son las personas con alguna discapacitación y el argumento de venta los buscadores, cuando la realidad es otra. La realidad es que una web con faltas de ortografía, (por ejemplo y siendo puristas) es inaccesible (para todos).
Así que la accesibilidad de la web no depende sólo de que herramienta usas, sinó de como la usas, para que la usas y para quien la usas (resultado, objetivo, usuario).
Espero haber aclarado mi opinión, o haberos liado lo suficiente a todos ... :D
ventdaval
Guille, las soluciones que presta swfaddress estan disponibles desde hace ya mucho tiempo... yo diria que la primera vez que vi algo similar fué hace unos 5 años con Flash 5 (si, lo del SEO, lo de las URLs, lo del boton atras, etc... si quieres te busco algun link).
La implementacion del tema va de mano del desarrollador, y sí, es un rollazo gigante hacerlo bien... es, basicamente, desarrollar dos veces y media la misma web... Y si alguna vez os veis tentados a implementarlo completo, os recomiendo antes meditar mucho si realmente es necesario el (full) flash.. :P
Personalmente, creo que Flash ya se hizo mayor con AS3, pero no porque vaya a reemplazar a HTML, sino porque como plataforma de desarrollo ya es seria (quizas demasiado ^^).
A mi me gusta pensar en internet como informacion antes que como interfaz, y mientras la informacion de un swf vaya de acuerdo a criterios arbitrarios, creo que no hay nada que hacer (aunque google pueda meterse dentro del swf, que lo hace hace tiempo tambien). Quizás sí podria ser beneficioso disponer de protocolos estandar para organizar la información en Flash (RSS?, Sitemaps?), pero aun asi creo que me costaria justificar Flash para una web con informacion importante y que deba ser indexada.
En fin, que tengo q terminar de destornillar un mapa de ubicacion xD
guille
Está claro que son cosas distintas.
Pero yo creo que Flash ha cambiado muchísimo, y que ya no es el "destornillador" inútil de hace unos años, sinó que ha convertido en una herramiento multiuso muy potente que ningún fontanera de la web debería descartar.
elsuricatorojo
Yo insisto, hay que ver al Flash como un destornillador (por ejemplo) y al HTML como a una llave inglesa. Para unas cosas será mas util el destornillador, para otras la llave y para otras la combinación de ambas.
txuma Plus
Athomix, creo que estás mezclando ideas y conceptos.
No acabo de entender muy bien a que te refieres con 'HTML hubiese desaparecido de no ser por CSS o JS'. Sospecho por dónde van los tiros, pero prefiero que me lo confirmes antes de emitir una opinión precipitada.
Y si me permites, una segunda pregunta al hilo de esta frase:
Athomix
Por último, cuando alguien habla de accesibilidad, ¿sólo piensa en los buscadores? Al final un poco de sentido común no estaría de más.
¿A qué te refieres con 'un poco de sentido común'? Cuando se habla de accesibilidad no se hace referencia a buscadores, sino a que todos los usuarios puedan acceder a la información de una web.
athomix
Humildemente creo que no es Flash quien tiene que hacerse mayor...
Si HTML no ha desaparecido es gracias a CSS, JS y porque no, gracias a Flash. Porque Flash se integra fácilmente DENTRO de un HTML para mantiner una compatibilidad con navegadores y buscadores. El día que éstos se espabilen el que corre peligro de extinción és HTML.
Luego el "libro de primero" ha de ir acompañado de otros de segundo y de tercero.
En que web no hay nada en Flash?
y en que web HTML no hay nada en JS y/o CSS?
Luego hay unos cuantos intereses (SUN, Adobe, W3C, Apple, Microsoft, ... ), cada uno con su parcela de poder, que quieren obviamente explotar y rentabilizar al máximo, lo que difiuculta la integración real.
Por último, cuando alguien habla de accesibilidad, ¿sólo piensa en los buscadores?. Al final un poco de sentido común no estaría de más.
Personalmente creo que el futuro està más cerca de Flash/Pdf (sí pdf) que de cualquier otra tecnología actual. Pero hoy es hoy, claro.
orange
Lo que yo no entiendo es la manía en tratar de "unir" ambos ambientes, cuando cada uno tiene puntos fuertes/débiles y creo que ninguno de ellos es capaz de "emular" de forma totalmente correcta al otro.
Por muchas técnicas que se utilicen, Flash sigue teniendo muchos más problemas a niveld e SEO, accesibilidad, etc... que un HTML a palo. Y eso sin entrar a valorar la simplicidad en el desarrollo, es decir que para programar una página indexable y accesible en HTML vale un libro de primero y en flash ni te cuen.
Y por mucho que JS evolucione una página HTML+JS siempre irá por detrás del Flash en muchas cosas, y esto sin entrar en vídeo, audio, etc... Y eso sin entrar a valorar la simplicidad en el desarrollo, es decir que hacer ciertas cosas en Flash está chupado y para emularlas en JS, con el mismo universo de navegadores, es jodido de huevos.
Yo soy un FAN de todas estas cosas (tratar de pulir fallos en cada uno de los dos mundos) pero lo que me parece que no tiene sentido es decir que son iguales.
Respondiendo a la pregunta. Flash se "hará mayor" cuando deje de compararse con HTML y se haga rey y dueño de su propio campo (que ya lo tiene).
tpmmds
Hola:
En principio está muy bien, pero el problema que le veo yo es que no es algo "transparente" para el desarrollador Flash. En Flex existe el History management que te permite hacer algo similar. También te permite recordar estados de la aplicación y volver a apartados concretos de la misma, pero eso sí, lo tienes que implementar tú, como me pacere que hace también este paquete.
Y claro, el problema aparece por la falta de homogeneidad en las aplicaciones web que se van generando: unas lo llevan, otras no y, lo más peligroso, un término medio de aplicaciones que lo llevan a medias ;-). De hecho creo que un "usuario tipo" de la web, en el momento que detecta que está en un "entorno Flash" (para entendernos) olvida consciente, o inconscientemente, las dos flechas de la parte superior izquierda de los navegadores.
Un saludo.
guille
Pero la historia no es esa.
Lo que se hace es mostrar los contenidos de una forma diferente si el que visita la web tiene javascript habilitado (swf - usuario) o si no (html - boots/google).
Los contenidos están guardados en un XML. Si es un usuario el que entra se muestran en un SWF, y si es un boot se muestran con PHP/HTML.
No es muy complicado.
juandelgado
Ivan, las especificaciones del formato swf son abiertas. Se pueden solicitar aquí:
http://www.adobe.com/licensing/developer/
Si Google no hace más por indexar swfs es probablemente porque no quiere, no porque no pueda.