Closed MontseTelefonica closed 5 months ago
Hola @MontseTelefonica,
Los tokens controlInverse
y controlActivatedInverse
se añadieron en la PR: https://github.com/Telefonica/mistica-design/pull/1548 como solución a https://github.com/Telefonica/mistica-design/issues/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 https://github.com/Telefonica/mistica-design/issues/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.
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: https://github.com/Telefonica/mistica-design/issues/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í.
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.
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.
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
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?
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!
Buenas @MontseTelefonica y @lauraocana,
El token controlInverse
no está siendo utilizado actualmente en desarrollo. Dicho esto veo 3 vías:
controlInverse
en Mistica para que tome el color que se ha definido para las gráficas.controlInverse
.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 (https://github.com/Telefonica/mistica-design/issues/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.
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).
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?
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?