¿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.

2 pensamientos en “¿Flash o Html?

  1. Alex

    Muy interesante, aunque no me queda claro la parte de "Crea en html las páginas necesarias para cada sección y subsección (o una página dinámica que se actualice convenientemente" ya que una web diseñada enteramente en Flash (sin ser dinámica) solo necesita de un html donde va insertado el swf. Supongo que se refiere solamente al caso en que sea una web dinámica o desarrollada en html no?

    Saludos!

    Responder
  2. Semántica

    Hola Alex,

    La verdad es que releyéndolo es cierto que no queda muy claro.

    Si por ejemplo la web tiene 3 secciones (home, work y about) y estamos utilizando algún lenguaje de servidor, se trataría solamente de incluir entre las etiquetas noscript de la página principal donde reside el swf los contenidos de esas tres secciones y un menú simple que permita navegarlos. Luego podremos hacer que la página muestre una u otra sección según una variable que le enviamos en get, algo como:

    example.com/?seccion=home

    los elementos de ese menu html llevarían ya los links que dirigen todos a la misma página, pero con opciones diferentes.

    Recuerda que todo lo que pasa en el bloque noscript será visible solamente a browsers que no ejecutan JavaScript (básicamente los spiders de los buscadores).

    Para hacerlo aun más seo-friendly, puedes poner un htaccess con un mod_rewrite que convierta example.com/work en example.com/?seccion=work, o algo similar.

    Al final lo que te debería quedar es solo una página html, pero que recibiendo según qué variables renderiza (en el bloque noscript) un contenido u otro.

    Si no usas un lenguaje de servidor como php, no te queda otra que hacer esto mismo pero creando realmente la estructura de carpetas y poniendo en cada una el mismo html, pero con contenidos distintos en el noscript.

    Esto último es bastante más engorroso, especialmente para sitios grandes, y dado que la lógica que habría que implementar en php es muy simple, yo recomendaría la primera opción.

    Responder

Responder a Semántica Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *