Analizando logs con flash y de sites basados en flash.
Uno de los puntos más débiles de los sites desarrollados en flash es que no son facilmente medibles y por tanto no se pueden evaluar en efectividad.
Este punto debil es crÃtico ya que un site que no se puede evaluar no se puede corregir y por tanto nos encontramos a ciegas ante nuestro desarrollo.
2mdc presenta este analizador de logs basado en flash y diseñado para sites cuyo contenido es flash.
El diseño es efectivo, simple y permite analizar las peticiones a las pelÃculas de nuestro site. Si organizamos el contenido de los movie clips por carpetas y utilizamos nombres identificativos para los ficheros esta herramienta se puede convierte en algo muy util para nuestro cliente final.
Tamaño de lienzo dinámico
Otro de los puntos débiles de Flash es el disponer de un "lienzo" de tamaño dinámico.
Flash permite crear una pelÃcula en la que el tamaño del área de trabajo está predeterminado y es fijo para toda la pelÃcula. Es decir, si decidimos hacer una pelicula flash de 800×600 sólo podrá ser de 800×600 con lo que tendremos problemas si en algún momento del desarrollo el texto crece, queremos acumular más contenido, etc…
2mdc ofrece este desarrollo que permite que el tamaño de la pelÃcula flash crezca (literalmente) a medida que el contenido se expande.
En el ejemplo se puede ver como las "filas" de texto HTML inferior y superior son empujadas al abrir las carpetas de la pelÃcula flash.
En este caso, los amigos de 2mdc ofrecen los ficheros para ser descargados.
Conclusiones. Flash no es el problema.
Un punto bastante en común en los debates sobre flash es este. El problema no es Flash, son los desarrolladores.
Desarrolladores que dan la espalda al usuario, que se limitan a complacer al cliente ignorando resultados a medio / largo plazo.
Si eres desarrollador, conoce a tus usuarios, estandariza y desarrolla de forma sostenible.
Si eres cliente, busca desarrolladores que tengan a los usuarios en mente y te ofrezcan soluciones adaptables, medibles, escalables…
Algo más de ayuda para Flash
Eduardo de 2mdc envÃa esta explicación para resolver el análisis de logs en flash de una manera sencilla.
Texto de Eduardo.
Uno de los argumentos utilizados en contra del uso de Flash es que uno de sus puntos fuertes, a saber, la posibilidad de mostrar información bajo petición sin necesidad de descargar información del servidor es, a su vez, uno de sus principales defectos, pues esa interactividad no queda registrada en los logs del servidor que, al fin y al cabo, son la herramienta más utilizada para conocer las preferencias de los usuarios.
Es tÃpico que los â??defensoresâ? de Flash arguyan que existen formas de almacenar mucha más información sobre el usuario utilizando Flash que DHTML o similar y, aunque nos les falta razón (al menos eso creo), sus argumentos se debilitan por la necesidad de utilizar una maquinaria mucho más sofisticada y compleja como bases de datos, lenguajes de scripting, etc., para hacer algo que en HTML y/o sus avatares, se soluciona sencillamente analizando los logs del servidor con herramientas estándar ofrecidas muchas veces gratuitamente por las ISPs.
Mi propósito es mostrar que podemos hacer de forma muy sencilla que la interactividad en Flash sea medida de la misma manera que en HTML pero sin la necesidad de perturbar al usuario con innecesarias descargas ni de complejos (¿y costosos?) desarrollos.
Para establecer los conceptos es conveniente centrarnos en un ejemplo. Supongamos que entramos en la tienda virtual de relojes queHoraEs.com y que buscamos información sobre un modelo de reloj que tiene 3 versiones diferentes, formal, sport y fiesta.
La solución â??no Flashâ? será, normalmente, una página que describe las cualidades generales del modelo y 3 enlaces a los diferentes modelos: formal.html, sport.html y fiesta.html. El usuario interesado exclusivamente en el modelo sport hará clic en el enlace a sport.html, verá la información y, de paso, el dueño de la tienda virtual sabrá cuanta gente está interesada en ese modelo analizando los logs, pudiendo llegar, por ejemplo, a la conclusión de que la mayorÃa de los usuarios sólo están interesados en esta versión, una información de puede ser de gran valor.
En la solución â??Flashâ?, probablemente se descargue una pelÃcula de Flash con las tres versiones del reloj integradas (siempre que esto no obligue a hacer una descarga excesivamente pesada en KBs) con lo que el usuario disfrutará de una experiencia de navegación más integrada, más tipo CD-ROM (con agradables transiciones, etc.), pero que, a priori, tiene el grave inconveniente de que no podremos saber en que versión del reloj ha pinchado el usuario……al menos, no usando los logs de acceso del servidor.
Afortunadamente existe una (muy) sencilla solución a este problema. Solo debemos crear tres páginas web vacÃas en el servidor con los nombres formal.html, sport.html y fiesta.html y añadir una sola lÃnea de código a nuestro botón â??versión formalâ? (y sus equivalentes para las otras dos versiones) en Flash:
loadVariables(â??formal.html?â? + getTimer(), â??â?);
NOTA: Este comando es compatible Flash4 y superior. En vez de â??formal.htmlâ? escribir la ruta real a ese fichero en el servidor. La función getTimer() se utiliza para evitar que el navegador utiliza la versión almacenada en su memoria cache de formal.html (de paso nos sirve para saber cuantos milisegundos han pasado desde que se descargó la página hasta que el usuario hizo clic).
Sin que el usuario note ningún tipo de resultado aparente por esta â??acción extraâ? se registrará una llamada a formal.html en los logs de acceso del servidor y podremos conocer cuántas veces se ha pulsado esta opción, y todo ello con la misma herramienta de análisis de logs utilizada en el caso â??no Flashâ?.
Como podéis comprobar, medir la interactividad dentro de una pelÃcula de Flash no está reservado a â??gurúsâ? de la programación web 🙂