2009-09-21 15 views
5

Otra pregunta aleatoria que me ha afectado (he bebido ~ 9 tazas de café en las últimas 5 horas, lo siento mucho) - ¿Qué tipo de barra de progreso mostrarías a un usuario para una toma que no haces? t saber cuánto tiempo tomaría, pero tiene una buena idea de un tiempo "promedio". Por ejemplo, una tarea que normalmente tomaría alrededor de 30 segundos, pero no tiene manera de saber el progreso (por motivos distintos de su todavía en marcha o simplemente fallado). ¿Cuál sería la mejor UX ?:Barras de progreso para tareas que pueden tomar un tiempo indeterminado?

  • una barra de progreso que comienza siendo rápida y ralentiza (tal vez con el progreso de ser una curva asintótica 1/x el estilo) que llega a 50% en todo el tiempo de la tarea promedio (el estilo del eclipse guía sugiere esto).
  • Una barra de progreso que progresa, lentamente, a un ritmo constante y quizás alcanza el "tiempo promedio" en 15% o algo (IE/Firefox hace esto al buscar inicialmente un dominio)
  • Una barra indefinidamente ondulada (Macs tener esto por todos lados, las versiones de Windows más nuevas lo tienen, también) que solo muestra algún tipo de movimiento sin sugerir ningún progreso, una rueda giratoria o alguna animación que simplemente notifique al usuario que algo está pasando.

¿Sería la respuesta diferente si el tiempo promedio fue de 10 minutos en lugar de 30 segundos?

Gracias, Robert

EDIT:

Para que quede claro, la pregunta es sobre las barras de progreso en la que no tienen ni idea/indicación de cuánto tiempo va a tomar (por ejemplo, la ejecución de una tarea en una máquina remota). Si tiene alguna indicación de progreso, a menudo es bueno usar eso.

+5

Hagas lo que hagas, no lo ejecutes hasta el 99% y lo mantengas allí durante un tiempo realmente largo. Microsoft me hace eso todo el tiempo. –

+4

Ejemplo: http://xkcd.com/612/ –

+2

@ Charlie: tienes razón. Eso es una gran usabilidad no-no. – voyager

Respuesta

6

Los estudios de usabilidad (no puedo encontrar el pdf) mostraron que en la misma duración, cargando barras con diferentes patrones (exponencial, lineal, logaritmig), las que "sentían más rápido" que las que completaban exponencialmente. Con eso quiero decir, los que comienzan lentamente, pero se vuelven más rápidos a medida que pasa el tiempo.

lo que hago normalmente es:

  • Si sé que el tiempo promedio que el proceso puede tomar, Alocate por un poco más, e ir despacio hasta el último 20% -10%, entonces la barra de progreso se acelera y se pone al día con el progreso real, con tal sincronización que el proceso finaliza en el momento en que la barra tiene la velocidad más rápida.
  • Si no sé cuánto tiempo podría tomar, me medir muchas veces para tener el estadio de béisbol (segundos? Minutos a horas?)
    • Si es una operación repetitiva con poca variación entre las corridas, que tienen en cuenta la última vez que corre.
    • Si es una operación de larga ejecución o con alta variabilidad, no uso una barra de progreso, sino una animación para mostrar que estoy trabajando.

Simplemente no lo encuentran a sus usuarios. Nunca dígales que se terminará en un minuto y media hora después de que siga funcionando.

+1

El enlace está aquí: http://www.chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf ... Parece un buen método, pero debe tener alguna idea de cuándo comenzar a acelerarlo. –

+0

Pruebas, pruebas, pruebas. Los datos duros son Dios. Mida la operación bajo diferentes cargas y condiciones. – voyager

+1

Buen estudio, pero ¿es la duración mínima percibida después de los hechos lo más importante? Para realmente utilizar el feedback de progreso, el usuario quiere saber: (a) ¿Debo hacer otra cosa mientras esto se ejecuta? (b) ¿Con qué frecuencia debo consultar? (c) ¿El proceso toma más tiempo del que tengo? (d) ¿Está colgado? Su desafío de diseño es proporcionarle al usuario la información necesaria para responder a estas preguntas lo mejor que pueda. –

1

¿Por qué no incrementar la barra de progreso a medida que completa las tareas en un método?

La duración de la tarea o el proceso es irrelevante, es posible simplemente aumentar el valor de la barra de progreso en X cantidad cuando la parte Y de la tarea está completa o usted está muy avanzado en el proceso. (es decir, cada 5 kilobytes que se procesan en la carga de archivos de 100 kilobytes)

+1

Esto es lo que hago, siempre que sea posible. Si sé que he completado la tarea 2/5, puedo mostrar la barra al 40%. Cuantas más tareas tenga, más suave se incrementa la barra, pero tener una tarea realmente larga hace que la barra se "congele" durante un largo período de tiempo. Personalmente, prefiero tener una barra que se incremente y se congele, que una barra indeterminada que me diga nada más que "todavía está trabajando ... no terminado todavía". –

+0

sí, pero esto se rompe si cada fragmento demora mucho tiempo, p. leyendo desde la web y tarda 10 segundos por fragmento, o 30 segundos para leer cualquier cosa. Parecerá que la descarga se ha estancado – Glen

+0

Soy el mismo Charlie. No quiero estimar el tiempo "normal" que una tarea "debería" tomar porque es muy variable en muchos casos. Calcular el tiempo posible solo puede terminar en frustración. –

3

Definitivamente la barra de progreso del poste Barber. Creo que es el estándar en las pautas de interfaz humana de Mac (HIG). Estoy seguro de que existen barras de progreso "indefinidas" similares para otras plataformas también.

También pondría un indicador de progreso de texto (como la cantidad de bytes transferidos, por ejemplo). "Adivinar" un porcentaje completo puede ser factible, pero definitivamente debe ser muy seguro del tiempo promedio, y su desviación estándar, de lo contrario, se enojarán un montón de usuarios molestos y harán clic en cancelar porque su progreso se ha estancado en 99 % desde una hora. Eso sería muy molesto para ellos y para la reputación de su software.

6

Me estoy convirtiendo en un gran admirador del círculo rotativo estilo Mac y Vista que indica progreso sin configurar las expectativas engañosas del usuario.

xkcd cómica
http://xkcd.com/612/

https://imgs.xkcd.com/comics/estimation.png

+3

Si vas a downvote, al menos deja un comentario indicando por qué lo hiciste. –

+0

Upvoted for awesomeness: -) ... ¡Me encanta! –

3

No importa si la barra de progreso se mueve a una velocidad constante de precisión. De hecho, tomado literalmente, eso seguramente sería casi imposible. ¿Cómo sabría de antemano qué factores podrían entrar en juego para acelerar o ralentizar el progreso real?

Así que escojo cualquier medida conveniente de la cantidad de trabajo que hay que hacer y el porcentaje de seguimiento completo. Si ese es el número de bytes a transmitir, el número de registros a procesar, el número de foos a la barra, lo que sea. Tan seguro, a veces comienza rápido y luego se ralentiza o viceversa. Pero todo lo que realmente importa es que, mientras el proceso avance hacia la finalización, siga avanzando.

Creo que el problema difícil es cuando usted no sabe de antemano NINGUNA medida razonable de la cantidad de trabajo a realizar. Al igual que, debe procesar un conjunto de registros, pero no tiene una forma fácil de obtener el conteo de registros que no sea leer todos los registros y contarlos, y una vez que haya hecho eso, también podría haberlos procesado a lo largo del proceso. camino. En esos casos, en lugar de una barra de progreso usualmente recurro a mostrar un "recuento de progreso": como "1 registro procesado", "2 registros procesados", etc. Al menos el usuario puede ver que se está moviendo, y después de que lo haya hecho Algunas veces, probablemente tenga una idea general de lo lejos que va a llegar, es decir, está en las decenas de miles frente a los cientos de miles o lo que sea.

Estoy trabajando en un sistema ahora que rutinariamente utiliza un enfoque que me parece bastante cojo: simplemente atan porcentajes completamente arbitrarios a cualquier punto de control conveniente. Por ejemplo, si una función lee un montón de datos, los ordena, los formatea y los imprime, dicen que se realiza un 25% de lectura, un 50% cuando se realiza la clasificación, un 75% cuando se realiza el formateo y luego un 100% cuando la impresión está hecha. Supongo que es mejor que nada.

2

Nunca lo he visto, pero qué tal una ventana deslizante sobre una barra de progreso, para que pueda ver si el trabajo está progresando, a qué velocidad, pero el final sigue estando un poco más alejado. Tipo de moonwalking para barras de progreso.Tendrá que hacer que la animación sea distintiva para que el usuario sepa que se están agregando nuevos blobs y los más antiguos están deslizándose hacia la izquierda. El deslizamiento se detiene cuando el programa determina que conoce la distancia hasta el final de la tarea.

+0

¡Es una especie de idea genial! No estoy seguro de si podré implementar eso, pero ... ¡maldición! –

2

La mejor estrategia es ser simple, simple y honesto. Di lo que se sabe y establece la expectativa correcta.

Si puede llevar mucho tiempo, es mejor que sea más explícito, como por ejemplo:

============================================================================== 
    Executing command xyz.. 

    Started: 10:30 AM (usually requires about 20 minutes to complete) 

    Status: 10:35:10 AM.. Still working...{this line needs to update frequently} 

    [Send to background] [Cancel] 
============================================================================== 

he visto tales descripciones detallados en algunas grandes instaladores en alguna parte; no puede recordar exactamente dónde, pero probablemente fue el sistema operativo o el software del servidor. Frases como "Esta tarea puede tardar varios minutos en completarse" tampoco son poco comunes en los instaladores.

Si la tarea generalmente demora un poco en completarse (digamos 30 segundos), pero en ocasiones puede llevar más tiempo, probablemente sea mejor mostrar solo un indicador de que la tarea no está colgada o disfuncional, si y solo si puede ser averiguado. es decir, si puede, asegúrese de que la tarea no esté muerta o colgada. Si tiene tanta incertidumbre como el usuario final sobre lo que está sucediendo con la tarea, lo mejor es simplemente mostrar una opción de fondo (para permitir que el usuario haga otra cosa mientras continúa), o una opción de cancelación (si la tarea puede ser cancelado).

Un ejemplo típico sería una consola de administrador de base de datos que permite al usuario ejecutar una consulta SQL en una base de datos. Normalmente, las consultas se satisfacen en cuestión de segundos, pero con poca frecuencia, hay casos en los que la consulta requiere productos cartesianos grandes, la creación de varias tablas temporales, la espera de que se borren los bloqueos, etc., que puede llevar varios minutos. El software de la consola de administración no tiene ningún medio para determinar cuánto tiempo puede durar la consulta, ya que el servidor de bases de datos solo puede conocer toda la información sobre el tiempo de ejecución esperado de la consulta. En este caso:

  1. no es posible determinar cuánto tiempo llevará.

  2. tampoco es posible determinar si el servidor de base de datos está pegada o colgada en un callejón sin salida

  3. lo peor de todo, no se puede cancelar la ejecución de la consulta.

En este caso, lo único bueno sería dejar al usuario "de fondo" la tarea.

+0

Hmmm ... esto parece genial para las herramientas orientadas a desarrolladores/administradores, pero ¿qué pasa con las aplicaciones para usuarios "promedio"? ¿Los mensajes simplemente los confundirán? –

+0

Podemos objetar sobre el texto exacto. Tal vez algo como, "Por lo general toma de 2 a 7 minutos más o menos" es suficiente para la mayoría de los usuarios. Más importante es el principio de ser honesto con el usuario y no pretender rastrear algo que la aplicación no puede rastrear. Los comentarios basura generalmente son peores que no hay comentarios. –

Cuestiones relacionadas