No toques el scroll
(dontfuckwithscroll.com)- Scrolljacking sobrescribe la velocidad, dirección y efectos de desplazamiento predeterminados del navegador, alterando la navegación web predecible que esperan las personas usuarias
- En el estudio de usabilidad de Nielsen Norman Group, muchas personas participantes perdieron el sentido de orientación, y algunas interpretaron el cambio en el scroll como un bug
- Los plugins de scroll con momentum, suave o inercial rompen la memoria muscular y las funciones nativas del navegador, dificultando ubicar la posición actual en páginas largas
- Las animaciones de transición de pantalla y la dependencia de JavaScript aumentan la carga de accesibilidad y rendimiento en casos de mareo o vértigo, tecnologías de asistencia, dispositivos de bajos recursos y entornos móviles
- Las personas usuarias llegan por el contenido, no por efectos de scroll, así que es mejor que los sitios mantengan un scroll nativo y rápido tal cual
Cómo el Scrolljacking arruina la navegación web
- Scrolljacking es una técnica que redefine el comportamiento de scroll predeterminado del navegador para cambiar la velocidad, dirección y efectos del desplazamiento en una página web
- Los plugins de scroll con momentum, scroll suave y scroll inercial son formas comunes de scrolljacking
- Puede parecer una mejora, pero interfiere con una experiencia de navegación web natural, eficiente y predecible
- El impacto se manifiesta principalmente en usabilidad, accesibilidad y rendimiento
La confusión confirmada en estudios de usabilidad
- El estudio de usabilidad de Nielsen Norman Group muestra que el scrolljacking puede provocar desorientación en las personas usuarias
- Muchas personas participantes experimentaron al menos un grado mínimo de pérdida de orientación
- Algunas personas usuarias interpretaron el comportamiento modificado del scroll como un bug
- Las personas usuarias orientadas a tareas mostraron mucha menos tolerancia al scrolljacking que quienes navegan con fines exploratorios
- Una participante reaccionó en el sentido de: “Deslicé completamente y no me movió a ninguna parte”, y dijo que, como clienta potencial, le habría resultado muy frustrante
- En móviles, el problema empeora por la larga duración del desplazamiento y el tamaño reducido de la pantalla
Violación de expectativas y control de la persona usuaria
- Las personas usuarias esperan que, al hacer scroll, el contenido se mueva de inmediato
- Los plugins de scroll con momentum ofrecen un comportamiento mezclado con animación en lugar de un movimiento inmediato y predecible
- Estos cambios interfieren con la memoria muscular y los hábitos existentes en los que las personas usuarias dependen para navegar con eficiencia
- Al sobrescribir el scroll predeterminado, la puesta en escena del sitio se impone por encima de las preferencias o necesidades de la persona usuaria
- Las personas visitan un sitio para ver el contenido, no para vivir una experiencia de scroll excesivamente producida
Mareo y carga de accesibilidad
- Los plugins de scroll con momentum agregan animaciones flotantes o tambaleantes que pueden resultar pesadas para personas propensas al mareo o al vértigo
- Muchos sitios no ofrecen una opción para desactivarlas, por lo que es difícil evitar esa incomodidad durante la lectura
- Las tecnologías de asistencia, como lectores de pantalla y navegación por teclado, pueden verse afectadas por los retrasos de temporización
- Para personas con discapacidades motrices o limitaciones visuales, estos retrasos pueden volver más difícil el uso del sitio
- La accesibilidad no debe tratarse como una función opcional, sino como un requisito básico del uso de la web
Menor rendimiento y consistencia entre dispositivos
- Los plugins de scroll con momentum cargan JavaScript, y pueden causar retrasos, tirones o fallas en dispositivos antiguos o de bajos recursos
- En vez de sentirse “smooth”, la página puede parecer rota en equipos más modestos
- Renderizar estas animaciones requiere bibliotecas de JavaScript infladas, dependencias adicionales y más ciclos de CPU
- Como resultado, el tiempo de carga de la página puede aumentar
- En redes móviles o zonas con mala conectividad, los efectos de scroll llamativos vuelven la página más lenta y menos accesible
Problemas con funciones nativas del navegador y percepción de posición
- Los navegadores modernos ya incluyen configuraciones de scroll con momentum para quienes las desean
- Los plugins de terceros pueden sobrescribir estas funciones nativas o generar conflictos, rompiendo gestos de scroll personalizados o el scroll con momentum
- Las preferencias de la persona usuaria, como la configuración del sistema para reducir movimiento, pueden dejar de funcionar como se espera
- Las animaciones de scroll con momentum añaden una demora entre la entrada de la persona usuaria y el resultado
- En páginas largas, se vuelve más difícil ubicar con precisión la posición actual y también navegar con rapidez
Power users y costo de mantenimiento
- Para las personas usuarias avanzadas que hojean documentos rápidamente o se desplazan con precisión por una página, el scroll con momentum ralentiza el flujo de trabajo
- Tener que esperar animaciones lentas choca con la expectativa de quienes quieren terminar una tarea rápido
- Los plugins de scroll con momentum no son una función que se instala una vez y ya
- Requieren actualizaciones periódicas para seguir siendo compatibles con los navegadores, sistemas operativos y dispositivos más recientes
- Cada actualización introduce el riesgo de nuevos bugs y añade trabajo extra al equipo de desarrollo, en lugar de dedicar ese tiempo y costo a hacer el sitio más rápido, seguro u optimizado
Conclusión: deja el scroll como comportamiento predeterminado
- El scrolljacking y los plugins de scroll con momentum añaden complejidad innecesaria, reducen la usabilidad y frustran a las personas usuarias
- Como dice Nielsen Norman Group, “la usabilidad es la base del deleite”
- En lugar de reinventar el scroll, hay que mantener un comportamiento nativo, predecible y rápido
- No conviertas el scroll en un evento especial; deja que la gente simplemente haga scroll
1 comentarios
Opiniones en Hacker News
Tampoco deberían meterse con la URL, la navegación del navegador ni el botón de volver.
Siento que esa batalla se perdió hace mucho, y las SPA rompieron la web y la hicieron mucho peor.
La History API funciona bien, así que se puede hacer que una SPA y su propio navegador se comporten de acuerdo con el navegador y el usuario.
Pero muchos desarrolladores rompieron eso porque no les importaron los fundamentos de la web, como poder guardar marcadores y la navegación.
Una buena SPA debería comportarse como un sitio web normal, y uno no debería notar que es una SPA salvo porque es rápida y responde bien.
Es cierto que debería poder marcarse o compartirse un estado específico, pero para eso es mucho mejor que solo cambie la URL en el lugar, en vez de crear un nuevo paso de navegación.
Quienes rompieron la web fueron las personas que no se preocupan por los fundamentos de la web, la URL, volver atrás, la experiencia de usuario del scroll, etc.; el problema no es la SPA en sí.
Los navegadores deberían arreglarlo, pero la inercia es tan grande que parece que no va a pasar.
Creo que la actitud de “nosotros sabemos mejor que el usuario” no solo aplica al scroll con Momentum, sino también a muchas modas actuales de diseño UX.
Me pregunto cómo llegamos a caer en el culto a la estética sacrificándolo todo.
Hay una actitud extremadamente condescendiente de impedir que el usuario asuma cualquier responsabilidad por sí mismo.
Hoy mismo busqué cómo desactivar en macOS el molesto comportamiento de “se necesita la contraseña para activar Touch ID”; entiendo que la pida después de reiniciar, pero la exigencia que parece basada en tiempo aparentemente no se puede desactivar.
Lo más cercano que encontré fue usar el comando
bioutilpara reducir el límite de tiempo, pero no se puede aumentarlo.Estoy pensando en hacer ingeniería inversa para encontrar dónde se valida el valor máximo y ver si puedo eludirlo llamando directamente a una API de más bajo nivel.
Más bien se parece a una ausencia de diseño UX.
Había una buena entrada de blog con un título tipo “Button presses You”, pero no logro encontrarla.
La idea central era que el propósito de una aplicación ya no fluye hacia decidir qué hará el usuario con el programa, sino hacia que la aplicación le indique al usuario qué hacer y cómo hacerlo.
Tampoco deberían meterse con las barras de scroll.
Últimamente parece haber una moda de hacerlas de algo así como 1 px de ancho en todos lados.
Si de verdad quieres hacer una app ergonómica, tienes que lograr que funcionen bien los gestos con uno o dos dedos, por ejemplo arrastrar con el dedo para hacer scroll.
Entonces, en escritorio, la única forma de hacer scroll es seleccionar texto arrastrando más allá del borde del marco.
Trato de no usar contenido que se desborde, pero cuando necesariamente tiene que desbordarse, la barra de scroll interfiere con el diseño y la barra de scroll por defecto es demasiado fea, así que la oculto.
Aparecen en cuanto mueves el mouse y desaparecen cuando te detienes.
Si quieres ver tu posición, basta con mover un poco el mouse.
Uso Internet desde la época de Gopher y me gusta el minimalismo de la estética HTML pura.
También me gustó mucho el enlace al final del artículo hacia el sitio web que lo inspiró.
Cuando uno ve el código fuente de páginas así, no es simple nostalgia: da una sensación cálida de “esta gente sí entiende”.
Es parecido a la escena del documental Helvetica donde los diseñadores describían lo que sintieron cuando pudieron elegir la nueva Helvetica en lugar de esas fuentes script malas estilo años 50.
Creo que esto también incluye las landing pages llamativas donde el contenido que aparece en el fondo cambia según el scroll, o donde la propia página se divide en secciones.
Ej.: https://webflow.com/made-in-webflow/website/Translate-Webflo...
El scroll por inclinación del iPad ayuda incluso a personas mayores a leer y desplazarse rápido, y el scroll automático también es bastante bueno.
Sigo odiando tanto como la primera vez que vi que pusieran botones < > en las filas de elementos de páginas que originalmente solo se desplazaban hacia arriba y abajo.
Las plataformas de streaming son las más infames en esto, pero no son las únicas culpables.
Lo que más odio últimamente es que intercepten Ctrl+F o Ctrl+K.
Para que los navegadores lo hicieran posible, seguramente tuvieron que agregar código extra, y a Google, Apple o Mozilla no les habría costado nada no escribir ese código.
El navegador debería ofrecer un atajo alternativo para estos casos, como Shift+Ctrl+F.
Acabo de descubrir que en Firefox Shift+Cmd+F hace algo.
No deberían tocar combinaciones de teclas estándar.
No deberían quitarle funcionalidad a otra aplicación y sorprender al usuario.
Hace poco dejó de funcionar Cmd-F para buscar dentro de una hoja de cálculo en Google Sheets en Mac; aunque esa forma sí interceptaba un atajo del sistema, en la práctica tampoco había una función alternativa.
Así que para buscar había que ir a la barra de menú de Sheets y encontrarlo dentro del menú.
Tampoco deberían tocar eso de que al desplazarte hacia abajo avanza una animación, los elementos se mueven hacia los lados y hay que pasar por una barrera de scroll antes de poder seguir bajando por la página.
Es horrible, molesto, obstructivo y hostil para el usuario.
Lo más gracioso es que el enlace “Back to the normal version” solo se puede hacer clic después de volver hasta arriba con scroll suave.
Bien jugado.
Me pregunto si esto se puede desactivar en Firefox con
about:settings.¿O se rompería la detección de eventos?
Como alternativa, una extensión del navegador podría ayudar.
La implementación seguramente varía según el caso, y el ejemplo de la página [1] usa la biblioteca luxy.js [2].
En esa página específica [1], se pudo desactivar el comportamiento de scroll suave ejecutando el siguiente comando en la consola de las herramientas de desarrollador:
luxy.init({ wrapperSpeed: 1.0});