Darkmode: Mer enn bare estetikk
Darkmode har gått fra å være en kul funksjon til å bli en forventning. Det er ikke lenger bare et spørsmål om estetikk, men også et viktig aspekt ved tilgjengelighet og brukervennlighet. Nå er tiden inne for å bringe temastøtte til Aksel.
Darkmode gir valgfrihet
Darkmode gir mindre lysstyrke, noe som kan gjøre at øynene blir mindre slitne, spesielt i mørke omgivelser. Dette er veldig relevant for de som jobber mye foran skjermen, og for de som bruker våre tjenester sent på kvelden eller i mørketiden. Det er derfor ikke så overraskende at de fleste ønskene om darkmode kommer fra ansatte som jobber lange dager med fagsystemene til Nav.
Et annet viktig poeng er lesbarheten. For noen er det lettere å lese tekst på mørk bakgrunn, mens for andre vil en lys bakgrunn være best. Vi har derfor jobbet mye med farger og kontraster for å sikre at innholdet er lett å lese i begge modusene. Darkmode gir deg mer fleksibilitet når det kommer til dine preferanser og behov, som da igjen vil gjøre opplevelsen bedre for enda flere.
I tillegg er det flere som bare rett og slett foretrekker mørk modus. Mange opplever at det ser bedre ut, og at det er mer behagelig å bruke. Hvis du i utgangspunktet jobber i et darkmode miljø, vil det være forstyrrende at noen av løsningene er i lightmode.
Uansett grunn, synes vi det er viktig å gi brukerne mulighet til å velge selv.
Er du interessert i å lese mer om fordelene med darkmode har Nielsen Norman Group en fantastisk artikkel på dette. Under er en liten oppsummering fra artikkelen:
(...)we strongly recommend that designers allow users to switch to dark mode if they want to — for three reasons: (1) there may be long-term effects associated with light mode; (2) some people with visual impairments will do better with dark mode; and (3) some users simply like dark mode better.
Utforming av ny fargepalett
Farger
Når vi designer for darkmode, er det ikke bare å invertere fargene. Det krever en ny forståelse av hvordan visuelt hierarki fungerer. I lightmode er vi vant til å bruke lysere bakgrunner og mørkere elementer for å skape fokus. Men i mørk modus må vi tenke annerledes for å sikre at viktige elementer fortsatt skiller seg ut og at strukturen er like tydelig. Navs digitale løsninger inneholder mye viktig informasjon, og det er da viktig at elementene som fremhever den informasjonen ikke mister mening på tvers av fargetema.
Vi merket at duse fargede bakgrunner som funker godt i lightmode kan bli ganske grelle i darkmode. I lightmode må fargemetningen være høy for at fargen skal være synlig, men i darkmode blir den for sterk. Derfor justerte vi ned fargemetningen på de fleste duse fargene i darkmode. Noen farger funker rett og slett dårlig i darkmode, uansett hva vi gjorde. Vi har en dus oransje-beige bakgrunnsfarge i lightmode som forvandles til en mindre pen brun i darkmode.
I sånne situasjoner må vi endre fargen som blir brukt i darkmode. Vi regner med at vi må gjøre justeringer fremover også når det nye systemet tas i bruk. Siden vi bruker design tokens vil løsningene oppdateres uten plunder og heft 🤩
Kontrast
I det gamle fargesystemet vårt var ikke kontrastnivåene like på tvers av fargene. Eksempelvis hadde ikke blue-500 lik kontrast som orange-500. Det gjorde det vanskelig å lære seg et system for hvilke farger som skulle brukes for å tilfredsstille de ulike kontrastkravene.
I det nye systemet bestemte vi oss for å bruke verktøyet Leonardo for å hjelpe oss med å lage nye fargeskalaer. I Leonardo satte vi opp skalaene etter kontrastnivåer og brukte en fargetype som kalles OKLCH. Fordelen med OKLCH er at den definerer farger basert på hvordan mennesker oppfatter lyshet og fargestyrke. Resultatet er at vi kan lage fargeskalaer som oppleves uniforme på alle nivåene. Deretter justerte vi kontrastnivåer, fargestyrker og fargetoner med visuell testing på alt fargene brukes til i forskjellige situasjoner.
Som man ser på den nye skalaen, vil den ikke tilsvare bruk 1 til 1 som den gamle skalaen. Vi har derfor også gjort et større arbeid med å utarbeide et semantisk lag som effektivt bruker de nye fargene for å kunne lage gode grensesnitt.
Det er ikke så lett å se skygger i mørket
I Aksel måtte vi se kritisk på alle komponentene våre for å tilpasse dem til darkmode. Før brukte vi skygger og gråtoner, som måtte byttes ut med andre virkemidler for å skape den samme dybden og distinksjonen i darkmode. Dette førte til at vi tonet ned bruk av skygger, og lente oss mer på borders for å skape et tydelig visuelt hierarki.
Slik vi ser i eksempelet over, vil virkemidler som skygger miste mye av effekten sin i darkmode, og i høykontrast forsvinne helt. Med et flatere utrykk får vi tydeligere design på tvers av tema, og ved bruk av border får vi bedre støtte for høykontrast.
Men border løser ikke nødvendigvis alt, og vi trenger fortsatt noen metoder for å indikere et hierarki. Derfor introduserer vi to nye tokens for bakgrunnsfarger: sunken
og raised
.
Utforming av design tokens
Implementeringen av darkmode i Aksel var ikke bare en visuell oppgradering; det var en teknisk og organisatorisk utfordring som krevde planlegging og tett samarbeid. Når en endring treffer hele tech-stacken vi tilbyr, gjelder det å ha litt is i magen og dele problemet opp i håndterbare biter.
Grunnlaget for reisen startet med design tokens. Selve strukturen for hvordan vi bygger opp komponenter og systemet vårt er basert på godt forarbeid med våre design tokens. Vi har lent oss på disse tidligere erfaringene for å iterere oss frem til det nye systemet.
Erfaringer fra gammelt system
Da vi høsten 2022 valgte å oppdatere til et nytt fargesystem, var dette en reaksjon på at det foregående systemet fra 2020 ikke lenger dekket behovene våre i følge med nye komponenter. Vi endte ofte opp med å bruke "feil" token for å løse problemer, da systemet ikke var tilpasset behovene for mer komplekse design og kontekster. Denne utfordringen ble forsterket av alle ulikhetene i fargemetning og kontrast, som nevnt tidligere, da "riktig" warning-token ikke nødvendigvis så lik ut som tilsvarende success-token.
Det kan diskuteres hvor problematisk det er at "feil" tokens blir brukt internt i designsystemet, men for oss var dette et symptom på at noe ikke fungerte som det skulle. Hvis vi som laget token-systemet ikke klarer å bruke systemet riktig, hvordan kan vi forvente at teamene våre skal klare å lage gode visuelle løsninger med dem?
Som reaksjon på dette utformet vi et system som vi i etterkant mener var for å: Bygge gode løsninger for våre brukere, med mye inspirasjon fra Polaris og Carbon som vi på den tiden mente var de beste på dette. I retrospektiv var dette kanskje feil retning, og vi bommet på hva vi faktisk ønsker å oppnå: Hjelpe teamene våre med å bygge gode løsninger. Systemet må være laget for bruk av teamene våre, ikke bare Aksel.
Løsningen er Darkside
Globale tokens
Vi startet med å redusere antall "lag" vi forholder oss til. Det globale laget som før brukte fargenavn som green og blue, har nå fåttt navn etter hva de brukes til, f.eks accent og success. Disse navnene er det vi kaller en "rolle", der de fleste fargene har en egen distinksjon for hva de skal oppnå ved bruk.
Likere struktur for semantiske tokens
I det forrige systemet endte vi opp med ulike sett med semantiske tokens for de ulike rollene. Dette førte til at action, neutral, status og alt-farger alle hadde ulike strukturer for tilgjengelige tokens. Dette, kombinert med at noen av dem også inneholdt alpha, gjorde systemet vanskelig å lære, huske og ta i bruk. Siden alle fargene nå har lik fargemetning og lyshet, har vi samlet alle roller og gir dem de samme tokens. Det er bare én samlet skala for alle fargene, og default-skala har samme tokens som rollene. Du trenger derfor ikke lengre å lære mange ulike "systemer", men bare disse to.
Token navn | Default-skala | Rolle-skala |
---|---|---|
Default | ✅ | ✅ |
Soft | ✅ | ✅ |
input | ✅ | |
raised | ✅ | ✅ |
sunken | ✅ | |
overlay | ✅ | |
hover | ✅ | ✅ |
hoverA | ✅ | ✅ |
moderate | ✅ | ✅ |
moderateA | ✅ | ✅ |
moderate-hover | ✅ | ✅ |
moderate-hoverA | ✅ | ✅ |
moderate-pressed | ✅ | ✅ |
moderate-pressedA | ✅ | ✅ |
strong | ✅ | ✅ |
strong-hover | ✅ | ✅ |
strong-pressed | ✅ | ✅ |
Komponent tokens
I 2023 introduserte vi muligheten for å tilpasse spesifikke deler av en komponent med egne tokens. Vi ønsket med det å teste outsourcing av temastøtte, noe som frem til nå har resultert i over 450 tokens for alle komponentene våre. Vi gjennomførte en review av alle tokens brukt i Nav sine Github-repoer:
Når vi dykket ned i hva disse 6 repoene gjorde, viste det seg at de fleste laget sin egen darkmode. Vi mener derfor at ved å tilby innebygd støtte for darkmode, vil behovet for komponentspesifikke tokens være mindre og derfor ikke fortjene den koden og kompleksiteten det medførte. Vi fjerner derfor støtten for komponent tokens i det nye systemet.
Referansesider
Når vi skulle starte dette arbeidet var det viktig for oss at vi ikke utførte arbeidet i isolasjon, men tok utgangspunkt i noe som allerede eksisterte. Vi startet derfor prosessen med å finne fem eksisterende sider som referanse for åpne sider, innloggede sider og fagsystemer. Disse sidene ble brukt gjennom arbeidet til å kartlegge behov, teste endringer, og til slutt validere at endringene vi gjorde faktisk fungerte i ulike kontekster.
Det var gjennom denne metodikken vi oppdaget flere ukjente utfordringer og fikk testet ulike løsninger på disse. En av disse er bg-input
token, som vi ikke har hatt tidligere. I lightmode er skjemaelementer lett synlige ved bruk av border og uten andre hjelpemidler, men i darkmode opplevde vi at skjema var mindre synlig. Løsningen på dette var å legge til en ny token: bg-input
som blir mørkere i darkmode, og da fremhever skjemaelementene.
Så må vi skrive litt kode da
Heldigvis for oss, er darkmode ikke ny teknologi. Vi kunne derfor ta lærdom fra andre designsystem og bruke allerede testede teknologier for dette. Det er alltid en god dag når man ikke trenger å finne opp hjulet på nytt. Så hva betyr da dette for implementasjonen vår?
CSS first!
Kort oppsummert, så lenge du bruker CSS-pakken vår @navikt/ds-css
følger det med støtte for darkmode. Alt du trenger å gjøre er å legge på klassen .dark
eller .light
så får alt i cascaden riktig fargetema. Alt er bygd på CSS custom properties og ingen av komponentene våre har "theme"-spesifikk styling som bare blir satt på ett av fargetemaene nå.
En del av økosystemet
Gjennom årene har det blitt flere metoder å konsumere Aksel på. Kanskje bruker du bare Tailwind, bare CSS, eller flere deler i samme prosjekt. Uansett teknologi eller rammeverk skal Aksel kunne brukes. Vi ønsker ikke at det skal være flere metoder å implementere darkmode på, men én som fungerer ut av boksen for alle rammeverk. Heldigvis for oss fungerer CSS custom properties til det aller meste vi har behov for:
Veien videre
Vi jobber nå med å samle løse tråder og sikre at oppdateringen til nytt system blir så enkelt som mulig. Dette innebærer dokumentasjon, codemods, guider og testing ute hos team.
Testperiode
I T1 2025 vil vi jobbe sammen med noen team for å teste nye tokens og darkmode i reelle løsninger.
Vi har snakket mye om darkmode her, men den nye oppdateringen inneholder også ny lightmode som erstatter dagens versjon av designsystemet. I starten av 2025 vil dette være opt-in, slik at alle fortsatt kan få oppdateringer fra Aksel uten å måtte migrere til nytt system. Når vi føler oss trygge på testresultater, dokumentasjon og migreringshjelp, vil vi publisere ny versjon.
Disse endringene vil bli gjort til standard gjennom en major-versjon i løpet av 2025.
Dokumentasjon på dette vil komme fortløpende gjennom T1 2025, slik at ditt team kan teste og oppdatere i god tid før vi kommer med ny versjon.
Bidragsytere
Flere blogginnlegg
Aksel med oppgradert design
Snart kommer en ny versjon av Aksel med flere stiloppgraderinger for våre komponenter. Da får vi blant annet darkmode-støtte, forbedret fargepalett, færre skygger og litt rundere hjørner.
Jørgen Maristuen
Aksel med oppgradert design
Snart kommer en ny versjon av Aksel med flere stiloppgraderinger for våre komponenter. Da får vi blant annet darkmode-støtte, forbedret fargepalett, færre skygger og litt rundere hjørner.
Jørgen Maristuen
Hvordan produktstrategien samler teamet vårt
Produkstrategi er noe litt ullent. I denne artikkelen skriver vi litt om hvordan Team Datajegerne jobber med dette og viser hvordan strategien vår ser ut.
Louis Dieffenthaler
Hvordan produktstrategien samler teamet vårt
Produkstrategi er noe litt ullent. I denne artikkelen skriver vi litt om hvordan Team Datajegerne jobber med dette og viser hvordan strategien vår ser ut.
Louis Dieffenthaler