¿Cuánto tiempo puede tomar para que aparezca una pantalla antes de que se considere un problema de rendimiento?


12

Estoy involucrado en el desarrollo de una aplicación de Windows que tiene varias pantallas. Uno de ellos tarda diez segundos en aparecer sin ninguna flecha giratoria u otra indicación de que la pantalla se está cargando. Considero que esto es un problema grave de rendimiento, pero parece ser el único preocupado.

¿Estoy siendo demasiado celoso? ¿Cuál es un período de tiempo aceptable para esperar a que aparezca una pantalla?


2
¿Son 10 segundos en la máquina de gama alta de un desarrollador, o 10 segundos en la máquina de días mejores vistos por el usuario promedio?
MZB

@MZB: 10 segundos en la máquina del desarrollador ...
azul

@ 8kb, ¿cuál es el problema que hace que la pantalla tarde tanto en aparecer?
AttackingHobo

3
Android recordará una pantalla atascada después de 5 segundos, si no recuerdo mal. Luego le preguntará al usuario si quiere matar la aplicación o seguir esperando.
Federico klez Culloca

Respuestas:


23

Esta es una investigación antigua pero 10 segundos es mala:

http://www.useit.com/papers/responsetime.html

de la página:

El consejo básico con respecto a los tiempos de respuesta ha sido casi el mismo durante treinta años [Miller 1968; Card y col. 1991]:

• 0.1 segundos es aproximadamente el límite para que el usuario sienta que el sistema está reaccionando instantáneamente, lo que significa que no es necesaria una retroalimentación especial, excepto para mostrar el resultado.

• 1.0 segundo es aproximadamente el límite para que el flujo de pensamiento del usuario permanezca ininterrumpido, aunque el usuario notará el retraso. Normalmente, no es necesaria una retroalimentación especial durante demoras de más de 0.1 pero menos de 1.0 segundo, pero el usuario pierde la sensación de operar directamente sobre los datos.

• 10 segundos es el límite para mantener la atención del usuario centrada en el diálogo. Para retrasos más largos, los usuarios querrán realizar otras tareas mientras esperan que la computadora termine, por lo que se les debe dar retroalimentación que indique cuándo la computadora espera que se haga. La retroalimentación durante el retraso es especialmente importante si es probable que el tiempo de respuesta sea muy variable, ya que los usuarios no sabrán qué esperar.


1
Nunca deje a un usuario preguntándose si acaba de romper el software, incluso una pequeña ventana de recordatorio que aparece inmediatamente con un tiempo previsto para finalizar detiene la ansiedad del usuario final y los deja sintiéndose en control.
Patrick Hughes

44
Yo diría que los datos de tiempo están desactualizados, ya que se escribieron hace unos 20 años. Hoy, con una máquina increíblemente poderosa en cada escritorio y la proliferación de interacción en tiempo real, las personas están acostumbradas a tiempos de respuesta mucho más cortos que 10 segundos.
Eran Galperin

2
Estoy de acuerdo en que 10 segundos es demasiado tiempo para que aparezca una pantalla sin ningún comentario. Para cualquier cosa que tarde más de ~ 2 segundos, probablemente pondría (al menos) una rueca para mostrar que el programa está haciendo algo , si no una barra de progreso.
DMan

1
Los datos se refieren a los procesos de pensamiento de una persona. Como tal, probablemente no esté tan desactualizado. Sin embargo, 10 segundos sin comentarios son demasiado largos en estos días. Existen técnicas para mejorar la capacidad de respuesta percibida.
BillThor

9

Más de dos segundos sin un reloj de arena y ya soy bastante escéptico. Diferentes personas tendrán algunas expectativas diferentes, pero esperaría 10 segundos sin comentarios para reconocer que hice clic en un botón o lo que sea que moleste a casi cualquier persona. Si importa o no molestar a sus usuarios es otra cuestión.


De acuerdo: debe abrir un "cursor de espera" o alguna otra indicación muy rápidamente. Según las normas UX, prefiero verlo en algo así como 0.1 a 0.25 segundos en lugar de dos segundos.
Bob Murphy

3

¿Qué piensan los usuarios previstos de esta aplicación? Si están de acuerdo, no se preocupe. En algunas aplicaciones que tienen que procesar muchos datos, está bien que un comando de apertura de ventana tenga un poco de retraso antes de abrirse.

Si es posible agregar una pantalla de bienvenida o una barra de progreso o algo para indicarle al usuario que está funcionando, sería bueno. Por lo general, trato de agregar un indicador de progreso de algún tipo si mi prueba muestra que una ventana tarda más de 2 a 4 segundos en aparecer.


1

Respetamos la regla de que no debería tomar más de 2 segundos para que CUALQUIER comentario aparezca para el usuario.

Dije cualquier comentario porque hay momentos en que no es posible cargar toda la página en 2 segundos. Debe informar a los usuarios qué esperar después de los primeros 2 segundos.


1

Aunque DKnight cita una buena investigación en su respuesta , otra cosa a considerar sería los requisitos de rendimiento del sistema. ¿Los usuarios realizan algún tipo de trabajo urgente o por alguna razón necesitan requisitos rápidos? Si de alguna manera puede preguntar a los usuarios qué tiempos de respuesta les gustaría ver, especialmente en términos de tiempos mínimamente aceptables, sería lo mejor. Realizar pruebas de usabilidad con observación también sería bueno para la usabilidad general, y si ve que un usuario se frustra por esperar después de realizar una acción específica, entonces sabe que debe volver a visitar el rendimiento de esa parte del sistema.

Sin embargo, en términos de generalidades, sospecharía que 10 segundos es realmente mucho tiempo. Hay algunas operaciones de larga duración, y si este es el caso, es importante proporcionarle al usuario señales de que el sistema todavía está funcionando y continuar esperando.


0

Estoy de acuerdo en que 10 segundos son definitivamente demasiado. Trabajé para aplicaciones de intranet en una Casa de software (utilizada solo internamente por los empleados) y el retraso máximo durante la carga de una página fue de 5 segundos. Este fue para mí el límite.

Sin embargo, vi otras aplicaciones internas, muy complejas, pero donde el tiempo de carga era algo dramático. En la peor situación, debido a miles de registros / consultas ejecutados, ¡tomó alrededor de 2 minutos! Pero, por supuesto, esto está muy lejos del contexto general.

Por lo tanto, concluiría diciendo que 3 o 4 segundos son el límite para proporcionar un buen servicio de respuesta.


0

Este no es un problema de rendimiento como tal, sino un problema de GUI. Se debe decir al usuario lo que hace el programa y, si tarda más de 1-2 segundos, se debe mostrar una barra de progreso.

Dicho esto, podría haber una RAZÓN para esto, si solía ser rápido, pero eso no es lo que pediste.

El problema típico con tales aplicaciones se está quedando sin memoria física, por lo que Disk I / O se convierte en el cuello de botella para cargar e intercambiar. También podría ser simplemente que los conjuntos de datos han crecido tanto que el algoritmo O (N ^ 3) ahora brilla.


Creo que una barra de progreso solo debe usarse si se conoce la duración o las tareas totales. De lo contrario, debería usarse algo más indeterminado.
Thomas Owens
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.