¿Flash o Html?

En las reuniones previas al desarrollo de un sitio web siempre llega el momento de la pregunta del millón ¿Lo hacemos en Html o en Flash?

En la mayoría de los casos el cliente ya tiene una idea creada al respecto, pero por desgracia, una buena parte de ellas están basadas en premisas erróneas o en el mejor de los casos incompletas.

Lo que no puede ser no puede ser, y además es imposible

Incluso un usuario medio, sin conocimientos de lenguajes, protocolos o formatos, distingue perfectamente una página en flash y divide, aunque a veces inconscientemente, la web en dos grandes grupos: Por un lado están las páginas con movimiento, transiciones complejas, contenido gráfico altamente customizado y sistemas de navegación molones que a veces no hay quien entienda. Por otro las páginas que cargan una a una, sin apenas transiciones y en las que generalmente todo funciona mejor (el texto se puede seleccionar, los botones atrás/adelante del navegador hacen lo que deben, los menús están claros y casi todo es previsible).

Entre medias quedan las aplicaciones que mediante javascript consiguen una respuesta inmediata a las acciones del usuario, como la mayoría de las aplicaciones de google (gmail, picasa, finance, etc), y las que como beatport o Photoshop Express utilizan Flex para proporcionar una interfaz rica y altamente estructurada o realizar acciones complejas.

• Es perfectamente posible producir en flash un resultado con look&feel de html, no así la riqueza de metadatos y la carga semántica de una página en html correctamente planeada.
• Seguramente sea perfectamente posible producir en html (ayudándonos de Javascript y java) un resultado parecido a flash en términos de interfaz y respuesta… aunque me duele la cabeza solo de pensar en la compatibilidad con navegadores de algo así (un tema, por cierto, bastante bien enfocado por google y su GWT).

¿Por qué nadar contracorriente? si tu contenido es tipo flash, haz flash, si es tipo html, haz html, si hay partes que precisan de un tratamiento diferente, puedes optar por secciones, subdominios o dominios claramente diferenciados, como hace DoubleYou, si no te encuentras a gusto en ninguno de los anteriores, quizás debas hacerte algunas preguntas más.

¿Es push o es pull?

Si el carácter de tu contenido es push, si una parte importante del mensaje está en la gráfica, el uso de audio o en la interactividad, si consigues tus visitas mediante enlaces patrocinados y mailings, flash puede dar a la web ese carácter especial, haciéndola destacar sobre las demás, diferenciándola y favoreciendo el recuerdo, sin necesidad de que tu web sea invisible a los buscadores (lo visible que sea dependerá del tiempo que te tomes más que del formato)

Por el contrario, si tu contenido es (o tiene partes) pull, si es probable que los usuarios accedan a el mediante buscadores, si es factible que alguien quiera agregar ese contenido para reutilizarlo, o acceder a el mediante dispositivos móviles, en otras palabras, si el contenido trasciende al medio, el xhtml es probablemente lo mejor.

Ser indexable es bueno

La maravilla del html es que permite una indexación salvaje, es pura semántica, palabras clave, vínculos, metadescriptores, tags, ontologías, vocabularios controlados… Cualquiera sabe esto, lo hemos escuchado tantas veces que la frase “El contenido en flash no es indexable, en html sí” es habitual entre desarrolladores, diseñadores y responsables de marketing… y es incorrecta.

El mero hecho de presentar el contenido en html no lo convierte en indexable, accesible o usable, de hecho diría que cerca del 80% de las páginas que visito diariamente presentan problemas de indexabilidad como metadescriptores incorrectos o inexistentes, palabras clave y títulos repetidos, enlaces sin significado del tipo “pulsa aquí”, o contenidos que simplemente desaparecen al desactivar JavaScript.

Por poner un ejemplo, esto es lo que dice sobre sí misma la home española de un conocido fabricante de automóviles:

<meta http-equiv="imagetoolbar" content="no" />
<meta name="robots" content="index, follow" />
<meta name="revisit-after" content="10 days" />
<meta name="content-language" content="es">

No es demasiada información ¿no? ni siquiera para un mercado tan oligárquico como el de los automóviles. Si miramos en su web internacional encontramos más datos:

<meta http-equiv="imagetoolbar" content="no" />
<meta name="author" content="Scholz &amp; Volkmer GmbH, Germany (www.s-v.de)" />
<meta name="copyright" content="2008 Daimler AG, Germany" />
<meta name="keywords" content="Mercedes-Benz, Mercedes, Benz, Brand World" />
<meta name="description" content="Daimler official Mercedes-Benz site. Contains car profiles, motor sports and classics." />
<meta name="robots" content="index, follow" />
<meta name="revisit-after" content="1 day" />

Si dependíesemos de los metadescriptores para organizar la web el primer ejemplo caería en la categoría de “páginas en español sin descripción”, o sea un cajón de sastre.

Además tendemos a olvidar que flash también es html, porque se embebe dentro de una página en html. En muchas ocasiones el contenido de una página es predominantemente visual y no tiene una estructura claramente definida aún teniendo secciones, o se trata de una aplicación secuencial, eminentemente interactiva, o que entendemos como una experiencia completa y no navegable o divisible en “trozos” de contenido, como Navidad Smart o elfyourself.

En estos y otros casos una sola página en flash con un título, descripción, y palabras clave correctamente elegidos, claros e inteligibles funciona mejor en buscadores que un sitio en html con cientos de páginas sin una distinción semántica o títulos y descripciones repetidos o mal planteados. Así por ejemplo la página de la fotógrafa Luana Fischer, programada en flash y “teóricamente” no indexable, aparece con frecuencia en la primera página de resultados de una búsqueda google hecha en España para el término “fotografía profesional” .

Rizando el rizo

Si nuestro contenido tiene una estructura clara con páginas y secciones diferenciadas, actualizaciones frecuentes o contenido semántico que queremos que sea indexable y accesible más allá de las posibilidades de los metas, y al mismo tiempo la interfaz o la experiencia que queremos proporcionar al usuario necesita flash para vivir, va a ser necesario mancharse un poco más las manos.

Crea una arquitectura completa de tus contenidos, y divídelos en secciones y páginas como harías en un proyecto html. Lo que buscamos es un prototipado funcional esquemático (raquítico, diría yo) para poder convertirlo después en una web reducida a su mínima expresión, sin estilos, sin colores, solo texto, hipervínculos y etiquetas estructurales (como h1 o h2).

Crea un mapa del sitio coherente con este prototipado.

Crea una estructura semántica de carpetas para contener cada página (lo ideal) o al menos una estructura de secciones que responda a variables GET, preferiblemente con significado (?seccion=proyectos).

Crea en html las páginas necesarias para cada sección y subsección (o una página dinámica que se actualice convenientemente), embebiendo en ellas el contenido flash mediante JavaScript (hacerlo así ya era recomendable para evitar el molesto “pulse aquí para activar este contenido”).

Programa cada una de estas páginas con sus propios títulos y metadescriptores, e incluye en xhtml simple todo el contenido de la página (incluyendo el menú completo, textos, imágenes e hipervínculos) entre etiquetas <noscript></noscript>

Cuando sea posible, haz que se refleje en la película flash la sección a la que hace referencia la URL. Esto no tiene influencia en cómo los buscadores ven tu web, pero sí en cómo la ven los usuarios.

Inhabilita JavaScript en tu navegador favorito y navega la página. debería ser navegable e inteligible. Aquí puedes ver un ejemplo www.frostnixon.net.

A partir de aquí puedes conformarte con mantener a los buscadores informados de los cambios en tu mapa del sitio o profundizar más utilizando herramientas de SEO. En cualquiera de los casos el sitio será visible e indexable y los resultados no tardarán en hacerse notar.