ControlInverse y ControlActivated son iguales

[MontseTelefonica]

Describe the bug

Hola! Usamos los colores control y control activated en las gráfica de facturas, y nos hemos dado cuenta que al pasarlo al inverse los colores se ven iguales: blancos.
¿Esto es un bug o es expected?

Quizás no deberíamos usar esos tokens para las graficas y deberíamos usar otros.

What libraries are you seeing the problem on?

No response

Steps to reproduce

apply color preset ControlInverse and ControlActivatedInverse to 2 elements and check they are the same.
See example

Expected behavior

Necesitamos aplicar a las barras de gráfica constantes de color que funcionen bien sobre fondo blanco, inverse, alternative y dark mode. ¿Puede cubrir Mistica esta necesidad?

[aweell]

Hola @MontseTelefonica,

Los tokens controlInverse y controlActivatedInverse se añadieron en la PR: #1548 como solución a #1369

En el caso de las tabs inverse únicamente se utilizó controlActivatedInverse y controlInverse se introdujo planteando ya la necesidad que habíamos identificado en un análisis realizado para resolver #736.

Como resumen, este análisis plantea una solución a los controles actuales, en concreto: radio-button, checkbox y switch, los cuales no funcionan sobre fondos inverse.

En concreto, el uso actual que se le está dando al token control es en los estados inactivos

Radio-button:

Checkbox:

Switch (*)

(*) En el caso de iOS este color no es customizable y será siempre #E9E9EA

En el caso de los switch de Android incluso al revisar este análisis hoy, quizás haya cosas que se tengan que revisar. No olvidemos que esto es aún una tarea en el backlog sobre la que debe trabajarse.

Dado que para el checkbox y el radio, no es el color únicamente lo que diferencia los estados activo / inactivo, que estos dos colores sean iguales a priori no se plantea como un problema.

Token barTrack & barTrackInverse

Hace poco y a raíz de una petición de vivo, fue necesario crear el token trackBar, que se usa actualmente para los tracks de la progressBar, slider y stepper.

Issue: #1615

Conceptualmente me encaja, que de solucionar este problema con un token de Mística, sea un posible barTrackInverse el que se utilice para las barras inactivas en vez de usar control. No sé @yceballost y @AnaMontes11 lo que opinan aquí.

Solución sobre alternative

Necesitamos aplicar a las barras de gráfica constantes de color que funcionen bien sobre fondo blanco, inverse, alternative y dark mode. ¿Puede cubrir Mistica esta necesidad?

Aquí aunque mantuvieramos control en alternative, en casos como blau, no diría que funciona exactamente muy bien, por tanto habría que encontrar otra solución.

Token extended

El tema de hacer unos tokens extended creo que debería barajarse, independientemente de que haya exista una solución futura para este problema o no.

Para este caso de uso van a proporcionar la seguridad de que ninguna actualización de componentes de Mística que no tienen que ver con la gráfica requieran un retrabajo en la misma.

[yceballost]

Mmm tengo mis dudas, aunque en su apariencia es cierto que es una bar.. en su uso es más parecido a un control, no? Tiene los estado inactivo y activo caracteristico de los controles 🤔 (y al final entiendo que debería tener una consistencia más parecida a un control que a una barra de progreso)

Esto abre un mundo también a esos tokens para gráficas... no estaría mal pensar en eso también para ese futuro

[MontseTelefonica]

Gracias por la explicación Alex, me queda mucho más claro. En este caso nos corre un poco de prisa pues se necesita para la new new App. ¿Cómo creéis que debemos proceder entonces?

[lauraocana]

Exacto, el tema es el que comenta Montse, necesitamos dar solución ASAP ¿qué opción veis más viable, pensar en tokens para gráficas en Mística o abrir la puerta de token extended para este caso? Thanks!

[aweell]

Buenas @MontseTelefonica y @lauraocana,

El token controlInverse no está siendo utilizado actualmente en desarrollo. Dicho esto veo 3 vías:

1. Modificar el token controlInverse en Mistica para que tome el color que se ha definido para las gráficas.
2. Crear un token extended para ese caso que tenga independecia de controlInverse.
3. Hacer una definición para los tokens de las gráficas en Mística

En el caso de tomar el camino 1 podemos cambiar el token, el riesgo es que potencialmente cuando abordemos la tarea de los controles en inverse (#736), no podemos asegurar que la solución siga estando alineada. Llegado a ese punto tendría que volver a valorarse el punto 2.

El punto 3 quizás no este alineado con la premura que necesita esta problemática.

Para intentar paliar ese futuro desalineamiento he hecho un análisis rápido de como funcionaria actualmente la nueva definición del token en los controles. Esta definición usa en light/inverse textNavigationBarSecondary menos en Blau que mantiene control y mantiene la definición actual de control en todas las marcas para dark/inverse.

https://www.figma.com/file/3Bwg2qAz2QjvevnN5HRUzr/ControlInverse-update-analysis?type=design&node-id=0%3A1&mode=design&t=8BI0kHx1Q8xw6tMG-1

A nivel de accesibilidad tanto el controlInverse actual como la propuesta pasan AA en Graphical objects en vivo, o2 y telefónica fallando en blau y movistar (Algo que considero que no tiene que ver tanto con el color del control sino con el background).

[MontseTelefonica]

Pues creo que un approach bueno sería modificar ahora el controlnverse y si en un futuro hay conflicto creamos el extended con calma. ¿Parece razonable el approach?