Cada frame, perfecto

• La UI es casi la única superficie con la que el usuario juzga la calidad de una app, y la confianza se construye cuando, sin importar en qué momento se tome una captura de pantalla, el estado de la pantalla tiene sentido
• Una UI bien lograda se convierte en una señal de que el desarrollador dedicó tiempo a pulirla, y también en una heurística razonable para pensar que la calidad del código fue cuidada de forma similar
• El criterio real consiste en eliminar el parpadeo blanco entre transiciones de pantalla, las cargas parciales, los reacomodos durante la carga, los textos de estado inconsistentes y las animaciones imprecisas
• Aunque el estado inicial y final sean buenos, si los frames intermedios se desalinean, se genera la sensación de que los componentes no están sincronizados y, como en el caso de Photos, incluso puede crear una sensación falsa en transiciones donde en realidad no hay cambios
• Las animaciones deben ayudar a entender las transiciones, y solo cuando se cuidan no solo el inicio y el final, sino también todos los frames intermedios, la UI se siente como una herramienta de precisión

---

Principios clave

• El objetivo explícito de Wayland, “every frame is perfect”, es una meta técnica para recuperar el control dentro de la complejidad del stack moderno de GPU
• El mismo principio también aplica a la UI: sin importar en qué momento se capture la app, la pantalla debe verse natural y consistente
• Como el usuario no puede ver el código, la UI se convierte en la única superficie con la que evalúa la calidad de la app
• Si la UI está bien pulida, eso indica que el desarrollador invirtió tiempo en refinarla, y lleva a pensar que el código fue trabajado con un nivel de cuidado similar

Criterios reales y casos

• Para lograr frames perfectos, no debe haber parpadeo blanco entre pantallas, ni contenido cargado a medias, ni reacomodos de layout durante la carga
• El estado interno de la UI debe ser consistente: una parte no puede decir “1 update available” mientras otra dice “Checking for updates...”
• Las animaciones suelen olvidarse; aunque el estado inicial y el final sean buenos, si lo que ocurre entre ambos se ve extraño, una captura intermedia termina siendo un frame sin sentido
• En el caso de Safari, el texto de marcador de posición se mueve desde el centro, pero el cursor se anima desde una posición a la izquierda, lo que da la sensación de que ambos componentes no están sincronizados
• En el caso de Photos, al cambiar entre los modos Crop y Adjust, la foto se mueve de inmediato a su lugar, pero el borde de recorte sí se anima, creando una sensación falsa de que algo cambia sutilmente durante la transición
• En el caso de una UI de búsqueda, una animación que debería ayudar a entender la transición termina haciendo más difícil seguir el movimiento de la lupa
• En el caso de Youtube, incluso en una tarea simple como mover un rectángulo de una posición a otra aparece un movimiento extraño, y sin importar la razón, el resultado es un frame imperfecto
• Incluso incluyendo la animación de zoom de Preview, la idea central es que no solo importa el estado inicial y final, sino también prestar atención a cada momento intermedio

[GN⁺]

Comentarios de Hacker News

• Es cierto que algunos de los ejemplos del autor son malas animaciones, pero me cuesta estar de acuerdo con la premisa del artículo.
  Los gráficos por computadora son un campo que aprovecha las características del sistema visual humano, y percibimos de forma distinta lo que está en movimiento y lo que está quieto. Un frame que por separado parece “incorrecto” puede verse mejor dentro del flujo real del tiempo.
  Si lo comparamos con el cine, una toma de seguimiento rápida puede hacer que los frames individuales se vean mal por el motion blur, y una toma gran angular puede hacer que los objetos se vean “incorrectos” por la distorsión, pero si en el cine producen el efecto artístico buscado, entonces fueron la elección correcta.

  • Al principio pensé que “Every Frame Perfect” significaba evitar con rigor cualquier tartamudeo o corte en el movimiento, y con eso sí estoy totalmente de acuerdo. Pero desde la perspectiva del cine, el video y la tecnología 3D, los artefactos temporales como el motion blur no solo son lo que mejor “encaja” con el sistema visual humano, sino también la forma más fácil de interpretar.
    Si agregas el blur correcto al movimiento, puede sentirse más nítido, aunque al verlo congelado obviamente no se vea más nítido. La clave es que el motion blur correcto garantiza que se vea solo tan nítido como el detalle en movimiento que un humano realmente puede percibir a esa velocidad. Por eso, evaluar un frame congelado con motion blur según nitidez o legibilidad es un error.
    El resto del artículo se concentra en detalles de implementación, pero pierde la oportunidad de preguntarse si algunas de estas animaciones deberían existir en primer lugar. El movimiento puede ser una buena affordance si se usa con moderación, pero ahora ya no solo se abusa: a veces invade el campo visual y la carga cognitiva del usuario. Diseñadores y PM lo ven como una marca de “UX moderna y refinada”, pero en la práctica en parte ha degenerado en adorno de moda que imita el buen diseño, en vez de ser buen diseño real.
  • El argumento del artículo sería más fuerte si también mostrara buenos casos de uso. Aun así, estoy de acuerdo en que importa más la sensación general de la transición que cada frame individual.
    Algunas de las animaciones mostradas claramente parecen mejorables. Y siento que la IA puede ser bastante útil para empujar este tipo de pequeños placeres, porque antes tenían prioridad tan baja que era difícil dedicarles tiempo.
  • Creo que esta analogía va un paso de más. A diferencia del cine, la UI no registra la realidad: cada píxel en pantalla es resultado de cómo lo acomodamos nosotros, así que una analogía más cercana sería la del cartoon. Los in-betweens en un cartoon no son frames imperfectos, sino frames realmente terminados y cuidadosamente elaborados.
    Que un frame intermedio de una animación se vea un poco “raro” pero sea lógicamente correcto no es lo mismo que un estado intermedio que de verdad no tiene sentido y que solo existe porque no se pensó en lo que pasa durante la animación. En ese segundo caso, creo que sería mejor eliminar la animación o simplificarla.
  • La última animación de zoom de la app Preview también muestra un contraejemplo. Como quiere el autor, todos los frames por separado son perfectos, pero el problema se revela cuando lo ves en movimiento.
  • La idea de que una animación siempre deba ser consistente al desarmarla frame por frame no me parece muy convincente. Los usuarios en realidad no la ven así.
    Me gusta el enfoque del artículo de ver el nivel de pulido de la UI como un indicador indirecto de la calidad del software, y también acierta al señalar malas animaciones. Pero la consistencia por frame no es la mejor vara para medir si una animación es “buena”.

• Algunos dispositivos todavía tienen Sonoma, y no puedo decir otra cosa más que ha ido empeorando constantemente.
  El cuadro de diálogo de guardar tiembla un poco, pero no es tan confuso como en el ejemplo. El botón de Notes se mueve entre paneles con total suavidad. Si enfocas y desenfocas repetidamente la barra de Safari, la animación a veces se rompe, pero el cursor sí está perfectamente sincronizado con el texto, y solo aparece con fade-in después de que el texto termina de moverse a la izquierda. El bug de Preview también parece ser reciente, y no lo puedo reproducir.
  https://streamable.com/kx7op6
  Extraño la época en la que empresas como Apple, Sony e IBM se fijaban en detalles muy pequeños. Apple, en particular, obtuvo su valor actual con el iPhone, y en ese tiempo no hacía nada especialmente impresionante en funciones comparado con Windows Mobile o los PDA con Symbian; de hecho, en varios aspectos estaba por detrás funcionalmente. Pero era un dispositivo totalmente táctil que no te hacía querer usarlo cinco minutos y luego aventarlo contra la pared. Estas animaciones de ahora evocan exactamente la sensación de Windows Mobile y Symbian.
  Recuerdo cuánto le gustaban a Steve las animaciones de OS X. Varias veces en el escenario las volvía a reproducir en cámara lenta. Las de hoy ya están al nivel de merecer el destino que recibieron quienes estuvieron a cargo de la antena del iPhone 4.

  • Las animaciones del video corto en realidad se ven más ordenadas y menos confusas. Tal vez Apple usaba AppKit en Sonoma y ahora cambió a SwiftUI.

• Sí creo que una UI sin estos frames imperfectos podría sentirse mejor, pero a estas alturas me gustaría que alguien corrigiera cada clip y mostrara cómo se vería realmente.
  Al mismo tiempo, también me pregunto por qué todo necesita movimiento. Según entiendo, el movimiento tiene sentido cuando, como con un toast, la UI cambia sutilmente en una zona distinta de donde el usuario inició la acción.
  Muchas de las transiciones mostradas aquí parecen innecesarias, y probablemente se sentirían igual de bien si cambiaran al instante con una reubicación inmediata.

  • El “frame imperfecto” de la barra de búsqueda de Safari está bien en términos prácticos, y una forma de hacer que se vea mejor en un screenshot incluso podría ser peor.
    El cursor aparece a la izquierda porque ahí es donde el usuario realmente empieza a escribir. Alguien que conoce la UI probablemente va a mirar ahí. Hacer que el cursor aparezca en el centro de la pantalla y luego moverlo sería innecesario y distractor.
    El texto del placeholder se desliza hacia la izquierda para llamar la atención del usuario menos familiarizado.
  • Una tragamonedas siempre necesita que algo se esté moviendo, y las animaciones de Apple excesivamente dinámicas cumplen ese papel. Las animaciones de UI en general ayudan a los usuarios comunes, a quienes les cuesta cuando el contenido de la pantalla cambia de golpe, y también sirven para que la tasa de cuadros se sienta más fluida o para ocultar demoras de llamadas API y procesamiento en el backend.
  • Si juegas algún juego con buena UI, verás que la animación está en todas partes. Las transiciones instantáneas solo suenan bien en teoría.
  • No todo necesita movimiento. La mayoría de las cosas no lo necesitan. Este tipo de tonterías les crea trabajo a unas cuantas personas y además les da a otras una excusa para presumir que el lenguaje de diseño de $BRAND es superior a las alternativas.
    La mayoría de los ejemplos probablemente se sentirían mejor sin animación. Si presionaste un botón, solo muestra el resultado. No bailes antes de mostrarlo, solo muéstralo.
  • El movimiento es importante para recuperar la orientación después de una transición.
    Sin movimiento, muchas veces el cerebro tiene que volver a escanear toda la página cada vez que se refresca.

• Creo que la argumentación de este texto está planteada de forma débil. Tampoco ofrece mejores alternativas, ni explica realmente por qué lo propuesto sería negativo para los usuarios. Puede que lo sea, pero se parece a esa manera vacía de criticar señalando los smear frames de los medios o puntos de transición.
  El criterio de “cada frame tiene que tener sentido” también es difícil de sostener. Lo veo imposible, y me gustaría preguntar cómo se supone que se mantendrían todos los frames perfectamente, incluso mientras se redimensiona una ventana.
  Incluso para el propio autor, parece más fácil señalar frames defectuosos que poner en práctica el criterio que propone. Si haces clic en los enlaces del encabezado del blog, la animación se reproduce después de que termina el clic. Si ves sus propios proyectos de UI, también hay lugares donde el texto y los objetos no se quedan dentro del contenedor. Si va a decir que hay que seguir este tipo de principios, también debería poder demostrarlo por sí mismo.
  Un texto mejor escrito se habría centrado en por qué las cosas que presenta son malas para el usuario final y en cómo deberían resolverse en su lugar. Una buena crítica incluye no solo el qué, sino también el por qué y el cómo

  • Esta crítica, de hecho, es la que más vacía se ve aquí.
    El texto no está ofreciendo una solución, sino presentando una idea. No ver eso y criticarlo levantando varios hombres de paja es justo lo que pasó.
    Más importante aún: el texto no está escrito de manera tajante. Está redactado con cautela, con frases como “I think”, “Next thought:”, “Probably” y “So yeah.”. Es una persona compartiendo sus pensamientos, y son ideas bastante elaboradas como para hacer que varias personas razonables piensen en una dirección parecida.
    Que el autor no haya presentado una solución no significa que necesariamente tuviera que hacerlo. Ese criterio es raro e irrazonable.
    Tampoco se ve muy bien atacar el sitio del autor. Las diferencias de gusto son bien conocidas, y castigar una contribución conceptual porque va por delante de la técnica real resulta bastante desagradable.
    Una crítica mejor habría sido más generosa, en sintonía con el espíritu de esta comunidad

• Vi varias reacciones diciendo que les habría gustado que el autor incluyera ejemplos de solución. Hace poco escribió un texto muy parecido a este, y, como aquí, entra en detalle sobre los problemas de las animaciones y luego explica cómo los mejoró.
  Si te da curiosidad, se puede ver aquí: https://www.thisischris.dev/projects/project-6/

  • En Chrome móvil para Android, parece que la animación no funciona

• Creo que un frame imperfecto ahora es mejor que un frame perfecto más tarde. En toda UI, la latencia debería ser la prioridad máxima. Si la latencia es suficientemente baja, se siente como una extensión de tu propio cuerpo y reduce la carga cognitiva. La animación es especialmente mala para esto, porque añade cientos de milisegundos de retraso

  • Creo que eso es una falsa dicotomía. Los ejemplos que dio el autor no serían más lentos en absoluto aunque estuvieran bien implementados
  • Puede que hayas pensado por el título que esto era sobre Wayland, y esa idea sería correcta. Pero esto no trata sobre Wayland

• Me habría gustado que hubiera ejemplos positivos además de los negativos. La única conclusión que saqué ahora es que hay que evitar las animaciones, pero no creo que eso sea realmente lo que el autor quiere decir

  • La conclusión de “hay que evitar las animaciones” no es la peor lección. En general, hay que evitar la animación por la animación misma. Por ejemplo, imagina que en el teclado de un teléfono, cada vez que escribes una letra, el carácter saliera volando hacia el campo de texto

• No es raro que una buena animación use un poco de truco mientras se mueve, en vez de verse perfecta en cada frame. Como los smear frames de los dibujos animados: si los pausas en el momento equivocado se ven raros, pero dentro de la animación completa hacen que el movimiento resulte visualmente convincente

  • Los smear frames no son una técnica que se aplique a menudo en este tipo de animación. Está casi especializada en animación cuadro por cuadro, y en este texto no aparecen smear frames
  • La diferencia es que los frames borrosos se usaron intencionalmente para el efecto general. Las animaciones de aquí se parecen más a un tirón accidental que delata una app poco pulida
  • No creo que esa analogía encaje. Los frames borrosos se ven bien en movimiento, pero los frames del post del blog se ven horribles incluso en movimiento. El primer ejemplo es tan malo que, cuando lo vi por primera vez, pensé que quedarían tres botones arriba, y cuando me di cuenta de que en realidad eran solo dos, se sintió raro y desorientador
  • En macOS, sentí que la calidad visual y la calidad de las animaciones cambiaron mucho cuando Apple empezó a usar SwiftUI en el OS y en las apps.
    No soy desarrollador, pero sentí que había áreas donde los íconos o las ventanas ya no se colocaban o movían como antes, o como intuitivamente deberían hacerlo.
    Esa sensación de remiendo no cambió con el tiempo. Hay tantos ejemplos por todo el OS y las apps que dan ganas de decir “siempre fue así”, pero en realidad no. Apple tenía un estándar, ese estándar era alto y la calidad era excelente.
    Se siente como si hiciera falta mucho hackeo para lograr el mismo acomodo de UI o las mismas animaciones con SwiftUI.
    Por último, algo en lo que pienso seguido es que la creación analógica era realmente difícil, y todavía lo es. En lo digital siempre hemos pensado que ya lo retocaríamos después, pero en la práctica muchas veces no pasa, y es triste ver cómo se apila algo malo sobre algo peor
  • Overwatch es un ejemplo moderno bastante bueno [1]. Tiene muchas animaciones muy fluidas, pero si pausas los frames, realmente se ven muy raros.
    [1]: https://youtu.be/vIdeGmN__Pw?t=550

• Una app sin absolutamente ninguna animación se sentiría horrible. Si tienes Android, puedes comprobarlo tú mismo cambiando la velocidad de animación a 0x en las opciones de desarrollador. El cambio inmediato resulta molesto, y al cerebro incluso le toma como 1 segundo procesar qué fue lo que pasó; ese proceso puede hasta sentirse más lento que cuando hay animación
  Yo la tengo en 0.5x y me parece suficiente. Sigue siendo rápido, pero aún puedes ver cómo las apps se abren y se cierran

  • En Android tengo las animaciones desactivadas y lo uso feliz así. Es la única forma de que se sienta más o menos “inmediato”. En el contexto que va de la entrada del usuario al cambio en la UI, creo que la latencia siempre es peor que no tener transiciones vistosas
  • En mi caso no. Siempre desactivo las animaciones. Así está bien, y puedo usar el teléfono mucho más rápido porque no tengo que esperar a que terminen
  • Yo también uso 0.5x
    El problema de 0x es que parece aplicarse solo al 90% de la UI. Algunas cosas todavía tienen animación, y como resultado el ritmo se siente rarísimo
    En 0.5x molestan menos las cosas que, por alguna razón, no reciben bien el efecto de la configuración de velocidad de animación
    Si funcionara bien, usaría 0x
  • Después de usar Android casi 10 años, al final me cambié a un iPhone 12 Mini cuando salió. Todavía extraño que en Android se puedan desactivar las animaciones. Estoy 110% seguro de que mi teléfono actual sería 200% más rápido si pudiera apagar todas las animaciones que existen solo por existir
    Si hace falta, prefiero que el procesamiento tome 1 segundo, y de hecho ni siquiera creo que sea necesario. Es muchísimo mejor que perder 1 segundo cada vez que una app cambia de página por culpa de una animación, y al navegar todo se siente como melaza
  • Todas las animaciones son solo tiempo desperdiciado en el que no puedes interactuar bien con la UI, así que es mucho mejor apagarlas todas

• Me identifiqué con este artículo, pero me habría gustado que incluyera también ejemplos positivos. No se leyó como una queja, pero como alguien que no sabe mucho sobre cómo construir una buena UI, no sentí que estuviera más cerca de saber qué tomar como estrella polar

  • Hace poco escribí justo sobre eso. Primero profundicé en imperfecciones conceptualmente parecidas a las de este artículo, y luego expliqué el proceso de mejora que hice yo mismo
    Si te interesa, puedes verlo aquí: https://www.thisischris.dev/projects/project-6/
  • O el autor podría haber mostrado maquetas de cómo debería verse cada uno de los malos ejemplos si estuvieran bien implementados

[GN⁺]

Opiniones en Lobste.rs

• Creo que la premisa básica de este artículo está equivocada. Estas apps no se usan cuadro por cuadro
  Incluso en una clase básica de animación aprendes que la forma en que percibimos el movimiento es distinta a la de imágenes fijas. Si buscas una demo de "squash and stretch", verás que, cuadro por cuadro, las dimensiones de un objeto parecen absurdas vistas por separado, pero dentro del movimiento funcionan de forma hermosa

  • Los ejemplos del artículo no se ven bien ni siquiera en movimiento
  • El punto no es que la animación sea fea, sino que se creó un intervalo de tiempo en el que una UI utilizable fue reemplazada por una secuencia de animación no funcional
    Incluso puede mostrar incorrectamente el estado del programa, como en el ejemplo del recorte. El usuario tiene que “apagar el cerebro” por alrededor de un tercio de segundo mientras la UI se vuelve a ensamblar, y solo después puede seguir usando el programa

• No creo que la perfección por cuadro de la que habla el proyecto Wayland signifique esto en absoluto
  Más bien se refiere a detalles técnicos de nivel más bajo, como el redimensionamiento de ventanas. Por ejemplo, que el contenido se redimensione de forma asíncrona, que se rompa la sincronización vertical y aparezca tearing o artefactos diagonales extraños, o que el reporte de regiones dañadas se haga como subregiones rectangulares
  Claro, estaría bien que tanto los detalles de bajo nivel como las animaciones de alto nivel fueran perfectos cuadro por cuadro

  • De acuerdo. Y creo que el autor también lo ve así

    Wayland is talking about the technical side of things (modern GPU stacks are very complex and Wayland is trying to take control back) but it could be applied to UI too.

• Supongamos que quieres probar este tipo de animaciones y escribir tests que verifiquen que esta propiedad no se rompa con el tiempo
  ¿Cuáles son hoy las técnicas más modernas para probar este tipo de propiedades en apps web y nativas? ¿Hay categorías específicas de pruebas que en la práctica sean imposibles o muy difíciles de escribir porque no puedes controlar el event loop?

  • Solo puedo hablar de apps nativas de Android. Si usas el toolkit de UI Jetpack Compose, puedes controlar el reloj mismo que impulsa la UI, así que puedes capturar cualquier punto de una transición con pruebas estáticas de screenshots
    O también puedes registrar la transición completa como un PNG animado con herramientas como Paparazzi para hacer pruebas automáticas de regresión
  • Idealmente, la información de tamaño debería estar expuesta, un motor de layout genérico debería poder probarse de forma independiente, y la animación también debería estar separada
    Entonces podrías verificar por separado ambos puntos y al final confirmar solo el estado final. La animación no debería quedar fijada a una entrada temporal, sino poder avanzarse paso a paso desde afuera

• Creo que el ejemplo de YouTube corresponde bastante bien a un caso de View Transitions
  Es una forma declarativa de decir “cuando este elemento cambie, transfórmalo automáticamente”, y el resultado suele ser una transición técnicamente impresionante pero algo gelatinosa, donde los elementos flotan y se deforman entre sí
  Es una tecnología muy genial, pero casi nunca la he visto lucir realmente bien más allá de pequeños efectos de énfasis durante la navegación. Hay que usarla con muchísima moderación para que no se vuelva demasiado distractora