RAZONES PARA UTILIZAR FLASH

Como recordarán, en el capítulo anterior nuestro héroe fue forzado a demostrar su valor derrotando a sus archienemigos usando 5 grandes súper poderes: alucinaciones (experiencias multimedia), parainfernalia (atractivo visual), velocidad (ancho de banda), visión de rayos (video) y su capacidad de estar presente en todas partes (Navarro… perdón, ubicuidad). Pero aún saliendo airoso de la prueba, es evidente que nuestro héroe también posee un lado oscuro de insospechadas consecuencias para este mundo que llamamos ciberespacio. Una faceta tan siniestra que lo lleva desde el secuestro hasta el vandalismo, sin mencionar el atropello a discapacitados. ¿Podrá nuestro héroe redimir su espíritu malvado? ¿Serán sus súper virtudes capaces de superar a sus súper defectos? ¿Debe Safari para Windows ser rebautizado como TranSafari? Sepan todo esto y mucho más en nuestro capítulo de hoy: las 5 grandes razones para desechar a Flash. ——————————————————————————– CONTRA Nº1 – Toma de Rehén al Cliente Hace un par de años, un diseñador que frecuentaba el MMUG Chile me mostró el sitio Web que estaba ultimando para un cliente. Intrigado al notar que todo lo que había hecho pudo realizarse sin complicaciones sobre HTML, le pregunté por la motivación para usar Flash como base de su trabajo. Con toda ligereza, el sujeto me dio las 2 razones más patéticas que jamás esperé oír: “porque es más fácil -a lo que me referiré dentro de poco- y porque así me aseguro que el cliente siga trabajando conmigo“. Ahora viene un tema delicado, así que permítanme explicarme. Contrario a HTML que es un lenguaje de presentación editable hasta con el Bloc de Notas, Flash requiere 2 tipos de archivos: un archivo fuente (.FLA) cuya creación/edición se realiza en el programa Flash (o SWiSH o similar), y un archivo exportado (.SWF), que irá al navegador para visualizarse usando el Flash Player gratuito. Esta situación otorga una inquietante ventaja al diseñador ya que, al estar en poder de los archivos fuente, sólo él podrá realizar modificaciones al sitio Web. Así, un profesional inescrupuloso puede “asegurarse” de que el cliente seguirá contratando sus servicios, so pena de verse obligado a pagar a otro diseñador la reconstrucción completa del trabajo realizado. Y no crean que se trata de numeritos aislados. Como profesor, durante años he conocido múltiples casos -el último hace sólo un mes- de clientes que fueron chantajeados con la no entrega de archivos fuente al intentar cambiar de diseñador o realizar ellos mismos las modificaciones. En otras situaciones no hubo mala intención, sino que por pérdida de contacto con el profesional fue imposible recuperar los archivos .FLA originales. Aquí viene una discusión que hasta ahora no ha sido zanjada: ¿los archivos fuente son propiedad del cliente o del diseñador? En muchos contratos se estipula la entrega de los archivos fuente -a veces con un recargo- donde no habrá problema; sin embargo en otros, y principalmente por desconocimiento del cliente o porque el diseñador alega defender su “propiedad intelectual”, el círculo se cierra hermético en favor de este último. ¿Mi opinión? Los archivos fuente siempre son del cliente, pues él nos encarga y paga por el sitio Web. Retenerlos -máxime sabiendo que no se les podrá dar otro uso- es como si un arquitecto diseñara una casa y se negara a entregar los planos. Después de todo, de realizar un buen trabajo el cliente no tendría por qué cambiar de proveedor… y aún así está en pleno derecho de hacerlo. Debates aparte, la situación es una: el uso de Flash para construir sitios Web abre la posibilidad de que un cliente desinformado pierda su inversión, sea por olvido o por engaño. Esta variable se elimina al trabajar sobre HTML/CSS, ya que los archivos siempre son editables. CONTRA Nº2 – Sostiene la Incompetencia Hago una aclaración antes de ser linchado: conozco muchos diseñadores admirables que usan Flash para obtener resultados fantásticos. Andrés (aka Lifaros) por ejemplo, debe ser uno (sino el) programador de ActionScript más experimentado de Chile, mientras que Alberto (aka ViB) y Romina (aka Az) son capaces de desenvainar Flash con la misma solidez con que dominan HTML. Kudos para ellos. El problema se da al otro lado de la cadena alimenticia. Un gran número de profesionales (o aficionados) que ingresan a la creación Web se dejan seducir por la simplicidad -aparente- en el entorno de Flash, en especial cuando se trata de diseñadores que provienen del área gráfica. Seguro. ¿Para qué perder el tiempo calculando dimensiones de tablas, posicionando elementos de bloque, escribiendo hojas de estilo, agregando texto alternativo e incluso saltando continuamente del editor al navegador para comprobar si todo va como debe? Flash nos evita en gran medida lidiar con código, nos provee la misma interfaz familiar de un programa de dibujo y se traslada un elemento o posiciona texto con sólo arrastrarlo. Además metemos fotos, sonidos y video dentro de un solo archivo y podemos aplicar algo de pirotecnia que aguará la boca del cliente. ¿Qué más se puede pedir? Chicos, cuando comprendemos a Flash como un cómodo resguardo a nuestras limitaciones -sea incompetencia, pereza o ignorancia- no sólo realizamos un trabajo deficiente que falla en los principios mínimos de optimización, indexación, usabilidad, accesibilidad (o estándares) que debe tener la Web; también fallamos en desarrollar la potencialidad inherente a la herramienta. Por eso la anécdota inicial tacha la aplicación como “más fácil”: para quien así lo desea, Flash permite saltarse conocimientos indispensables cuando se trabaja con HTML, CSS o JavaScript, mantener ese espejismo de que se trabaja en forma gráfica (a conciencia de que un sitio Web es usable por esencia, en vez de observable) y aún así obtener resultados; ineficaces -hasta inútiles- pero siempre envueltos para regalo. Curiosamente, esto nos deja con otra reflexión: si existe la necesidad de crear sitios Web en forma amateur -ya sean personales o de pequeñas empresas- ¿no debemos transitar a que editores como Dreamweaver, GoLive, Expression o NVU alcancen un verdadero estado “WYSIWYG“, donde un usuario pueda diseñar visualmente mientras el programa se encarga de aplicar los estándares tras bambalinas? Algunos pensarán que esto sería el fin de los diseñadores Web. Más bien, yo diría que sería el principio de una Web como corresponde: usable, algo que hoy Flash no facilita… irónica y precisamente por el mismo motivo. CONTRA Nº3 – Problemas de Usabilidad Sé lo que están pensando: ambos puntos anteriores son problemas más propios del diseñador que del programa. Es una verdad a medias pues todo efecto requiere una causa, pero ya que lo mencionan vamos a las debilidades intrínsecas de Flash. Desde que en 2000 Jakob Nielsen escribiera su famoso ensayo de Flash 99% Bad, mucho se ha debatido en torno a las falencias de usabilidad y accesibilidad de nuestro programa en comparación con los sitios Web realizados sobre HTML (nótese que Nielsen acabó uniendo fuerzas con Macromedia en 2002 para mitigar estos problemas, pero sus resultados aún están en entredicho). Sin más preámbulos, los sitios Web en Flash son culpables de 7 pecados: Deshabilitar el botón “Atrás” del navegador, puerta de escape de muchos usuarios, en especial los con menos experiencia. Imposibilitar el cambio de tamaño de la tipografía, función imprescindible para usuarios con limitaciones visuales o de la tercera edad (mismo vicio en que caen los diseñadores que usan pixeles para definir sus hojas de estilo CSS). Los contenidos -en principio- no son seleccionables, imprimibles ni pueden ser leídos por navegadores para personas con discapacidad visual (como JAWS). Carencia de texto alternativo. Toda imagen JPG, PNG o GIF puede acompañarse de un texto que la describa para los usuarios con impedimentos visuales o que por razones técnicas tienen deshabilitadas la visualización de imágenes. Flash -en principio- carece de esta posibilidad. No se puede marcar o acceder al contenido directamente. Dado que -en principio- un sitio Web desarrollado en Flash se envuelve dentro de un mismo archivo, toda acción se desarrolla en forma interna, sin que cambie la dirección (URL) de la página. Esto impide marcar o acceder directamente a una sección del sitio, tal como sucedía con los combatidos marcos (frames) de HTML. Vínculos (links) no estándar sobre texto, en ocasiones sin subrayado ni otra seña que indique su existencia. Adicionalmente carece del atributo “alt” o incluso de la conexión con la barra de estado del navegador, que informa a los usuarios dónde se dirigen. Uso de interfaces gráficas (GUI) no estándar. Las posibilidades gráficas de Flash tientan a los diseñadores a construir botones, ventanas, barras de desplazamiento e incluso cursores personalizados, que muchas veces anulan las convenciones familiares para los usuarios, extraviándolos. Ahora bien, en defensa de Flash debemos aclarar que muchos -sino todos- estos puntos son subsanables a través de funciones internas del programa (como hacer el texto seleccionable, la creación de marcadores, etc) o bien mediante instrucciones JavaScript. Una buena muestra de ello es The Flash Files, un sitio realizado con (casi) todas estas falencias subsanadas. ¿El gran problema? Requieren conocimientos o desarrollo extra -en ocasiones tan oneroso como construir una versión HTML y otra Flash de cada contenido- que muchos usuarios no se molestan, no saben o simplemente no tienen tiempo/presupuesto para habilitar. Producto de ello, la inmensa mayoría de los sitios Web en Flash incumplen groseramente estos preceptos de usabilidad. Aquí se produce una redundancia curiosa del punto anterior: en HTML o CSS, prácticamente todos estos puntos están previstos por la naturaleza del lenguaje. Están incorporados a él. Flash por su parte, realiza el mismo trabajo sin siquiera advertir al diseñador inexperto (o negligente) de su existencia. De aquí su supuesta “facilidad”. Y por cierto, aunque The Flash Files está muy bien realizado… ¿no habría sido una opción más lógica construir el mismo sitio en HTML con apoyo de animaciones en Flash? Cul-de-sac. CONTRA Nº4 – Problemas de Indexación No es raro que al conversar con un cliente, este frunza el ceño cuando le hablamos de usabilidad, accesibilidad, estándares y todas esas cosa’el diaulo. Por lo regular, los ejecutivos tienen la idea de un sitio a la PowerPoint, con muchas cositas que se mueven, suenan y saltan en forma lineal, por lo que Flash comienza siendo un requisito más que una solución. Si estos principios básicos no los remecen, la indexación seguro lo hará. En nuestra Web actual, no figurar en los motores de búsqueda -y particularmente en Google- significa no existir. Cada vez más usuarios comienzan sus sesiones de navegación tipeando el nombre de un sitio o un concepto en las cajas de búsqueda, por lo que un buen posicionamiento es fundamental para atraer tráfico hacia un sitio Web. Por desgracia, los archivos SWF de Flash son una pesadilla para los motores de búsqueda, que pese a los intentos por descifrar sus contenidos suelen permanecer inexpugnables, en contraste a los archivos HTML e incluso a sus pares de texto PDF o DOC. Así, 2 son los principales problemas de indexación de Flash: Los motores de búsqueda no logran procesar el texto en archivos SWF. Aunque algunos motores pueden hacerlo en forma parcial, no hay forma de indicar prioridades (como hacen las etiquetas estructurales

a

en HTML, o las semánticas como o ) ni de identificar las distintas secciones, por lo que el texto acaba siendo una masa que hunde nuestras posibilidades de remontar las páginas de resultados. Los motores de búsqueda no logran penetrar en los vínculos de Flash. ¡Esto significa que muchas veces Google, Yahoo, MSN Search o Ask no son capaces de ir más allá de la portada de un sitio Web! En otros casos, esas llamativas intros o coloridos menús que el cliente se empecinó en demandar serán las perfectas piedras de tope para decirle a los motores de búsqueda que se marchen. Por cierto, este es uno de los primeros problemas que las consultoras en optimización para motores de búsqueda (SEO) encuentran durante sus análisis, y pueden corregirse -hasta cierto punto- proveyendo enlaces complementarios en HTML y/o con un mapa del sitio accesible. Nuevamente, ambos problemas pueden subsanarse con desarrollo extra -como construir los sitios en películas SWF separadas montadas sobre páginas de hipertexto individuales, extraer los contenidos en forma externa desde bases de datos o bien desarrollar una versión HTML alternativa- pero con los apretados presupuestos y agendas de los clientes (y en otras las apretadas mentes de los diseñadores), ¿son realmente una solución factible? CONTRA Nº5 – Problemas de Administración Como si todo lo anterior fuera poco, aún restan 3 antecedentes que considerar previos a un desarrollo en Flash: Problemas de Actualización/Mantención: Salvo que sea magistralmente desarrollado en conexión a una base de datos u otras fuentes de archivos externos, una labor tan cotidiana como actualizar o modificar un sitio en Flash requerirá tanto de una persona con conocimientos específicos de Flash como del programa en sí. En comparación, un sitio montado sobre un administrador de contenidos (CMS) puede ser actualizado por una persona sin mayores conocimientos de informática, mientras que uno en HTML puede ser modificado -como ya mencionamos- incluso usando el Bloc de Notas de Windows. Problemas de Seguimiento: En un sitio HTML, analizar la conducta de los usuarios a través de estadísticas que nos digan cantidad de visitantes, horario, páginas que más visitan o palabras clave mediante las cuales los derivan los motores de búsqueda, es tan sencillo como agregar unas líneas de código de un servicio gratuito como StatCounter o Google Analytics. Si bien un sitio Web desarrollado sobre Flash puede ser monitoreado con la misma prolijidad, requiere tanto un trabajo como conocimientos específicos de marcado que muchos diseñadores no están en condiciones (o intenciones) de desarrollar. Problemas de Visualización: En 2005, una pequeña compañía californiana llamada Eolas le dobló el brazo a Microsoft respecto de la propiedad intelectual de los complementos (plug-ins) de los navegadores, obligándola a modificar las últimas versiones de Internet Explorer 6 y 7 para evitar el pago de varios millones de dólares. Debido a esto, todo contenido en Flash que no posea sobre el HTML que lo contiene un código JavaScript adicional de activación, no será lanzado de inmediato, sino que el usuario deberá hacer clic primero antes de visualizarlo. Desde luego, esto significa una molestia adicional para los usuarios e incluso quiebra las experiencias multimedia que se intentaba proveer. Y mientras Adobe provee la documentación para agregarlo, así como Dreamweaver 8.02 y CS3 lo hacen automáticamente, esto significa que una cantidad creciente de usuarios tendrán problemas para visualizar los contenidos en Flash que no hayan sido actualizados, mientras aquellos con restricciones a la ejecución de JavaScript -con frecuencia por razones de seguridad- tampoco podrán beneficiarse. No está de más recordar que Firefox y Opera están exentos de este problema😉
Explore posts in the same categories: Uncategorized

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: