More flexible color theming

[mrosvik]

Møte "Fargefloka" 4. september 2024

Udir har delt sin erfaring med bruk av temabyggeren og tokens-oppsettet.

Hovedproblem

Slik tokens er satt opp nå med èn accent-farge, er ikke systemet fleksibelt nok. Udir og Mattilsynet har grønn som primærfarge. De ønsker denne grønnfargen på noen av de interaktive komponentene, men den passer seg ikke til alle. Når den samme fargen brukes på alle interaktive element blir det en for høy vekting av denne fargen (den blir mer fremtredende enn ønskelig).

Det er ikke gitt at radioknapper og vanlig knapper MÅ ha samme farge. Dette vil være ulikt fa organisasjon til organisasjon. Vi må lage det fleksibelt nok til at en virksomhet selv kan bestemme om Button skal ha samme farge som radio f.eks.

Forslag om å utvide accent

• Det ble foreslått å utvide accent til flere skalaer.
• Eksempel fra token-struktur hos Møller: https://gnist.moller.no/latest/?path=/docs/foundation-colors-overview--docs

Komponent-tokens eller ikke?

• Fordel: De gir mulighet til å sette en komponent til accent og en annen til neutral f.eks. Det gir deg veldig mye fleksibilitet.
• Ulempe: Det blir veldig komplekst både å lage og holde oppdatert hvis noen endrer disse verdiene.

Oppfølgingspunkt

• [x] Teste om vi kan utvide fargeskalaen med flere farger. Utvide accent til flere skalaer.
• [x] Hvordan løser vi dette i praksis? I Figma og i kode? Enten gjennom varianter i Figma, eller gjennom tokens-logikk.
• [x] Arbeidsmøte med teamet for å se på mulige løsninger
• [x] Presentere forslag til Udir

### Tasks
- [ ] https://github.com/digdir/designsystemet/issues/2373
- [ ] https://github.com/digdir/designsystemet/issues/2507
- [ ] https://github.com/digdir/designsystemet/issues/2655

[Febakke]

Å legge til flere skalaer tenker jeg er uproblematisk fra et Figma/design perspektiv, men utfordringen blir hvordan legger vi til denne fleksibiliteten? Jeg ser for meg tre mulige løsninger akkurat nå og tar gjerne forslag på andre 😄

1. Varianter av komponenter. For komponenter hvor det er aktuelt kan vi legge til fargevarianter slik vi gjør med button i dag. Da vil designeren kunne bestemme hvilken variant de trenger i designet. Det er nok den enkleste implementasjonen da vi ikke trenger noen store endringer på tokensstrukturen... Meeeen

   • Hvis jeg som designer har ansvaret for å sette opp komponentbiblioteket for min organisasjon, så ville jeg låst det til riktig variant. (Vi bruker alltid accent varianten av button. Den enkleste måten å gjøre dette på ville vært å fjernet de uaktuelle variantene. Men det vil kreve litt vedlikehold når det kommer nye varianter.
   • Komponentbiblioteket vil bli ganske mye større, det vil si mer vedlikehold og større sjanse for feil

2. Vi kan løse det i Token strukturen på samme måte som vi løser ulike brands i dag. At man setter en kontekst på selve masterkomponenten for hva deres designsystem skal bruke.

   • Jeg vet ikke om vi ønsker enda mer kompleksitet i token strukturen. Det kan fort bli veldig kaotisk og vanskelig å få oversikt over hva som styrer hva.
   • Vi vil få samme problem som på nr. 1 at designere innad i organisasjoner lett kan endre kontekst slik at knapp får en annen farge enn det som skal brukes.

3. Kanskje det enkleste er det beste? Om vi lager et default oppsett hvor vi har satt de nye fargeskalaene til å peke på "fornuftige" komponenter. Så kan designere enkelt endre hvilken tokens som er satt til komponentene for å endre det.

   • Uten komponenttokens i Figma vil det ikke være definert i koden/tokens hvilken farger som peker på hvilke komponenter. Det kan fort bli en kilde til feil mellom Figma og kode.
   • Oppdateringer av tokensstrukturen vil være enkelt å oppdatere uten store problemer, men oppdateringer av Figma komponentene vil kreve litt manuelt arbeid av designeren for å endre tokens de gangene det blir aktuelt.

[Febakke]

En liten utfordring til! Mitt inntrykk er at det veldig ulikt hvordan fargesystem er laget for profilene til ulike aktører, det gjelder også hvor mange farger de forskjellige aktørene har.

Om vi nå setter det opp med primær, sekundær og accent. Vil en virksomhet kunne si at de kun trenger primær og accent? Hvordan vil det påvirke token strukturen. Eller skal vi be dem om å legge til flere farger i så fall?

[mimarz]

Første jeg tenker er en kombinasjon av alternativ 2 (som @Febakke foreslår) og neutral color på form components (og/eller generelt alle som har accent farge).

En begrensning blir antall sets du kan ha i Figma (4stk) utenom enterprise prising, og at de kan fritt endres i Figma?

Vi kan så utvide koden til at du bestemmer hvilket tema/brand/kontekst som brukes på en kontekst. Da vil de i kode hvertfall kunne definere det i sine "wrapper" komponent for designsystemet.

Pseudo-kode:

// Primær accent grønn farge
<UdirButton>
  <Button data-ds-theme="udir" />
<UdirButton>

// Tonet ned grønnfarge?
<UdirFormButton>
  <Button data-ds-theme="udir-subtle" />
<UdirFormButton>

// Eller bare bruke atributtet uten wrapper komponent
// Alle komponentene vil følge tema "udir-subtle"
<div data-ds-theme="udir-subtle">
 <form>
   <Textfield />
   <Fieldset />
   <Checkbox />
   <Radio />
   <Button data-ds-theme="udir"> // <- Dersom du ønsker unntak fra inneværende tema
</Fieldset>

 </form>
</div>

[Febakke]

Tenker du at dette løses noe som dette i Token strukturen?

1. Primary, secondary og accent må ligge som hex koder i primitives. For å støtte dark/light/kontrast modes
2. De blir sendt videre til brand collection slik at man kan endre mellom for eksempel Digdir og Altinn
3. Mellom brand og det semantiske laget må vi legge til et set til som tar i mot primary, secondary og accent. Her vil man kontekst styre hvilken farge som vil bli sendt til det semantiske laget.

NB: En konsekvens av dette vil være at du ikke kan bruke primary og secondary i samme kontekst.

[mimarz]

Tenker du at dette løses noe som dette i Token strukturen?

Nei, tenker vi kunne løst det uten å røre tokens-strukturen. Det blir bare litt justeringer på det rundtliggende.

[Febakke]

Om vi ikke endrer token strukturen må vi gå for løsning 1 eller 3 som jeg nevnte over her. Jeg er ganske sikker på at 1 blir uaktuelt da det vil gjøre komponentbiblioteket gigantisk. 3 tror jeg er mer realistisk og vil fungere bra så lenge de som tar det i bruk ikke skal endre mellom accent og primary på button. (En work-around er jo at de lager varianter internt der de trenger det)