Es interesante como (casi) todos terminan entiendiendo que un sitio Flash no es la solución, y aceptan que desconocían las desventajas de hacerlo de esa manera y las distintas alternativas que existen al momento de desarrollar un sitio web.

Es por ello, a servicio tanto de clientes como de desarrolladores web, creé esta lista de “Porqué no se debería utilizar Flash para diseñar un sitio web”.

Atenta contra usabilidad del sitio.

Tal vez esta sea una de las mayores contras de utilizar Flash.

Cuando estamos navegando un sitio web realizado en (x)HTML y llegamos a una página que no nos interesa, simplemente pulsamos el botón “Atrás” de nuestro navegador y volvemos al contenido anterior. Lo mismo sucede con la dirección URL de la misma: si es de nuestro interés, podemos agregarla a nuestros favoritos o enviarla por mail a un amigo.

En estos casos, usabilidad sería poder utilizar las herramientas que nos brinda el explorador para hacer de nuestra de navegación una experiencia agradable.

Bueno, olvídensen de poder realizar esto con Flash, ya que (en la mayoría de los casos) toda la navegación se realiza dentro de un mismo archivo SWF. Entonces, cuando hacemos clic en “Atrás”, en realidad no estamos yendo al contenido Flash anterior, sino a la URL anterior. De esta manera, se pierde toda posibildad de poder referenciar a un contenido en particular dentro del sitio.

No es leído por los robots de los buscadores. La exposición del sitio en buscadores es pobre.

Si bien es cierto que se han realizado avances en materia de lectura e indexación de archivos SWF por parte de los robots de los buscadores, dichos avances nunca podrán asimilar la capacidad semántica que podemos brindar con (x)HTML.

En el código (x)HTML, utilizamos distintos tags para indicar (a los buscadores, al navegador y al usuario) qué contenidos son importantes, cuáles relevantes, qué hace referencia a otros sitios, qué es una imagen, qué es un título, etc. Con la próxima llegada del HTML5, esto se potencia aún más.

Bueno, esto no se puede realizar con Flash. Debido a que es un código cerrado y carece de semántica, los robots de los buscadores no pueden interpretar el contenido del sitio con la riqueza que lo harían con los (x)HTML.

Esto se traduce a que el sitio en Flash rankeará (dejando de lado otras variables) peor que su gemelo realizado en HTML, generando un volumen menor de visitas.

Si a esto le sumamos que otros sitios de Internet no podrán referenciar directamente a contenidos que están dentro del archivo SWF (no los podrán linkear, ver punto sobre la usabilidad), la posibilidad del sitio en Flash de lograr un buen posicionamiento es mucho menor.

Es un software propietario

Otra desventaja de utilizar Flash es que no es un software de código abierto, tales como (x)HTML, CSS y JavaScript. Para generar un archivo SWF (el Flash que finalmente veremos en nuestro navegador) debemos utilizar, en la mayoría de los casos, el software Adobe Flash. El archivo SWF generado es inmodificable, para realizar cambios debemos contar con el archivo FLA original. Muchas veces, éstos quedan en el poder de los diseñadores, y muchas otras veces se terminan perdiendo (ya que no es necesario subirlos con el sitio, y luego desaparecen con alguna formateada).

En cambio, con (x)HTML, CSS y JavaScript no precisamos de ningún programa (si nos damos maña, podemos resolver todo con un Notepad), y todos los archivos son modificables. Esto implica que es más sencillo realizar mantenimiento del código, actualizaciones, etc.

Además, con Flash estamos obligando al usuario a tener instalado el Plugin necesario para reproducir este tipo de archivos. Esto no sucede con (x)HTML, Javascript y CSS, que son nativos en cualquier navegador.

Requiere mayores tiempos de carga y el usuario debe instalar un plugin

Otra desventaja más es que los archivos SWF son más pesados que sus primos (x)HTML (con imágenes y todo). Esto implica que el usuario tiene que esperar hasta que la película SWF se termine de descargar para poder visualizar el sitio, y es bien sabido que “tiempo de atención” no es algo que sobre en Internet.

Los usuarios abren, cierran y visualizan páginas de Internet en segundos. Hay millones de sitios dando vuelta. Si el usuario ve que tiene que esperar más de 10 segundos para poder visualizar un contenido, lo más probable es que abandone dicho sitio y se vaya al sitio de la competencia (que no está a una cuadra de distancia, está a solo un clic de distancia).

La atención y el tiempo disponible son muy fugaces. Entonces, ¿por qué abusar de la paciencia del usuario? Si queremos captar su atención e interés (AIDA, para los publicistas), ¿es una buena estrategia que tenga que esperar para ver el contenido?

Además, no nos olvidemos que, para poder visualizar un archivo SWF, el usuario debe tener instalado y actualizado el Flash Player (para cada navegador que utilice). Es decir, otra molestia más.

Muchas animaciones se pueden lograr sin problemas con (x)HTML, CSS y Javascript

Por último, muchos de los motivos utilizados por los diseñadores Flash es que con (x)HTML, CSS y JavaScript no se pueden realizar animaciones.

Puede que haya sido cierto hace un par de años: las páginas web eran muy estáticas y la única forma de mover el elemento “X” de A a B era con Flash. Actualmente, se han realizado muchos avances con JavaScript y se han escrito muchas librerías (jQuery, MooTools, etc) de código abierto que permiten hacer maravillas con (x)HTML.

La mayoría de las animaciones que hoy vemos en sitios Flash se pueden realizar sin problemas, con menor carga y de manera más eficiente, con (x)HTML, Javascript y CSS. Además, con la próxima introducción de HTML5 y CSS3, las posibilidad se extienden mucho más.

Así que ya saben, si un diseñador les ofrece como única alternativa un sitio en Flash, ¡cuidado! Es muy probable que dicha persona no se haya podido actualizar y desconozca las ventajas de realizar el sitio con (x)HTML, CSS y Javascript.

Extraído de ElBlazer

Una empresa de hosting con la que colaboro, tiene incompleta la sección de ayuda del sitio web. Les pregunté porqué no la completan, se podrían ahorrar muchas horas de soporte. La respuesta fue: “Por más que la completemos la gente no la va a leer y va a terminar llamando igual”.

OK, es verdad que los usuarios no son muy “amistosos” con la idea de leer. El tiempo en Internet es veloz, tenemos mucha información para leer y procesar, y no dan los tiempos para ponerse a interpretar un extenso archivo sobre cómo configurar el mail, si hay un número de teléfono al cuál llamar.

Pero mi pregunta es: ¿la gente realmente no lee, o estamos haciendo las cosas mal?

Por ejemplo, los clientes de esta empresa de hosting reciben, al momento de darse de alta, un detalladísimo mail con todas las configuraciones que precisan. Si leyeran detenidamente eso, prácticamente podrían prescindir del servico técnico de la empresa. Pero dicho e-mail tiene varios errores:

• No tiene diseño, es casi texto plano.
• No hay índices ni se explica, al principio del mail, que contenidos encontrarán en él
• No hay títulos visibles

El mundo de la publicidad nos ha enseñado valiosas lecciones sobre diseño y redacción si queremos captar la atención del target. ¿Por qué no las ponemos en práctica?

Eso, amigos, es parte de la usabilidad. La web es un soporte más, y como tal, hay ciertas reglas que no podemos obviar:

• KISS (keep it simple, stupid). Esto es infaltable. Lo quiero sencillo.
• Colores y diseños user-friendly. Lo quiero lindo.
• Índices o menúes de navegación y títulos explicativos. Lo quiero rápido.
• Información organizada de manera sencilla y entendible. Lo quiero sin complicaciones.

En otras palabras, creo que depende de nosotros motivar a los usuarios.