40 commits para unificar tres pantallas idénticas: por qué la estandarización invisible lo cambia todo

Tres pantallas. Tareas. Notas. Eventos. Las tres muestran esencialmente lo mismo: un título, un contenido, personas que tienen acceso, una carpeta de adjuntos, recordatorios, etiquetas. Y sin embargo, en TAMSIV, estas tres pantallas tenían cada una su propio diseño, su propio orden de secciones, su propia forma de mostrar la misma información. 40 commits después, finalmente se parecen. He aquí por qué esta uniformización invisible lo cambia todo.

Por qué uniformar tres pantallas que ya funcionaban

La pregunta es legítima. Si las tres pantallas ya funcionaban, ¿por qué gastar 40 commits en hacerlas idénticas? La respuesta se resume en una palabra: carga cognitiva.

Cuando tú usas TAMSIV a diario, pasas de una tarea a una nota y luego a un evento a veces en menos de un minuto. Si cada pantalla muestra la misma información en un orden diferente, tu cerebro tiene que reorientarse en cada transición. Buscas la etiqueta arriba en la tarea, la encuentras abajo en la nota, ya no la encuentras en el evento. Multiplica esto por 20 o 30 consultas al día, y la fricción invisible termina por pesar.

Por el contrario, cuando las tres pantallas se parecen, tu cerebro aprende una sola vez dónde está cada cosa. El título está arriba. El árbol de acceso está justo debajo. La carpeta padre sigue. Las etiquetas vienen después. El contenido principal ocupa el centro. Los recordatorios y el historial bajan. Tres pantallas, un solo mapa mental.

El árbol de acceso: dos ramas, cero ambigüedad

La información más crítica en una pantalla de detalle es "quién ve qué". Antes del refactor, cada pantalla respondía a esta pregunta a su manera. La pantalla de tareas listaba una carpeta asignada con una insignia. La pantalla de notas mostraba una lista plana de miembros. La pantalla de eventos mostraba una sección "Participantes" separada del resto.

El nuevo componente TaskAccessTree reemplaza estas tres lógicas con una estructura de dos ramas claramente etiquetadas:

• Rama "propietario": la persona que creó la tarea o la nota. Visualización mínima, avatar más nombre, nada más.
• Rama "grupos compartidos": cada grupo en el que el contenido es visible, con la lista de miembros involucrados en forma de avatares apilados. Si la tarea se comparte en tres grupos, se muestran tres subramas.

El interés de esta estructura de dos ramas es que responde a dos preguntas diferentes sin mezclarlas. Quién es el propietario: rama 1. Quién ve el contenido además del propietario: rama 2. No hay confusión posible. Un usuario puede de un vistazo comprender quién tiene acceso, sin leer una sola línea de texto.

Cuando la jerarquía de migas de pan desaparece

Otro detalle de refactor, invisible cuando todo va bien pero horrible cuando aparece: el rastro de migas de pan de las carpetas padre. Si tu tarea está organizada en Familia > Compras > Supermercado, la pantalla muestra esta ruta en la parte superior como un breadcrumb. Perfecto.

Problema: algunas tareas no están organizadas en ninguna carpeta. Están en la raíz. El breadcrumb mostraba entonces un espacio vacío, luego una flecha, luego nada, luego el título. Un artefacto visual que daba la impresión de que la pantalla estaba mal cargada.

La solución es trivial cuando se piensa: si la lista de padres está vacía, no se renderiza el componente. Dos líneas de código, un error visual menos, y la pantalla respira. Es típicamente el tipo de pulido que ningún usuario notará conscientemente, pero que todos sentirán subconscientemente como "esta aplicación está cuidada".

Las etiquetas prefijadas con hashtags

Las etiquetas se mostraban sin prefijo ni encabezado. Una lista plana de palabras colocadas debajo del contenido. Visualmente, se mezclaban con el texto principal y no se identificaban inmediatamente como etiquetas.

La nueva representación añade dos cosas simples:

1. Un encabezado "Etiquetas" encima de la lista, para que el ojo sepa de inmediato de qué se trata.
2. Un prefijo # delante de cada etiqueta, convención tomada de las redes sociales y que todo el mundo conoce.

El resultado es inmediato: una tarea que tiene cinco etiquetas ahora muestra una línea clara como #urgente #compras #fin_de_semana #familia #comida, imposible de confundir con texto normal.

El mismo orden de secciones en las tres pantallas

En cada pantalla, las secciones ahora siguen este orden:

1. Título y estado (o fecha para un evento)
2. Árbol de acceso (TaskAccessTree)
3. Carpeta padre asignada (con la misma tarjeta visual en todas partes)
4. Etiquetas (con encabezado y prefijo #)
5. Contenido principal (descripción, texto de nota, detalles del evento)
6. Recordatorios y recurrencia (si aplica)
7. Archivos adjuntos (si presentes)
8. Historial y actividad (comentarios, reacciones)

Pasar de una tarea a una nota y luego a un evento ahora proporciona una continuidad visual total. Tú aprendes una vez dónde hacer clic, y luego no aprendes nada más. Una ganancia de unos pocos milisegundos por consulta, que se convierte en minutos al día y horas al mes para un usuario regular.

Las características invisibles hacen las aplicaciones que conservamos

Nadie lanzará TAMSIV mañana diciendo "oh, genial, la pantalla de detalles de la tarea está alineada con la de la nota". Las características invisibles no se anuncian. No se venden. Se sienten.

Este sprint de 3 días y 40 commits no produce ninguna captura de pantalla de marketing. Ningún botón nuevo que mostrar. Ninguna animación cinemática. Y sin embargo, es exactamente el tipo de trabajo que marca la diferencia entre una aplicación que se instala y se olvida, y una aplicación que se conserva y se recomienda.

Los 10 días anteriores, fue un sistema completo de correos electrónicos transaccionales. Los 3 días siguientes, fue la uniformización de las tres pantallas de detalle. Y mañana, será otra cosa igual de invisible. La aplicación crece, pero siempre en silencio.

Lo que este refactor permitirá más adelante

El otro beneficio de esta uniformización es que allana el camino para futuras características mucho más rápidamente. Cuando las tres pantallas comparten la misma estructura, añadir una nueva sección (por ejemplo, un recuadro "traducido automáticamente" para una nota de voz en un idioma diferente) se hace una sola vez y se aplica en todas partes.

Antes del refactor, añadir una sección transversal suponía codificarla tres veces, con tres variantes de estilo y tres ubicaciones a negociar. Después, es un componente compartido que se inyecta en todas las pantallas de detalle. El coste marginal de añadir una nueva característica se divide por tres.

Este es el verdadero beneficiario oculto de esta semana: no el usuario de hoy que solo verá una aplicación más coherente, sino el desarrollador individual que construirá las próximas 40 características en un tercio del tiempo.

Y mientras tanto, 22 redirecciones SEO antiguas

Paralelamente a la uniformización de las pantallas, corregí un problema de redirección en el sitio. Las primeras pasadas de traducción del blog habían dejado 22 slugs obsoletos en DE, ES, IT y PT, que devolvían 404 en Google. Cada slug obsoleto ahora se redirige de forma permanente (301) a su versión actual.

El archivo x-default del sitemap también se corrige, para que los motores de búsqueda entiendan cuál es la versión canónica de cada artículo cuando el idioma del usuario no es determinable.

Son 22 líneas en un archivo de redirección de Next.js, 22 errores de indexación menos, y potencialmente 22 rutas de visitantes recuperadas en lugar de perdidas.

Preguntas frecuentes

¿Uniformizar las pantallas de detalle hace que la aplicación sea más rápida?

Técnicamente, marginalmente. Los componentes compartidos se renderizan en caché de manera más eficiente, y el paquete Javascript disminuye aproximadamente un 3% gracias a la deduplicación de código. Pero la verdadera ganancia es cognitiva, no técnica: el usuario se siente más rápido porque navega con menos fricción mental.

¿Por qué no se hizo esta uniformización antes?

Porque mientras las tres pantallas evolucionaban por separado y aún no se sabía qué secciones emergerían como transversales, intentar uniformar habría sido prematuro. Primero era necesario que cada pantalla descubriera sus propias necesidades, y luego extraer los patrones comunes una vez que fueran estables.

¿Qué impacto tiene para alguien que usa TAMSIV por primera vez?

Un recién llegado aprende primero la pantalla de tareas. Antes del refactor, tenía que volver a aprender la pantalla de notas y la pantalla de eventos. Después, reconoce instantáneamente los elementos, y su curva de aprendizaje pasa de tres niveles a uno solo. La incorporación se divide por tres en tiempo percibido.

¿Un usuario notará la diferencia?

Probablemente no conscientemente. El refactor está diseñado para ser invisible. Pero si se le pregunta a un usuario que usaba la aplicación antes y después qué ha cambiado, a menudo dirá "la aplicación me parece más coherente" o "encuentro mi información más fácilmente", sin saber explicar exactamente por qué.

¿El refactor ha roto algo en la versión móvil?

Se realizó una auditoría completa después del despliegue. No se detectó ninguna regresión funcional. Las animaciones de transición entre pantallas incluso se han fluidificado ligeramente porque los componentes compartidos permiten una renderización más predecible por React Native.

Disponible en Play Store, 6 meses y más de 780 commits

TAMSIV está disponible en producción en Google Play desde el 2 de abril. Gratuito, 6 idiomas, desarrollo individual. La aplicación sigue evolucionando cada día, mayoritariamente en silencio. Son el 80% invisible lo que hace que se mantenga instalada.