Babelia

Las estructuras de navegación son elementos fundamentales en un portal web. Los errores relacionados con menús y enlaces de navegación son generalmente críticos, debido a que son los mecanismos que el usuario emplea para navegar y explorar un sitio.

Los portales cuya arquitectura de información es demasiado profunda, tienden a ofrecer al usuario menús desplegables de múltiples niveles para “asegurarse de que todo está a la vista.”. Sin embargo, lejos de ser una buena práctica, el uso de menús desplegables de más de dos niveles es uno de los atentados más grandes contra el éxito de un portal.

Entre las razones por las cuales no se deberían usar menús desplegables de múltiples niveles están:

• Los menús con demasiados niveles son difíciles de manipular. Generalmente el usuario cree que la distancia más corta entre dos puntos es una línea recta. Al cruzar en diagonal hacia un nivel desplegado los menús tienden a cerrarse.
• Los menús de múltiples niveles generalmente contienen muchos elementos, por lo que sobrecargan la memoria del usuario y le hacen más difícil aprender a usar el sitio.
• El problema se agrava si el menú tiene un comportamiento aleatorio. Por ejemplo se abre a izquierda o derecha según se va navegando.
• Si los elementos de navegación son difíciles de usar, el usuario no podrá explorar el sitio web.
• Si se combinan menús desplegables de varios niveles, con el uso de texto falso en sus elementos, el error es aún más grave.

Una buena práctica, es el uso de menús desplegables verticales (de solo dos niveles), o incluso un menú simple con enlaces (un solo nivel). Al reducir las posibilidades, el usuario podrá tomar sus decisiones más rápido, y seguramente una navegación de contexto le dirá adónde ir dentro de un nivel mucho más específico.

De www.leandrodonofrio.com me traigo un post con las premisas básicas a la hora de optimizar un swf

¿Mejorar el peso para qué?

Simple. No todas las personas que entren a nuestro sitio tendrán una conexión de banda ancha y no hay nada más feo que entrar a una web hecha en Flash y ver al preloader sumar byte por byte…

Hoy en día son pocos los sitios en Flash que cargan todo el contenido de una sola vez. Habitualmente lo que se hace es dividir el sitio en varias películas e ir cargándolas a medida que el usuario lo requiere. El tamaño de cada película va a depender de la complejidad del sitio.

Lo ideal seria tener una presentación liviana e ir cargando las películas externas con un peso no mayor a 40 KB aunque como bien dije todo va a depender de la complejo que sea la web.

Asi que empecemos a hablar un poco sobre el tema…

• Por lo general cuando estamos desarrollando un trabajo en Flash solemos repetir elementos en el escenario (Botones, MovieClips, Gráficos, etc). ¿Para qué dibujar lo mismo varias veces cuando podemos tener mismos símbolos con diferentes propiedades? La utilización de instancias de símbolos ayuda a bajar el tamaño final. Por ejemplo si necesitamos dos círculos de diferentes tamaños y colores, no vamos a crear dos círculos diferentes, sino creamos uno, lo convertimos en símbolo y lo copiamos en el escenario. Luego con los paneles modificamos el color y tamaño de cada uno;

• El entorno de autor de Flash fue pensado como el escritorio de un dibujante/animador. Sin embargo si necesitamos realizar alguna animación en movimiento no es recomendable realizarla fotograma por fotograma sino utilizar Interpolaciones de Movimiento debido a que Flash realiza varios cálculos complejos para crear la animación y optimizar el archivo final en peso;

• Con los mapas de bits podemos crear texturas que con vectores no podemos. Sin embargo utilizarlos incrementa varios KB al archivo final. No quiero decir que nunca hay que utilizarlos, son necesarios en muchas ocasiones, por ejemplo como fondos estáticos. Si los vamos a utilizar tratar de comprimirlos lo mejor posible sin perder mucha calidad. Para eso podemos utilizar la opción Exportar para web en Photoshop o utilizar programas como el PIXresizer;

• Al utilizar cualquier componente incrementaremos 30 KB el archivo final . Para evitar esto podemos buscar alternativas o construir nosotros mismos al elemento suplente;

• Una de las ventajas de Flash es la posibilidad de mostrar textos estáticos con cualquier tipografía. En contrapartida si utilizamos fuentes muy complejas (ejemplo: Cocaine sans) ó fuentes incrustadas (en caso de utilizar textos dinámicos o de entrada) incrementaremos el peso del archivo final. Si tan solo deseamos mostrar un texto podemos utilizar fuentes pixeladas que son mucho más livianas o usar fuentes standards como Arial, Verdana, etc;

• Sigo con el tema de las fuentes, si utilizamos fuentes incrustadas, solo incorporar los caracteres necesarios;

• Al incorporar música al sitio, probar con distintos bitrate hasta encontrar un sonido entendible, no distorsionado y no muy desproporcionado en peso;

• Optimizar el código y no repetirlo. Utilizar funciones genéricas que puedan ser reutilizadas. Habituarse a usar un código centralizado y no desparramado por diferentes elementos. Utilizar más o menos comentarios dentro del código no afecta al archivo final ya que Flash no los incorpora al exportar el swf;

Aquí os dejo un link (a recursos vectoriales) con unas cuantas páginas donde se pueden sacar recursos para unas prisas

De itespresso.es me traigo este post sobre la polémica de la utilidad de flash.

******************************

Microsoft anuncia que su navegador reproducirá solo H.264.

Adobe no está pasando por su mejor momento. Tras la carta de Steve Jobs explicando por qué no le gusta Flash, Microsoft acaba de anunciar que la próxima versión de Internet Explorer, IE9, también dejará fuera al formato de Adobe y reproducirá únicamente H.264.
Dean Hachamovitch, Manager General de Internet Explorer, explicó en un post en su blog corporativo que aunque HTML5 (”el futuro de la web”) permite vídeo sin especificar un formato determinado, en Microsoft creen que H.264 es una opción “excelente”, por lo que “IE9 solo reproducirá H.264″.
Podría parecer así que Microsoft se une a Apple en su guerra contra Adobe, pero las palabras de Hachamvitch apuntan en otra dirección. Si bien afirmó que Flash tiene problemas de “fiabilidad, seguridad y rendimiento”, también aclaró que en Microsoft trabajan con los ingenieros de Adobe de forma continua, “compartiendo información” sobre estos puntos.
Dean Hachamovitch dedica dos párrafos de su entrada a explicar la cuestión Flash, incidiendo en la comunicación continua y el trabajo conjunto para resolver problemas. No es descartable por lo tanto que en un futuro, y una vez que Adobe haya mejorado en esos aspectos, IE9 vuelva a abrir la puerta a Flash.