Unificando "Dismissed" vs "Not Interested," y la fila de Settings que repetía su propio encabezado de sección
Una revisión de diseño de Deep Cut Atlas sacó a la luz algo pequeño pero molesto: la app llamaba a la misma función de tres formas distintas según la pantalla que se estuviera mirando. Settings tenía una fila etiquetada “Dismissed releases.” La pantalla que esa fila abría se titulaba “Not Interested.” El estado vacío de esa pantalla decía “No Dismissed Releases.” Y el diálogo de confirmación para borrar todo decía “Clear all Not Interested?”
Cuatro nombres, un concepto. Ninguno de ellos exactamente incorrecto, solo inconsistentes de una forma que hace sentir la app como si la hubieran armado cuatro personas distintas que nunca se hablaron entre sí (lo cual, para ser justos, es más o menos lo que pasa cuando las funciones se agregan de a un ticket por vez a lo largo de meses).
La solución parecía trivial: elegir “Not Interested” porque es la etiqueta que la gente realmente toca, y cambiar las otras tres para que coincidan. Cuatro cambios de string, listo en veinte minutos.
Solo que cuando fui a cambiar la fila de Settings, encontré que vivía dentro de una Section ya titulada “Not Interested.” Así que si simplemente renombraba la fila para que coincidiera, iba a quedar un encabezado de sección diciendo “Not Interested” seguido inmediatamente por una fila que también decía “Not Interested.” Arreglar la inconsistencia habría introducido una nueva, solo un nivel más arriba.
Esto es lo molesto de los tickets de consistencia de copy: la solución obvia y la solución correcta no siempre son la misma solución. Revisé la pantalla realmente renderizada antes de fijar nada, porque este tipo de redundancia es obvia en cuanto se ve la interfaz real y fácil de pasar por alto mirando fijo los strings de origen. La propia app de Settings de Apple nunca repite un encabezado de sección dentro de una fila. Section(“Notifications”) nunca contiene una fila que también diga “Notifications.” El encabezado establece el contexto una vez, y la fila de abajo describe la acción o el sub-detalle, no el tema. Así que la fila pasó a ser “Manage,” con el conteo como su valor final. El encabezado establece el “qué,” la fila describe el “qué hago acá.”
El único lugar donde ese instinto no aplica: el botón destructivo “Clear all Not Interested,” ubicado en esa misma sección, también repite técnicamente el encabezado. Lo dejé como estaba. Las acciones destructivas tienen una excepción. Settings de Safari dice “Clear History and Website Data,” no solo “Clear,” porque cuando se está a punto de borrar algo permanentemente, repetir qué se está borrando vale la redundancia. La consistencia por la consistencia misma también habría acortado ese botón; la mejor decisión fue reconocer que una repetición es un error y la otra es una función de seguridad.
Ticket chico, pero es un buen recordatorio de que “hacerlo consistente” y “hacerlo coincidir con lo que asumí al principio” no son la misma instrucción, y los diez segundos que toma mirar la pantalla realmente renderizada antes de fijar un cambio de string suelen valer la pena.
Lecturas relacionadas
Cuando el mismo ícono significa dos cosas distintas, y por qué la solución no fue solo cambiar una etiqueta
Dos botones de pulgar hacia abajo, con el mismo estilo rojo: uno permanente, uno inofensivo. El lenguaje visual hacía una promesa que el código no cumplía, y el nombre del método era parte del bug.
Una decisión de UX que hice mal la primera vez
La acción de agregar a lista de reproducción calzaba con su gesto hermano en la misma tarjeta, y peleaba con el resto de la app. Elegir el punto de referencia equivocado para «consistente.»
La configuración que funcionaba perfecto y se sentía completamente rota
Un filtro por defecto que solo se aplicaba al reabrir la app, porque un TabView mantiene vivos los view models y el estado sembrado en la construcción queda congelado. La solución eliminó un concepto.