Todas las etapas anteriores miden algo. Esta no puede, y ese es justamente su tema.
La tarea era pequeña y estaba bien planteada por el dueño del proyecto:
OK, cosas de diseño, en pantalla pequeñas, lo mas importante, el resultado, se corta, mal diseño pues
El dueño del proyectoTenía razón: en una ventana baja, la tarjeta del resultado —lo único que la aplicación produce— empezaba por debajo del pliegue. Lo que pasó después no tiene nada que ver con el CSS.
Nueve minutos
15:32 fix: show the result without having to scroll for it
15:40 fix: let the how-it-works card be as tall as its content
15:41 fix: shrink the opening on short windows so the result fits
15:42 Revert "fix: shrink the opening on short windows…"
15:42 Revert "fix: let the how-it-works card be as tall…"
15:42 Revert "fix: show the result without having to scroll…"Tres cambios de diseño en nueve minutos, directos a la rama que despliega a producción. El veredicto llegó un minuto después del tercero:
has hecho una mierda que flipas
El dueño del proyectoY después, cuando intenté explicar lo que había hecho:
pero que has arreglado?? no me queda claro
El dueño del proyectoLas dos frases señalan fallos distintos, y el segundo es más fácil de pasar por alto que el primero.
Por qué el diseño no tiene eval
El curso entero se apoya en una idea: no te creas una mejora, mídela. La etapa 15 tumbó una constante con 480 llamadas. La 18 midió el sujeto de la frase en 16 entradas. La 19 canceló una función entera porque la medición decía que ya funcionaba.
El diseño visual no admite ese trato. No hay un número que diga si una cabecera sobra. Y cuando no hay métrica, la tentación es sustituirla por confianza en el propio criterio, que es precisamente lo que produjo los nueve minutos.
El sustituto correcto no es medir: es enseñarlo antes. Una rama, un preview y una persona mirando. Más lento y menos elegante que un eval, pero es lo que hay, y funciona.
La segunda vez
La misma tarea, con reglas nuevas: rama aparte, un cambio cada vez, preview desplegado, y no seguir hasta que él lo juzgara.
4c06dd0 design: tighten the opening so the result starts on screen
2d5e2ec design: weight the input over the card, and talk like the app is named
de4547e web: shrink the input pair and give the side card its punchline
2fa35a3 web: put the page in motion
c03984b web: drop the header and rehome its link
fbc1421 web: reclaim the space the header used to occupy
970c8b3 web: raise the masthead cropSiete commits, dos ficheros, +291/−65, y una pull request que mergeó él. El mismo problema, resuelto.
Lo interesante no es que saliera bien: es qué encontró él que yo no habría encontrado nunca.
- La cabecera sobraba entera. Decía «La voz de Perico» justo encima de un H1 que dice «Tu texto, en la voz de Perico Delgado». Yo llevaba tres commits recortando píxeles alrededor de un bloque de ochenta que no había cuestionado. Él lo vio en una captura: «no aporta nada y el boton se pouede realojar en otro lado, no?»
- Mi arreglo introdujo el problema siguiente. Al quitar la cabecera subí el padding de la sección para compensarla. Compensar algo que ya no existe deja la página abriendo con 64 píxeles de nada — el hueco que acabábamos de recuperar, devuelto. Lo cazó en la captura siguiente: «ahora el espacio sobra, no?»
- El encuadre de la foto estaba calculado para una página con cabecera. Al subir todo, el ciclista se quedaba bajo. Él dio el número directamente:
object-position: 50% 75%.
Los tres son invisibles desde el código. El segundo es el más instructivo: un arreglo que crea el siguiente defecto se ve una sola vez, en pantalla, y sólo si alguien mira después de aplicarlo.
Lo que se dejó fuera, y por qué
Como referencia llegó un prototipo de v0. Traía cosas buenas —la proporción entre las dos tarjetas, el tono de la copy— y una que no entró: height: 100vh con overflow-y: hidden.
Encaja perfectamente mientras el resultado está vacío, que es como se fotografía siempre un prototipo. Con una traducción larga dentro, atrapa el final del texto sin manera de llegar a él.
De la copy sí entró lo mejor, y con una corrección. El prototipo decía:
Rescatamos tu idea, le ponemos casco y la soltamos cuesta abajo. El significado llega entero; la dignidad, ya veremos.
Prototipo de v0La tarjeta que sustituía decía en cambio «25 frases sacadas al azar de su archivo y 12 elegidas por parecerse a la tuya». Datos ciertos, pero texto fijo: los mismos números aunque la recuperación devolviera otra cosa. La consola de debajo ya informa de la recuperación real de cada petición, frase a frase y con su puntuación. Así que la tarjeta se queda con la broma y el dato se queda donde es verdad.
Movimiento
Con la estructura resuelta, el dueño pidió lo contrario de lo que llevábamos haciendo:
no sé que animaciones, para eso te pago, mete animaciones a saco, tanto con interaccion como si no, y vamos depurando
El dueño del proyectoOcho piezas: la página entra de arriba abajo al cargar; la caja vacía propone un ejemplo y lo cambia cada 3,6 segundos; una pegatina «¡ATACA!» aparece sobre el botón en cuanto hay algo que traducir; la bici pedalea sola mientras el servidor trabaja; el pipeline dibuja un perfil de puerto con un ciclista subiéndolo; un barrido amarillo cruza el resultado al llegar; las barras de similitud se dibujan en cascada; las tarjetas se levantan con el cursor.
Con una regla que decide el diseño entero:
Todo lo anterior cae junto bajo prefers-reduced-motion: reduce, en un solo bloque al final de la hoja de estilos.
Eso sólo es legítimo si ninguna animación comunica algo que no esté también escrito al lado. El perfil de puerto acompaña a una lista de pasos que ya dice en qué paso va; el barrido acompaña a un resultado que ya está ahí. Apagarlo todo no le quita nada a quien lo apague.
La regla práctica: si al desactivar el movimiento se pierde un dato, ese dato estaba mal colocado.
Y un aviso honesto que acompañó a cada entrega: yo no veo la página. Compruebo que compila, que el typecheck pasa y que los tests siguen verdes, y señalo cuáles de mis cambios tienen más papeletas de verse mal —en este caso, el ciclista montado sobre offset-path y la capa del ejemplo rotatorio encima del textarea. Decir «ya está listo» sobre algo que no he visto es la misma afirmación sin comprobar de los nueve minutos, sólo que mejor educada.
- Un prefijo de commit es una afirmación.
fix:dice que algo roto ya no lo está. Si nadie lo ha visto funcionando, el mensaje miente igual que mentía la herramienta de la etapa 08. - Lo que no se puede medir, se enseña. El diseño no tiene eval. El sustituto no es el criterio propio: es una rama, un preview y una persona mirando antes de mergear.
- De uno en uno. Tres cambios juntos no se pueden juzgar: si el conjunto está mal, no se sabe cuál sobra. Siete cambios seguidos, cada uno con su preview, sí.
- Un arreglo puede crear el defecto siguiente. Compensar una cabecera que acababa de borrar devolvió el hueco que el arreglo había ganado. Eso sólo se ve mirando después.
- El estado vacío miente. Una maqueta se fotografía recién cargada. Pregúntale siempre qué hace con el contenido largo.
- El dato va donde es verdad. Una cifra escrita a mano en la interfaz es una afirmación que nadie vuelve a comprobar; la misma cifra calculada en cada petición se corrige sola.
- Decir lo que no has comprobado, pero decirlo. No ver la página no es el problema. Dar por bueno lo que no has visto, sí.