Alpha's Manifesto

A black and white figure's thought-hive

Barras de progreso y velocidad aparente

La gran diferencia del detalle

Indicando progreso

Hemos visto como a través de los años las interfaces de los sistemas operativos y las distintas aplicaciones (también las web) han evolucionado y cambiado radicalmente su aspecto visual. Muchos más colores, formas redondeadas, animaciones y feedback que nos indica qué está pasando a cada momento.

Uno de los elementos que más cambio ha tenido son los indicadores de progreso. Desde las líneas que giraban simulando un progreso, usando los caracteres -, /, | y \ en una consola, hasta el uso de caracteres Unicode con barritas que se iban llenando, hasta las hermosas interfaces de hoy de colores y animaciones.

Cabe aclarar que los indicadores de progreso vienen en dos sabores. Uno de ellos es el indicador de progreso indeterminado, el cual indica que hay un progreso ocurriendo de fondo en nuestra aplicación, pero sin indicar qué tan cerca estamos de terminar esa operación. Muchos de estos hemos visto en Youtube y distintas páginas que hacen uso de ajax. Wikimedia tiene una linda galería de estos, pero para ejemplo, aquí tienen uno:

Loader

El otro tipo de indicador es la barra de progreso propiamente dicha. Esta barra es el concepto básico que indica un límite en donde el trabajo ha sido terminado y nuestra posición respecto de completar esa tarea. Una búsqueda en Google Images devuelve muchas, muchas imágenes para saber de qué estamos hablando, y mejor aún, PrettyLoaded es un sitio (Flash) con una galería continua de pre-loaders que reutilizan este concepto con distintas formas.

Progress bar

Jugando con la mente

Ahora, asumiendo que una tarea siempre tarda el mismo tiempo, el indicador de progreso puede hacer una diferencia en la velocidad aparente que como usuarios percibimos, y podría ser bien la diferencia entre cancelar una descarga que signifique una compra o esperar unos pocos segundos más. Esta velocidad percibida es también llamada velocidad aparente, y si bien está relacionada a la velocidad real, hay otros factores que pueden hacerla aparentemente mayor o menor.

La velocidad aparente se encuentra afectada por muchos factores, como bien publicó Anthony, de UXMovement, en el artículo llamado How to Make Progress Bars Feel Faster to Users. A diferencia de muchos artículos que se encuentran en la internet, este está respaldado por estudios de la gente de Carnegie Mellon University, de los Laboratorios de Investigación de AT&T, y de la Universidad de New York. (Los links están al final del mismo.)

Las características que mencionan aquí son las siguientes:

Animación en sentido contrario

Una característica de las nuevas interfaces ha sido la capacidad de entrelazar imágenes en estos mismos indicadores. Muchas veces es una forma de demostrar que la aplicación sigue funcionando aunque la barra de progreso mantenga su posición, de la misma forma que el caracter que giraba nos indicaba también que el programa seguía funcionando. Sin embargo, el tipo de animación también puede tener un efecto sobre la velocidad aparente del progreso general.

Y lo que han descubierto es que cuando esta animación se mueve en sentido contrario a la dirección de progreso de la barra, la sensación de velocidad es mayor.

Utilizar pulsaciones frecuentes

Los indicadores de progreso (tanto barras como indeterminados) pueden hacer uso de pulsaciones como parte de la animación. Esto es más común en las barras de progreso, en donde todo el color de la barra es cambiado por un momento y vuelve a su estado normal, repitiendo esta acción cada tanto tiempo, dando la sensación de una pulsación.

Los estudios demostraron que mientras más frecuentes son estas pulsaciones, mayor es la velocidad aparente. Por supuesto, puede que no resulte agradable al ojo del usuario si es demasiado frecuente. Un truco extra también mencionado es que a medida que nuestra barra está avanzando, la frecuencia de las pulsaciones puede ir aumentando, también generando la sensación de un aumento en velocidad, incluso aunque realmente no sea tal.

Acelerar el progreso

Supongamos por un momento que el progreso de nuestra tarea es fijo, y que cada tantas unidades de tiempo, siempre tendremos tantas otras unidades de avance en nuestro progreso. Mantener esa monotonía de avance es, si bien realista, no la mejor opción para dar la sensación de progreso. Según mencionan los estudios, incrementar la velocidad del progreso hacia el final genera una sensación de menor tiempo insumido en la tarea en general, incluso aunque los tiempos suma sean los mismos.

Recuerdo haber leído que entre Windows Vista y Windows 7, este había sido uno de los cambios de interfaz en el momento de copia de archivos, a pesar que la estrategia de copia de archivos no había cambiado, y la diferencia era notable. Desafortunadamente, no logro encontrar el artículo en donde originalmente leí eso.

Evitar pausas al final

La pausa final, que ocurre muy comunmente si se está haciendo un procesamiento al final de la tarea, arruina la sensación completa de velocidad que el proceso había ganado. Por supuesto, seguramente estemos en un punto en donde el usuario ya no decide cancelar la acción, pero con ella hemos logrado arruinar la sensación de un proceso rápido que el usuario sentía. Esta puede ser la diferencia entre volver a usar nuestro sistema o no en un futuro, así que cuidado.


Los estudios originales son:

Soy un zorrinito con progreso.

Link del día: Performance HTML5, CSS3 y DOM, Parte 2: Performance HTML5

Hay varias formas de aproximarse a la performance de una aplicación que está construida bajo los nuevos estándares e implementaciones de HTML5, CSS3, y, por supuesto, JavaScript. Como ya lo habíamos mencionado en la parte 1 de este artículo, el tutorial de HTML5 Rocks llamado Improving the performance of your HTML5 App trata varios puntos que son importantes para lograr una buena performance y una aplicación sólida.

Repasémoslos rápidamente:

  • Delegar animaciones al browser siempre que sea posible
    • Transformaciones y trancisiones con instrucciones CSS
    • Renderización “incentivada” a ser a través del GPU con [code lang=”css”]-webkit-transform: translateZ(0);[/code]
    • Separación de threads de animación con [code lang=”javascript”]window.requestAnimationFrame[/code]
  • Profiling de JavaScript
    • Utilizar el DOM lo menos posible
    • Nombrar funciones anónimas para identificar dónde están los problemas más fácilmente
    • Refactorizar el código
    • Crear funciones definidas y autollamadas si hacer métodos más pequeños no se puede (de esa forma “nombramos” parte del código)
  • Utilización del DOM
    • Lo menos posible (nuevamente)
    • Cachear elementos cuando tenga sentido
    • Hacer lecturas, luego modificaciones, luego escrituras para evitar reflows
    • No usar el DOM dentro de loops
  • Inicialización tardía
    • Delegación de eventos en lugar de asociación de handlers

Y eso es, a muy grandes rasgos, este artículo. Realmente recomiendo que le den una leída a fondo si ustedes trabajan del lado de la web. Realmente no verán una página de la misma manera.

Soy un zorrinito performante.

Link of the day: Procedurally speaking…

Remember that link where I spoke about different algorithms? I made a quick reference to Pixel City. If you had the chance to see it, and furthermore, if you have had the chance to download it and test it yourself, you might have seen that for a really little binary executable we can get really great things.

That’s because of content procedural generation, this means that the data you see is not configured or saved anywhere, it is just created in the moment that it is needed, with a set of rules that make sure that the result is close as expected.

Of course, this isn’t something new, lots of games already make use of this technique and not even that, there are a couple of games made entirely on this fashion. You should check out .kkrieger, a 96k 3D full level FPS game. That’s right. 96k.

You should also check Synth, an almost 100% procedural generated game, where even the music is generated in real time.

There’s also a nice experiment with procedural animation and genetic algorithms called Creepy Crawlies. In this application, you can create a creature with a certain configuration of bones (fixed length), claws (points it can grab on to) and muscles (parts it can expand/collapse), and the genetic algorithms will make it evolve so it grows up to the best locomotion technique. The animation is done procedurally too.

I’m a generated little skunk.