Design tokens en responsive gedrag

[jeffreylauwers]

Dit is de start van een verzameling aan vragen, tips en ideeën en testjes voor design tokens en responsive gedrag. En dan met name hoe dit in Figma is toe te passen.

Uitgangspunten

• Code = leidend
• Mobile first
• Uitweking zou in en uit te lezen moeten zijn door Token Studio / Style Dictionary.
• Uitwerking zou niet te complex moeten zijn. Liever geen complexe wiskundige formules, tenzij er een set aan 'sane defaults' is waardoor men niet noodzakelijk in hoeft te duiken.
• Uitwerking zou idealiter gelijkwaardige of snellere/langzamere groei moeten faciliteren.
• Aantal Figma component varianten moet te overzien blijven. Kan Figma variables hierbij helpen?

Handige linkjes

https://utopia.fyi/
Online tool om fluid type scales op te zetten.

https://fluid-tokenization.vercel.app/
Online tool om een fluid type scale op te zetten waarbij direct de tokens de kopieren zijn.

Fluid Design with Tokens - Youtube
Video waarin Marco Krenn van Token Studio uitlegt hoe je fluid design tokens kan inzetten met Token Studio.

Sam's fancy math equations in Tokens Studio - Substack
Uitgebreid artikel waarbij Sam beschrijft hoe je via Token Studio wiskundige regels kunt gebruiken. Niet zeker in hoeverre ons dit helpt maar ik deel hem hier wel alvast.

[jeffreylauwers]

Eerste uitvraag

Vrij snel na het opzetten van de eerste Figma componenten in combinatie met Token Studio vroeg ik me voor het eerst af hoe responsive gedrag hierbij ingebakken kon worden. Dit betrof toen als aanzet enkel een aanpassing in spacing.

Ik kwam toen tot het volgende voorstel. (Bekijk in Figma Schetsboek)

Viewport = Small
nl.card.padding-inline = 16px

Viewport = Medium
nl.card.padding-inline = 32px --> Waarde wijzigt buiten token naamgeving om. Als thema. Net zoals bijvoorbeeld dark-mode.
of
nl.card.vp-medium.padding-inline = 32px --> ‘Viewport’ (VP) in naamgeving. Een Button kan bijvoorbeeld ook ‘large’ of ‘small’ van zichzelf kan zijn. Zie afbeelding 2.
of
nl.card.{?}.padding-inline = 32px

Disclaimer: Bovenstaande tokens zijn puur als voorbeeld bedoelt.

[jeffreylauwers]

Voorstel tijdens Design Open Dag september

Tijdens de Design Open Dag van september zijn we hier met een aantal designers en developers nog eens naar gaan kijken. Op dat moment voelde we ons het meest senang bij de oplossing om de viewport grootte mee te nemen in de token naam. Het idee was om dan een vertaalslag te maken via Style Dictionary zodat dit op de juiste manier in code zou worden weggeschreven.

Voorbeeld bij een Heading 1 font-size:

• nl.heading-1.small-vw.font-size = 2.5rem
• nl.heading-1.large-vw.font-size = 3rem

Voorbeeld bij een Button inline padding:

• nl.button.small-vw.padding-inline = 16px
• nl.button.large-vw.padding-inline = 24px

Disclaimer: Bovenstaande tokens zijn puur als voorbeeld bedoelt.

[jeffreylauwers]

De uitdaging in Figma en Token Studio

De tokennaam gelijk houden
Je kunt de tokennaam gelijkhouden en in Token Studio een extra tokenset aanmaken specifiek voor een grotere viewport. Hier kun je vervolgens enkel de tokens in dupliceren waar bij responsive gedrag een verandering optreed. Maar wat doet dat voor de 'Apply to document' functionaliteit in Token Studio?

De tokennaam aanvullen met viewport grootte
Je kunt binnen Token Studio de tokennaam aanvullen met de viewport grootte. Er komt dat binnen dezelfde tokenset een token bij. Het aantal tokens neemt toe. Ook in de lijst met tokens naar de component. Is dit te overweldigend? En hoe is hiermee de aansluiting op Figma Variables?

Hier moeten we nog meer testjes van uitwerken. Wie helpt er mee? 😉

[RGRMdesign]

Voorbeeld toepassing op Paragraph component door tokennaam aan te vullen met vw aanduiding

Om responsive components te gebruiken in NORA heb ik het utrecht-paragraph component gekopieerd naar de Lokale bibliotheek van NORA. Zie het Figma Paragraph Component in de NORA Bibliotheek

Toelichting:

• Het utrecht.paragraph.font-size token is vervangen door:
  • utrecht.paragraph.small-vw.font-size en
  • utrecht.paragraph.large-vw.font-size
• Ik heb voor mijn toepassing de Variant 'Container' hernoemd naar 'Viewport Width'.

Voordelen

• Consumers van het Design System kunnen door middel van het wijzigen van de variant op de instance de weergave (Small of Large) aanpassen
• Consumers van het Design System hoeven Tokens Studio niet te gebruiken
• Globale updates (bijvoorbeeld font-family of color) kunnen met Tokens Studio toegepast worden op het gehele document (Apply to document) zonder dat de verschillende instances voor verschillende Viewport Widths overschreven worden

Nadelen

• Componenten kunnen veel tokens nodig hebben om het verschil tussen verschillende viewports te ontwerpen, de meest voorkomende zijn denk ik:
  • padding
  • font-size
  • line-height
• Ook is het gebruikelijk om voor meer dan 2 viewport widths te ontwerpen, vaak Small, Medium, Large. Het toevoegen en onderhouden hiervan kost tijd en energie doordat je tokens moet dupliceren en hernoemen.
• De tokennaam komt niet overeen met hoe die uiteindelijk (idealiter) in css zal bestaan. Het small-vw en large-vw gedeelte van de token zal daarin niet voorkomen als je deze in verschillende mediaqueries onderbrengt

[RGRMdesign]

Test met het gebruiken van verschillende token sets

Om te ervaren hoe het zou zijn om te werken met verschillende token sets het ik deze test opgezet: Figma VW Test.

Beevindingen en ervaringen staan gedocumenteerd in het Figma Design, voor de volledigheid plaats ik ze ook hieronder als screenshot.

[RGRMdesign]

Layers/Variants locken op een bepaalde combinatie van token sets in Tokens Studio

Een groot nadeel van het gebruik van meerdere token sets om responsive componenten te maken is dat je gauw instances per ongeluk overschrijft wanneer je globale updates doet en deze toepast op het gehele document.

Ik denk dat wanneer je bepaalde layers/variants zou kunnen vastzetten op een bepaalde combinatie van token sets (of thema) dit nadeel grotendeels opgelost is. Hiervoor heb ik een feature request ingediend bij de Tokens Studio Plugin, zie:

tokens-studio/figma-plugin#3178

[RGRMdesign]

Mobile/Small First benadering in tokennaam

Eerder was het idee om zowel .small-vw. als .large-vw. tokens te hebben. Ik ga nu bij NORA vanuit de Mobile/Small First gedachte de .small-vw. tokens weer terug hernoemen naar de originele naam (bijv. utrecht.paragraph.font-size). Dit heeft volgens mij de volgende voordelen:

• Small/Mobile First benadering
• De bestaande components, zonder viewport width tokens gaan niet stuk
• Met Style Directory hoeven straks de .small-vw. tokens niet in een media-query gezet te worden (komen standaard in :root)
• De workflow voor het uitbreiden met een variant voor grotere schermen is makkelijker, doordat je alleen tokens hoeft toe te voegen voor die viewport width zonder dat je de bestaande tokens hoeft te hernoemen

[RGRMdesign]

Viewport specifieke tokens naar een los css bestand

Ik heb voor NORA nu een implementatie gemaakt waarmee tokens met een large-vw aanduiding in de naam naar een apart css bestand worden geschreven.

Zie nl-design-system/themes#772

[AlineNap]

Uitwerking tokensets - tussentijdse update

Ik ben verschillende opties aan het uitwerken om daarbij de voor- en nadelen per gebruikersgroep te onderzoeken.

Gebruikersgroepen

Er zijn 3 soorten gebruikers om rekening mee te houden:

• Groep A: Component bouwer: Jeffrey en Rozerin, de NLDS maintainers
• Groep B: Themabouwer: Rogier, Aline, etc.
• Groep C: Gebruikers van de Figma bibliotheek die designs bouwen met de componenten

Opties

1. Optie 1: Viewport specifieke tokens per component
2. Optie 2: Aparte tokensets
3. Extra: onderzoeken hoe Figma variables kan helpen
   a. Voor optie 1: Switch voor component variants voor gebruikersgroep C
   b. Voor optie 2: Collection toevoegen voor de verschillende viewports
   c. Kunnen we iets met TS die alleen de common-tokens of spacing als figma variables exporteert? (Is wel ts pro..)

Uitwerking

Ik zal voor elke optie een bibliotheek (gebruikersgroep A/B) en template uitwerken (werk gebruikersgroep C), om de voor- en nadelen goed in kaart te brengen. Het template bestaat uit de volgende componenten:

• Heading
• Paragraph
• Heading-group
• Action-group (+button)
• Section
• Grid
• Logo

Ik ben met optie 2 begonnen omdat optie 1 al grotendeels is uitgewerkt door Rogier.

In de json zullen ook andere componenten staan maar kijk met name naar de uitwerking van deze componenten.

---

Optie 1: Viewport specifieke tokens per component

Nadelen die nog niet benoemd zijn voor deze optie:

Nadeel

1. Gebruikersgroep A/B: als je je font-size aanpast op basis van de viewport heb je van elk Figma component 2 of meerdere variants nodig.
2. Gebruikersgroep C: moet voor elk component de juiste viewport selecteren.
3. Gebruikersgroep B (en C): Als je de font-size niet aanpast per viewpoort heb je onnodige variants (en tokens) in je bibliotheek.

---

Optie 2: Aparte tokensets

Voordeel

1. De bibliotheek heeft geen onnodige component variants voor thema's die geen responsieve font hebben.
2. Als je je tokens goed toepast kun je met 1 druk op de knop wisselen van design (gebruikers groep C), zie onderstaande gif.
3. Ligt dichtbij de code
4. Extra voordeel is dat je met dezelfde opbouw Figma variables kunt inzetten voor degene die dat willen (en daarmee ook meer toekomstbestendig als Figma Variables beter wordt ingericht). Met de opbouw van 'optie 1: viewport specifieke tokens per component' is dat lastig tot niet mogelijk.

Nadeel

1. Gebruikersgroep C heeft TS nodig
2. Gebruikersgroep C moet design tokens toepassen voor de lay-out, of via component templates kopiëren/plakken
3. De width, min-width, max-width kunnen niet overschreven worden bij een instance van een component. Als je je logo bijvoorbeeld 40px wilt op mobiel en 48px op desktop kan dat niet door een token toe te passen op de width van het component. Het component luistert naar de width die uit de bibliotheek komt. Alle andere properties/ tokens kun je wel overschrijven: font-size, line-height, padding, gap etc.
4. Je kunt niet van fill naar hug of andersom.

Punt 1 t/m 3 kan mogelijk opgelost worden met Figma variables. Zal later uitzoeken hoe en of dat zonder TS PRO en met max 4 Figma variables modes kan.

Files

• De Figma bibliotheek voor gebruikersgroep A/B
• De Figma file voor gebruikersgroep C
• De token.json opzet vind je op mijn GitHub.

mov

screen-recording-with-aparte-tokensets.mov

[jeffreylauwers]

Brainfart:

Ik krijg steeds meer het gevoel dat het vergroten van tekst zou kunnen plaats vinden in de Brand of Common tokens doormiddel van de clamp functie (zoals bij Amsterdam). En dat vanuit de Component tokens simpelweg naar deze token kan worden verwezen.

Responsive gedrag in spacing zie ik dan juist wel weer op Component niveau. En daarbij voorzie ik, in tegenstelling tot fontsizes, juist weer px waardes na het lezen van dit artikel: https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/

[jeffreylauwers]

Fluid Design with Tokens - Youtube
Video waarin Marco Krenn van Token Studio uitlegt hoe je fluid design tokens kan inzetten met Token Studio.

Eerder noteerde ik deze video bij 'Handige linkjes'. Maar dit lijkt, volgens de maker, behoorlijk van de performance te vragen.