¿Cuánto tiempo debe rebotar la entrada de texto?

Digamos que tenemos un ejemplo simple como el siguiente.

<input id="filter" type="text" />
<script>

    function reload() {
     // get data via ajax
    }

    $('#filter').change($.debounce(250,reload));
</script>

Lo que estamos haciendo es introducir un pequeño retraso para reducir el número de llamadas a reload mientras el usuario escribe texto en la entrada.

Ahora, me doy cuenta de que esto dependerá de cada caso, pero ¿hay una sabiduría aceptada de cuánto tiempo debe durar el retraso de rebote, dada una velocidad promedio (o tal vez ese debería ser el mínimo común denominador) de escritura/interacción? Por lo general, solo juego con el valor hasta que “se siente” bien, pero es posible que no represente a un usuario típico. ¿Alguien ha hecho algún estudio sobre esto?

Como insinuó, la respuesta depende de una serie de factores, no todos subjetivos.

En general, la razón para hacer uso de una operación antirrebote se puede resumir en uno de dos propósitos:

1. Reducir el costo de proporcionar elementos interactivos dinámicos (donde el costo puede ser computacional, IO, red o latencia y puede ser dictado por el cliente o el servidor).
2. Reducir el “ruido” visual para evitar distraer al usuario con las actualizaciones de la página mientras está ocupado.

Tiempos de reacción

Un número importante a tener en cuenta es 250 ms: esto representa el tiempo de reacción promedio (aproximadamente) de un ser humano y generalmente es un buen límite superior dentro del cual debe completar cualquier actualización de la interfaz de usuario para mantener su sitio receptivo. Puede ver más información sobre los tiempos de reacción humanos aquí.

En el primer caso, el intervalo exacto de rebote dependerá de cuál sea el costo de una operación para ambas partes (el cliente y el servidor). Si su llamada AJAX tiene un tiempo de respuesta de extremo a extremo de 100 ms, entonces puede tener sentido establecer su rebote en 150 ms para mantenerse dentro de ese umbral de respuesta de 250 ms.

Por otro lado, si su llamada generalmente tarda 4000 ms en ejecutarse, es mejor que configure un rebote más largo en la llamada real y, en su lugar, use un rebote de primera capa para mostrar un indicador de carga (suponiendo que su indicador de carga no oculta su entrada de texto).


$('#filter').change($.debounce(250, show_loading));
$('#filter').change($.debounce(2000, reload));


Capacidad de back-end

También es importante tener en cuenta el costo de rendimiento de estas solicitudes en su backend. En este caso, una combinación de velocidad de escritura promedio (alrededor de 44 palabras por minuto, o aproximadamente 200 caracteres por minuto) y el conocimiento del tamaño de su base de usuarios y la capacidad de backend pueden permitirle seleccionar un valor de rebote que mantiene manejable la carga de backend.

Por ejemplo: si tiene un único backend capaz de manejar 10 solicitudes por segundo y una base máxima de usuarios activos de 30 (usando este servicio), debe seleccionar su período de rebote para evitar exceder las 10 solicitudes por segundo (idealmente con un margen de error). En este caso, tenemos el 33,3% de la capacidad requerida para manejar una entrada por usuario por segundo, por lo que idealmente serviríamos como máximo una solicitud por usuario cada 3 segundos, dándonos nuestra 3000ms período de rebote.

Rendimiento de interfaz

El último aspecto a tener en cuenta es el coste de tramitación por parte del cliente. Según la cantidad de datos que transfiera y la complejidad de las actualizaciones de la interfaz de usuario, esto puede ser insignificante o significativo. Una cosa que desea probar y asegurarse es que su interfaz de usuario siga respondiendo a la entrada del usuario. Eso no significa necesariamente que siempre deba poder reaccionar, sin embargo, mientras un usuario interactúa con él, debe reaccionar rápidamente (60FPS es generalmente el objetivo aquí).

En este caso, su objetivo debe ser eliminar rebotes a una velocidad que impida que la interfaz de usuario se vuelva lenta o deje de responder mientras el usuario interactúa con ella. Nuevamente, las estadísticas son una buena manera de obtener esta cifra, pero tenga en cuenta que los diferentes tipos de entrada requieren diferentes cantidades de tiempo para completarse.

Por ejemplo, transcribir una oración de palabras cortas generalmente es mucho más rápido que ingresar una sola palabra larga y compleja. De manera similar, si un usuario tiene que pensar en lo que está ingresando, tenderá a escribir más lento. Lo mismo se aplica al uso de caracteres especiales o puntuación.

Respuesta subjetiva

En la práctica, he usado períodos de rebote que van desde 100ms para datos que son excepcionalmente rápidos de recuperar y presentan muy poco impacto en el rendimiento hasta 5000ms por cosas que eran más costosas.

En el último caso, la combinación de un período de rebote corto y de bajo costo para presentar comentarios al usuario y el período más largo para el trabajo computacional real tiende a lograr un buen equilibrio entre la experiencia del usuario y el costo de rendimiento de las operaciones desperdiciadas.

Una cosa notable que trato de tener en cuenta al seleccionar estos valores es que, como alguien que trabaja con un teclado todos los días, probablemente escribo más rápido que la mayoría de mi base de usuarios. Esto puede significar que las cosas que me parecen fluidas y naturales son discordantes para alguien que escribe más lento, por lo que es una buena idea hacer algunas pruebas de usuario o (mejor aún) recopilar métricas y usarlas para ajustar su interfaz.

Me gustaría ofrecer un respuesta sucinta con respecto a la entrada de texto de búsqueda.

Yo suelo hacer 300msque solo siente correcto teniendo en cuenta tanto el ahorro de recursos de hardware como la provisión de una experiencia de usuario lo suficientemente buena.

—

Un pensamiento interesante…

Tomemos un ejemplo de uno de los maestros: Google.

Si nota (tiene que ser un mecanógrafo rápido), Google en realidad tiene muy poco o ningún tiempo de rebote para los primeros dos caracteres (creo que 2), pero después de eso aumenta el tiempo de rebote. Su objetivo principal, obviamente, es dar una sensación instantánea y equilibrar su interfaz de usuario con casos de uso. No sé qué datos o estudios han hecho, pero los han hecho y son un buen ejemplo cuando una entrada de búsqueda es la función principal de un sitio.

Con eso, diría que esta es una excelente experiencia de usuario, aunque con mayor complejidad y tiempo de programación. Google lo necesita. Una barra de búsqueda utilizada con menos frecuencia podría ir sin complejidad adicional, tal vez.