– Darkmode handler ikke kun om å se ut som en 1337 h4x0r

NAV om jobben mot darkmode, historietime om designsystemer og Storybook 8.5 i ukas ForrigeUke.

NAV forteller om hvordan de jobba med darkmode. 📸: aksel.nav.no
NAV forteller om hvordan de jobba med darkmode. 📸: aksel.nav.no Vis mer

Dette var uka for ulest lesestoff og en litt for menneskelig bestevenn — og 595 ting som skjedde i frontendverdenen!

Darkmode er mer enn estetikk

Tidligere denne måneden introduserte NAVs designsystem darkmode til designsystemet, og Ken Aleksander Johansen skrev en fantastisk bloggpost om veien dit.

Først, hvorfor skal du i det hele tatt bry deg om darkmode? Vel, det handler ikke kun om å se ut som en 1337 h4x0r. Hvor mange ganger har du ikke vært på en mørk nettside, for så å trykke på en ny fane som har en ytelsestest av lumen?

Darkmode handler om brukervennlighet. Brukere har ulik preferanse og ulik evne til å lese mørke eller lyse nettsider — så la brukerne velge.

Når det kommer til fargevalg, utbroderer Johansen hvorfor darkmode ikke kun innebærer å invertere alle fargene. Et enkelt eksempel på dette er at, ikke overraskende, så fungerer skygger ganske dårlig i mørket.

Implementeringen av darkmode var ikke bare fargevalg, men også en teknisk utfordring. Det krevde endring i struktur, mer spesifikt i hvordan tokensene var organisert. Underveis gikk teamet også fra et mål om å bygge gode løsninger til brukerne deres, til å hjelpe teamene deres med å bygge løsninger.

Historietime om designsystemer

Forrige uke ble en ny podcast for designsystemer lansert — “On Theme: Design systems in depth”. Og for å sparke showet igang, var det ingen ringere enn “Atomic design”- legenden Brad Frost som dukket opp.

I første episode diskuterer vert Elyse Holladay og Frost om hvordan dagens designsystemer ble til — og hvordan ordet “designsystem” i det hele tatt dukket opp.

Vi får et tilbakeblikk på da vi hadde egne nettsider for mobil, desktop og etterhvert iPad, og hvordan vi hadde egen kode for hvert stykke av nettsiden. Dette var en tid før ordet “komponent” var utbredt.

Vi turer innom hvordan Bootstrap hjalp å minske duplikat kode gjennom forhåndsdefinerte CSS-klasser, men innså at kun gjenbruk av stiler ikke var nok. Vi hører hvordan React forbedret komponent-tankegangen, men også hvordan det splittet opp CSS vekk fra resten av koden, og hvordan dette fortsatt er en utfordring i dag. Vi hører også om hvordan “designsystem” var noe som levde som et photoshop-prosjekt som kun designere jobbet i, til det nå også er noe utviklere forholder seg til.

Selv om designsystemer har hindret mye dobbeltarbeid og gjort appene våre mer konsistente, er det også noen slagsider ved disse fordelene. Designere mister mulighet for kreativitet, alle apper blir seende like ut og komponenter kan bli brukt feil. Ulempene nevnes kort i podcast-episoden, men for mer dybde kan jeg varmt anbefale Cam Worboys sitt foredrag “The broken promises of design systems”:

Storybook i versjon 8.5

Før Storybook ble til, hadde mange bedrifter sine egne improviserte løsninger for å visualisere komponenter. Selv om Storybook ikke er perfekt, er det mye du får ut av boksen, med en rask, standard oversikt over komponentene dine og en plattform du lettere kan teste komponentene dine.

Nylig ble versjon 8.5 lansert, og gjør nettopp testing enklere. Før hadde du UU-testing per story, men nå kan du kjøre tester på tvers i prosjektet, og lettere avdekke om komponentene dine er kosher. Dette gjelder også vanlige tester.

Det har også kommet ca. 100 andre forbedringer i versjon 8.5, som du kan ta en titt på her.

Det var alt for denne gang. Ha en riktig god uke! 👋