Buenas prácticas

En ocasiones el sistema puede parecer que no responde a nuestras necesidades.
‍
En estos casos, podemos emprender algunas exploraciones para resolver el problema en cuestión, pero es crucial que validemos estas soluciones con el sistema para ver si hay algún elemento ya existente que pueda proporcionar una solución.
‍
Además, tenemos una visión más amplia de otros proyectos, por lo que podemos sugerir o proporcionar soluciones que otros equipos ya han implementado.

El propósito del fragmento es servir a su componente. El fragmento se define dentro del componente, no debe usarse fuera de ese contexto.

Puede usarse de inspiración o referencia para realizar exploraciones, pero una vez validados, hay que alinearse con el sistema.

Si estamos en web mobile debemos tener en cuenta los siguientes puntos:

• No usamos componente de la librería de APP para web mobile. Son librerías distintas, con patrones de interacción distintos.
• Podemos usarlos como referencia, y pueden llegar a formar parte de la librería de web, pero hace falta validar.

Al utilizar un componente, si este no cubre nuestra necesidad:

• No deberíamos posicionar elementos por encima del componente ocultando los existentes para adaptarlo a nuestro caso de uso
• En la mayoría de casos se puede hacer swap o adaptar el componente sin detachear
• Podemos proponer mejoras o modificaciones al sistema

Se pueden usar a modo exploratorio. Una vez encontramos la solución buscada, se debería comunicar a sistema para que lo trate como un elemento transversal.

Si tenemos un elemento de diseño que aparecerá de forma recurrente a lo largo del archivo, es recomendable que creemos un componente. Esto nos permitirá:

• Ahorrar tiempo
• Realizar cambios de forma rápida, solo hay que cambiar el componente
• Mantener cohesión del diseño
• Posibilidad de convertirse en un elemento de área privada que puedan utilizar otros equipos
• Evitamos que nos olvidemos de un elemento que no hemos actualizado al nuevo diseño

Al reutilizar componentes, deberíamos consultar en la documentación hasta dónde está permitido hacer ajustes en tokens de color y texto. Por lo general:

• Los tokens de color no se deben eliminar/modificar
• En algunos casos se puede ajustar tamaños de texto mientras se mantenga la jerarquía (titular-body-caption)Ahorrar tiempo

Bajo ningún concepto. Cualquier propuesta o necesidad de nuevo icono, se mete en librería previa revisión por el equipo del sistema. El paquete iconográfico es transversal a todos los productos y respetarlo es crítico para evitar conflictos con desarrollo y contribución.

Bajo ningún concepto, las Foundations son sagradas. Cualquier propuesta de estilos nuevos se debería validar con el sistema. El sistema de colores de Oxygen tiene un reflejo en producción y para poder mantener los productos, se debe respetar.

‍
Tampoco se deben utilizar colores globales de visualización de datos para cubrir necesidades fuera de su contexto.

Es muy importante para el buen funcionamiento de todo el sistema que tengamos una metodología de trabajo estable, validada por todos y que escale a los diferentes tipos de productos y equipos de trabajo. Este es un resumen del modelo actual:

• Task: Toda tarea que esté abierta y en la que estemos trabajando. Este es el lugar de las exploraciones.
• Main: Para archivos entregados a desarrollo. Fuente de verdad que no se actualiza ni se modifica -> Si necesitas modificar algo pequeño se trabaja con mediante Branches.
• Archive: Pensado para guardar todo lo que ya no esté siendo usado, ni por diseño (tasks que se quedan en el camino, investigaciones...) ni por desarrollo, archivos que estuvieron en Main, pero ya no se está trabajando con ellos.