La mejor barra de progreso: el procesoArtículos
Todos conocemos la venerable barra de progreso, es algo así (o alguna variante):
Los expertos del diseño de interfaz recomiendan usarla para procesos que pueden tardar más de algunos segundos. Aunque definitivamente es mejor a sentir bloqueada la computadora, no es la solución idónea.
Un ejemplo de la vida real: acompañas a un familiar al doctor. El doctor te dice que puedes estar presente durante la consulta, o puedes quedarte en la sala de espera. La gran mayoría escogería estar presente durante la consulta; no precisamente por solidaridad, sino porque saben que se van a aburrir si se quedan en la sala de espera (prefiero taladrearme el cráneo antes que leer una de las abominables revistas que tienen ahí).
Este fenómeno tiene un paralelo en la web: está bien documentado que la percepción del tiempo de descarga de una página tiene más que ver con la rapidez en la que se muestre algo visible en la pantalla, sin importar tanto el peso total de la página. Ahora imagínate que cada vez que entres a una página se muestre algo así:
Y no se muestre nada hasta que la página haya terminado de descargar por completo, con imágenes y todo (de alguna manera me recuerda los sitios hechos en Flash). Con algunas excepciones en las que los datos procesados simplemente no se pueden mostrar visualmente, siempre es mejor mostrar el proceso a mostrar una barra de progreso.
En iTunes, cuando agregas canciones nuevas, observas visualmente aquellas que han terminado de cargar:
De acuerdo a las Human Interface Guidelines del iPhone, primero te muestra una imagen de cómo es el programa antes de cargarlo con datos reales (después de todo, un ícono brincando en el dock o la pantalla de inicio de Photoshop son el equivalente a una barra de progreso).
Nota curiosa: esta es una idea original de Jeff Raskin, la cual implementó en el comercialmente fallido Canon Cat. Cuando introducías un disco te mostraba rápidamente una captura de pantalla del último documento que tenías abierto, y mientras tratabas de recordar en qué parte te habías quedado, la computadora cargaba el documento real tras bambalinas. Muy poca gente se daba cuenta de esto.
Disco, un programa para grabar CDs en Mac, muestra visualmente cómo se quema el disco. El humito es puro eye candy pero también difícil de resistir.
Un ejemplo hipotético
Supongamos que queremos aplicar este principio a la herramienta para subir imágenes de Flickr:
En realidad es aplicable para cualquier programa que involucre imágenes: imagina que Photoshop, en lugar de mostrar una barra de progreso al aplicar un filtro, vaya mostrando el proceso. O un programa para escanear vaya mostrando la parte escaneada (estoy seguro que ya lo hacen, pero no lo he visto personalmente).
Otros ejemplos: cuando exportas un video, te va mostrando los cuadros que va guardando (y así puedes darte cuenta de algún problema de compresión, por ejemplo), o inDesign te puede ir mostrando las páginas de un archivo que guardas como PDF. En realidad el problema se puede reducir a una pregunta: "¿Se puede visualizar?", y si la respuesta es sí, entonces es mejor prescindir de la barra de progreso.
En realidad el problema se puede reducir a una pregunta dos preguntas: "¿Se puede visualizar?" Y "¿NO CONSUME DEMASIADO TIEMPO EL HACER QUE SE VISUALIZE?", y si la respuesta es sí a ambas, entonces es mejor prescindir de la barra de progreso ...
Saludos!
Mario
Excelente...
Al objetivo de la barra de progreso en manejar las espectivas del usuario.
Como usuarios queremos saber 2 cosas.
1) ¿Está funcionando todo bien?
2) ¿Cuando termina?
La primera pregunta se puede resolver con un mensaje al final del proceso.
La segunda con un estimado de tiempo. Pero solo tiene sentido cuando puede liberar al usuario de la espera.
Para seguir con el ejemplo del medico, si te dicen "puede irse a tomar un café, vuelva en una hora" la informacion es util. Si en cambio no podemos movernos del lugar o el tiempo no es suficiente para realizar otra tarea simplemente no aporta informacion.
La barra de progreso es util cuando libera al usuario para realizar otra tarea, no siempre es posible.
Excepto por algo mas sutil... aunque no tengamos control sobre el proceso nos gusta controlarlo, es como si quisieramos prueba de que el sistema está haciendo su trabajo correctamente.
En lo personal cuando desfracmento el disco no puedo evitar mirar los bloquesito de colores moviendose de un lado para otro. Lo se es una tontera, pero no lo puedo evitar.
El mostrar el trabajo parcial es una muy inteligente forma de dar "pruebas" que el trabajo esta siendo realizado correctamente. La informacion puede tener un valor marginal. Pero no deja de ser util.
Buenos comentarios los de Alejandro.
En cuanto al flickr, haz notado como puedes bajar imágenes en forma progresiva? Entonces lo que tendría que pasar es que el flickr durante su rutina de uploading debe leer del archivo mismo atributos como el alto y el ancho para luego hacer un mapeo a la rejilla de imágenes subidas, así obtendrías un thumbnail de la forma a tu imagen original y entonces asumiendo que el checksum o el chequeo de errores está bien resuelto (durante la transmisión y recepción de los paquetes con el contenido del archivo de imagen), por cada uno de los pedacitos en el que tomaría en cuenta el programa como porcentaje de avance, se haría un almacenamiento temporal del contenido y entonces seguiría un downsampling que daría pie a los pixeles que pondrías en ese contenedor (donde estás viendo el avance)...
Creo que el pecsi aquí es que durante la ida (el proceso de uploading), tendrías que hacer un downsampling eficiente (sobretodo si las imágenes son muy grandes) supongo que en el mismo host porque (ahí están llegando las imágenes) pero cada vez entonces tendrías que mandar de vuelta esta versión muestreada, lo cual sería poco pero no se si podría considerarse despreciable mientras se hace el uploading...
Te has fijado que mac trabaja mucho con imagenes submuestreadas, no has visto si hace algo como dices al subir al .mac?
Saludos.
Me quedo con el detalle. ¿Te gustó el disco de Dover que aparece en la captura? Yo prefiero los primeros. Por supuesto de rock no tiene nada.
Saludos. :)
No alcanzaré el nivel de Alejandro... igual, mi pequeño aporte es el siguiente:
En mi experiencia personal, encuentro que la principal utilidad de la barra de progreso es la "2) cuándo termina?". Encuentro que una espera resulta menos tediosa o en el mejor de los casos más llevadera cuando sabemos cuánto falta para el final.
A veces incluso, entre dos esperas de la misma duración, aquella en la que conocemos cuánto tiempo resta se percibe como más corta. ¿No les ha pasado que cuando viajan a un lugar nuevo el viaje de regreso parece más corto que el de ida, aunque (por supuesto) tenga la misma distancia y generalmente la misma duración (a veces más si nos topamos con el tráfico de regreso, je je)?
Independientemente de que la barra de progreso ayude a percibir la rapidez o lentitud de la descarga de un sitio, tambien sirve como indicador que existe una descarga y que esta funciona. La velocidad de la conexion puede variar muchisimo en los n segundos que se tarda en bajar un sitio. Lo ideal seria que la pagina te mandara una ventana de error cuando la conexion se perdiera o fuera super lenta (con lo que tendrias que activamente refrescar). Supongo que no debe ser facil programar eso pues rara vez se usa, entonces la barra es otro medio para saber si hay algun problema con la bajada del sitio. Ahora a diferencia de las partes de un sitio, es mas facil saber que si despues del 50% ya no aparecio un 60% tuviste un problema con la conexion /navegador/plug in. En cambio no siempre vas a saber si despues de la parte x de un sitio va a seguir otra cosa
Estoy de acuerdo con lo que escribiste, es algo muy importante para tener en cuenta.