Sobrescribir el atajo de teclado del navegador para "buscar en la página"

Hola, soy fan de Discourse, de una pequeña comunidad que está hablando de migrar desde vBulletin5. Una persona se opuso a Discourse porque «secuestrar Ctrl+f es malvado» y, tras ver lo que querían decir, tengo que estar de acuerdo. Hay un problema grave de usabilidad en cómo Discourse maneja actualmente Ctrl+f, que es el atajo del navegador para «Buscar texto en esta página».

El problema

  • A veces, Ctrl+f funciona como debería y Discourse utiliza la función de búsqueda integrada del navegador para que la página se desplace inmediatamente al primer resultado mientras escribes. Ctrl+G te lleva al siguiente resultado.
    • La vida es buena.
  • A veces, Ctrl+f no funciona y, en su lugar, muestra una lista de resultados de una búsqueda en la base de datos.
    • No desplaza la página al primer resultado mientras el usuario escribe.
    • La frase de búsqueda solo se resalta si por casualidad ya está en pantalla.
    • No permite buscar términos demasiado cortos, como «UX».
    • No acepta Ctrl+G para mostrar el siguiente resultado.
    • Sí muestra resultados para temas irrelevantes que Ctrl+f no habría mostrado si no hubiera encontrado el término en la página.
  • Por qué falla esto es completamente invisible para los usuarios, pero es extremadamente frustrante. Sienten que se les ha quitado la capacidad de buscar dentro de una página sin ninguna explicación.
  • No ayuda decirles que presionar Ctrl+f dos veces hará una búsqueda del navegador, ya que eso no encontraría publicaciones que realmente existen.

La causa raíz

Esto no es un problema cosmético, sino un problema fundamental de usabilidad que Discourse tendrá que solucionar en la raíz: la ilusión de que toda una conversación está realmente en el DOM del navegador, cuando en realidad se carga dinámicamente.

Cuando hay más de veinte publicaciones en un tema, Discourse envía las publicaciones al navegador solo cuando son necesarias. Podrías ver un hilo de más de 1000 publicaciones con casi ninguna carga en el servidor, ya que la mayor parte del DOM son solo esqueletos vacíos. Es una idea brillante, pero también es lo que hace que Ctrl+f deje de funcionar misteriosamente.

No estoy sugiriendo eliminar la ilusión, ya que creo que vale la pena. Discourse tuvo razón al abandonar la antigua forma de dividir las conversaciones en páginas arbitrarias con unas 40 publicaciones cada una.

Discourse solo necesita hacer un mejor trabajo para que la ilusión sea fluida.

Soluciones

Para ser honesto, no sé cuál es la mejor solución, pero tengo algunas ideas que espero que sean útiles.

Romper conscientemente la ilusión

Primero, aquí hay algunas ideas simples que son razonables si Discourse va a romper la ilusión al cambiar a una búsqueda en la base de datos:

  1. Informar al usuario de lo que está sucediendo. Colocar una pequeña nota donde normalmente aparecería el cuadro de búsqueda del navegador, con una disculpa y una explicación.
    • «Lo sentimos, pero este tema tiene 1002 publicaciones, pero tu navegador solo tiene cargadas 7 de ellas, por lo que «Buscar en la página» probablemente no funcionará. Si quieres intentarlo de todos modos, pulsa Ctrl+f de nuevo».
  2. Permitir que el usuario tenga cierto control. Cuando un usuario pulsa Ctrl+f, mostrar un botón para que los usuarios puedan cargar manualmente el texto de todas las publicaciones del tema en el DOM.
    • Si esto se considera imposible debido al límite de 100 publicaciones almacenadas en caché en el navegador a la vez, entonces mostrar un botón que permita a los usuarios volver al antiguo método de ver temas: divididos por página.
    • «Haz clic aquí para ver este tema de una manera que funciona con Ctrl+f: [Página 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]»
  3. Aumentar el límite predeterminado de 20 publicaciones a 100. Esto podría no ser demasiado difícil de cambiar, ya que Discourse ya es capaz de almacenar esa cantidad de publicaciones en caché en el DOM.

Reparar la ilusión

Por supuesto, esas ideas son poco estéticas y las considero solo soluciones temporales. Eventualmente, la mejor solución sería que Discourse implementara Ctrl+f de una manera que funcione como las personas esperan. Replicar en Discourse lo que hace el navegador para buscar interactivamente sería muy valioso, pero imagino que sería difícil.

Sin embargo, podría haber una solución (relativamente) sencilla.

No eliminar texto del DOM

Creo que la mejor solución para Discourse es eliminar solo los objetos multimedia de las publicaciones, no el texto. De esta manera, no habría necesidad de «secuestrar Ctrl+f» y reemplazarlo con una búsqueda en la base de datos.

«Buscar en la página» solo busca texto, por lo que no es necesario que el navegador tenga todo el DOM cargado para poder buscar en él. El texto es increíblemente ligero de enviar, especialmente si el servidor HTTP tiene activada la compresión gzip. El texto tampoco ocupa mucha memoria en un navegador web.

Ustedes lo sabrán mejor que yo, pero tengo algunas suposiciones:

  • Tamaño promedio de una publicación: 5 KiB de texto.
  • Longitud promedio de un tema: 50 respuestas.
  • Texto promedio a transferir: 250 KiB, lo que parece razonable.

Por supuesto, cada byte importa para la capacidad de respuesta. Si mis estimaciones son incorrectas y el tamaño del texto es un problema, llenar el DOM con texto podría hacerse como un proceso en segundo plano después de que se hayan enviado las partes importantes de la página. Si el DOM no se ha completado completamente con texto en el momento en que el usuario pulsa Ctrl+f, puede aparecer un medidor, informando al usuario que espere y mostrando el progreso a medida que el texto va llegando poco a poco.

Gracias

Aunque es un problema grave que Ctrl+f rompa la ilusión que crea Discourse, estoy impresionado con el increíble trabajo que hicieron los desarrolladores de Discourse al crear esa ilusión desde el principio. Estoy seguro de que eventualmente encontrarán la solución adecuada para esto también.

Gracias por tomarse el tiempo de considerar mis sugerencias.

Atentamente,

Mx. F.N.

3 Me gusta

Comparto tu sensación de que la experiencia de usuario (UX) aquí es frustrante y sorprendente. Para mí también es incómodo intentar hacer scroll hacia arriba y hacia abajo en un hilo simple de 30 temas. Es lo único de Discourse que me avergüenza.

Me pregunto si el equilibrio entre una buena UX en hilos pequeños y medianos y no romper los hilos grandes es realmente el adecuado. En mi proyecto, es poco probable que los hilos muy grandes sean un problema significativo, por lo que es frustrante que la UX se vea comprometida por sus necesidades.

Recuerdo haber leído que el verdadero problema que limita el enfoque actual es el tiempo de renderizado en Android. Si ese es el caso, parece una lástima limitar todos los dispositivos basándose en las limitaciones de algunos.

Me encantaría saber si es razonablemente posible para un desarrollador personalizar:
(1) el número de temas por bloque (por ejemplo, variar según el dispositivo)
(2) mantener visibles los temas ya renderizados, en lugar de la descarga actual de los mismos (lo que hace que volver a la parte superior sea engorroso)

Aprecio que esta es un área realmente compleja, sin buenas soluciones, y que ya se ha dedicado mucho esfuerzo a ella.

1 me gusta

Ha habido muchas buenas ideas en este hilo, la implementación actual (todavía) es horrible.
No lo hagas, simplemente no anules los atajos potentes. Incluso el antiguo enfoque de los tablones de anuncios con varios botones de búsqueda es más accesible. Encuentra una buena manera de buscar un tema o deja que el usuario cargue todo el contenido relevante en el DOM (lo cual también es horrible). Uno de los cofundadores dio el mejor consejo, presiona dos veces. Parece que somos más inteligentes…