Typografi i designsystemer

Vælg skrifttyper, indstil et hierarki og integrer med komponenter

Hverdagens digitale grænseflader inkluderer et stort udvalg af billeder, visualiseringer og andre billeder. Men mere end noget andet er de lavet af ord. Åh så mange ord. Når vi udstyrer hold til at designe og kode brugbare, konsistente, smukke grænseflader ved hjælp af systemer, er det vigtigt, at ord afhænger af et stærkt fundament i typografi.

Jeg må indrømme, jeg er ikke en typografekspert. Jeg mangler en grafisk design. Jeg er aldrig den person, der vælger en skrifttype, skaleringstype eller finesserende bogstavafstand. Som et resultat har jeg altid været tilbageholdende med at skrive om typografi.

På den anden side er jeg mønsterjæger. I årenes løb har jeg bidraget til mange designsystemer, der danner grundlaget for typografi. Hver gennemskridt af trin og beslutninger om at sætte et fundament og anvende det på et nye bibliotek med interfacekomponenter. Denne artikel opsummerer disse mønstre.

Typografi starter med at sætte et fundament for fontfamilier og -vægte sammen med tilbageslag. Derefter undersøges, hvordan man bygger hierarki ved hjælp af størrelse, farve, yderligere detaljer som linjehøjde og lagdelingens reaktionsevne. Disse modeller anvendes derefter til komponenter i et systems bibliotek (som artikel og overskrift) samt tilpassede komponenter, der er lavet af andre teams.

Skrifttyper

Inden du går i detaljer, skal du nøjes med det grundlæggende: font (er). Gennem udforskning, sammenligning, forskning og ofte - for store virksomheder - selv laver en skrifttype, kaskader hver skærm fra og afhænger af dette valg.

Familier, vægte og tilbageslag

Selvom systemer kan variere skrifttyper baseret på tema, grundlægges de fleste oprindeligt ved at identificere primær serif og / eller sans-serif fontfamilie. Hver skrifttype er forstærket med en kaskade af tilbagefald (Hello, Arial og Times), og mange systemer kaster en monospace-font til kodevisninger (selvom kun deres egne).

Skriv prøver på tværs af tre vægter af Barlow-skrifttypen

Nogle systemer kan slippe af med så få som to eller tre vægte af deres primære skrifttype og søge at afbalancere variation og fleksibilitet med styring og downloadvægt.

Afhentning: At komme til en primær skrifttype er ikke altid svært, men at vælge hvilke vægte der skal medtages har langsigtede konsekvenser. Det er let at tilføje skrifttyper og vægte. Det er svært at styre downloadstørrelse og ændre dem.

Henter skrifttyperne, hvad enten det er via download, link eller CDN

Uanset om et designsystemprogram ejer skrifttyperne eller ej, forventer brugere af et designsystem, at et system leverer de nødvendige instruktioner for at bruge skrifttyperne.

Fra en designerperspektiv handler det om downloads. Nogle skrifttyper er tæt indeholdt intellektuel ejendom med meget bevidst begrænset deling. Så mindst skal en typografiside give direkte download eller instruktioner om, hvordan man får godkendelse for at få dem. De fleste hold har en downloadbar ZIP, der indeholder alle de filer, du har brug for for at installere og bruge skrifttyper lokalt.

For udviklere afhænger det af tilgang, der giver muligheder som:

  • Download direkte skrifttype for at betjene skrifterne selv
  • Instruktioner til link til en tjeneste som Google Fonts
  • CDN-referencer, som alle produkter refererer til samlet
  • En invitation til at kontakte en teknisk arkitekt, da der kræves en licens til skrifttypen. Organisationer kræver dette for at kontrollere de tilbagevendende og ofte ikke-trivielle omkostninger ved hosting og servering af skrifttypen.

Takeaway: Skrifter er nødvendige for forskellige mennesker på forskellige måder. Systembrugere forventer, at systemet skal forklare, hvordan de nemt kan bruge alt, selvom det ikke er systemteamets opgave at lave tilpassede skrifttyper eller selv servere skrifttyper.

Typografiskala og hierarki

De fleste designsystemer demonstrerer en typografiskala i dokumentation som en lodret stak. Det er ikke nok. Et typografisk system bør også etablere konstruktioner som kropstekst, overskrifter, farve, lydhørhed, farve og andre finkornede detaljer.

Kropstekst

Systemer udnytter en typeskala for at tilbyde kernetekststørrelser - ofte kaldet blot som tekst eller krop - der inkluderer små, mellemstore, store, og hvis du har brug for det, xs, xl, og så videre. De fleste systemer har brug for tre eller deromkring (altså min komfort med at bruge t-shirtstørrelser). Start med nogle få, og udvid om nødvendigt som komponentdesign - og sidesammensætninger i naturen.

Små, mellemstore og store tekststørrelser

Kropskopi kan også tilbyde et tydeligt "Lead" (alternativt "Lede") -afsnit for at åbne en side, f.eks. I en artikel (mere om det senere). Således kan en simpel S / M / L-skala også have brug for andre varianter. Dette er især relevant i systemer, der tilbyder flere størrelser, da en bly til større skærme med lavere densitet ville være større end en bly til mindre alternativer med høj densitet.

Kontraster et blyafsnit fra mellemstor eller stor tekst

Afhentning: Hold kropsstørrelser enkle og få, men sørg for specifikke varianter uden for skalaen. Da kropskopiering væver gennem de fleste komponenter, tilbyder disse indstillinger hver egenskaber - størrelse, vægt, linjehøjde,… - at indstille for at få hver enkelt lige.

Tekstfarve

Farve spiller også en nøglerolle i en grænseflades typografiske hierarki, ofte af etablerede typer som:

  • Primær, for de fleste grænsefladetekst, uanset om det er krop eller overskrift.
  • Sekundær, for formindsket kontrast (ofte den "grå tekst") for supplerende information.
  • Interaktivt, ikke kun for links, men også flade knapper, fanetiketter og mere
  • Deaktiveret, ofte resulterende er især lavere kontrastbehandlinger
  • Fejl, normalt rødt, for den højeste kontrast til omgivelserne

Når det kommer til navngivning af tekstfarver baseret på forsæt, finder jeg, at Hudl Uniform-navnene er de mest spændende: standard, kontrast, subtil og ikke-væsentlig. Sådanne navne afbalancerer afvejen for stærkere kontrol med større abstraktion (og dermed mindre selvindlysende genbrug).

Tekstfarve på tværs af baggrunde

Disse typer er typiske, der findes under tidlige komponentdesign som knap, input og link. Når biblioteket vokser, bliver de spildt over hele komponentkataloget via værktøjer som tokens og mixin. Det bliver især nødvendigt, da komponentdesign spænder i lyse og mørke indstillinger.

For eksempel bruger vi i eightshapes.com-biblioteket (langt mindre nøje vedligeholdt, skomagerens børn og alle) en tekstfarvemixin, som itererer gennem baggrundsfarver, efter type.

Takeaway: Typografisk hierarki er ikke begrænset til størrelse og vægt; farve har også betydelig indflydelse. Designsystemer kræver ensartet farveanvendelse for at skabe kontrast inden for og på tværs af komponenter, og det er vigtigt at stole på velmodellerede typer for at styre sådanne forhold.

Overskriftniveau og særlige sager

Overskrifter er en kritisk bidragyder til sidehierarkiet. De fleste systemer tilbyder mindst fire, selvom nogle tilbyder mange flere. Sidetitler er normalt (men ikke altid) på linje med det største overskriftsniveau. Resterende niveauer er vævet på tværs af komponenter: en korttitel her, en alarmbeskedtitel der og Modal to niveaustitler.

Derudover tilbyder nogle systemer specialiserede overskrifter uden for den typiske overskudsskala, såsom et billedtekst eller et øjenbryn (se Morningstar Design System). Bare fordi en header findes uden for den traditionelle skala, betyder det ikke, at det ikke er et header, der rent faktisk kan genbruges i et katalog.

Øjenbrynens overskrift

Systemer kan også tilbyde mere sofistikerede kombinationer af overskrifter og brødtekst. For eksempel begrunder IBM Carbon typografi i IBM Plex-skrifttypen og adskiller overskrifter, der er relevante for enten webbaseret produkt (produktiv) og digital marketing (ekspressiv) -grænseflader.

Afhentning: Løs for lige nok overskrifttyper, og lag mere komplicerede headerkontroller kun efter behov og konteksten er klar. Normalt gør fire til seks overskrift niveau og et drys specielle varianter.

Overskrift Niveauer ≠ H # tags

I HTML tildeler overskrifttags semantisk betydning til et elements rolle i en sides hierarki. En komponents tags er imidlertid ikke eller kan ikke justeres med hver enkelt sides HTML, som den bruges på, især på tværs af sider eller en hel app. Derudover kan det, der måske er den største overskrift på en skærm (f.eks. En produktspecifik sidetitel), være den tredje største overskrift på en anden side (f.eks. Et produkts startside).

Overskriftniveauer er forskellige, men bruger dog samme HTML-tag

Som et resultat opfordrer jeg kraftigt hold til at adskille begrebet overskriftsniveau (det visuelle resultat af anvendelse af stilegenskaber) fra H-tag (HTML-elementer som H1, H2, H3 osv.).

Afhentning: Anvendelse af overskudsskalaer kræver ikke brug af et specifikt HTML-element. I stedet for at drille de to bekymringer fra hinanden. Et system skal væve kursniveauer konsekvent gennem komponenter og tilbyde værktøjer til, at adoptører kan gøre det samme med deres brugerdefinerede oprettelser.

Liniehøjde og andre egenskaber

Typografi er påvirket af mange andre egenskaber, herunder:

  • linjehøjde
  • justering (sjældent kontrolleret på systemniveau, normalt standard til venstre)
  • Spatiering
  • tekst-transformation (f.eks. store bogstaver)

Især er linehøjde udfordrende. I nogle biblioteker bruger vi konventioner og værktøjer til at beskære negativt rum, der er fastlagt efter linjehøjde fra al tekst, der er inkluderet i komponenter, som beskrevet i Rum i designsystemer.

Beskåret liniehøjde kontra tekstelementer, der inkluderer påvirkninger af liniehøjde

Biblioteker, der beskærer linjens højde, inkluderer Morningstar Design System, Discovery Education's Comet Design System og ~ 50% af andre, vi har lavet siden 2016. I alle de andre biblioteker har vi "lade linjehøjden gøre sine ting", der forudsigeligt kolliderer med polstring af indeholdende elementer.

Afhentning: Når et system kommer i gang med type, skal du grave i detaljer og starte nogle konventioner, for eksempel hvordan du takler linjehøjde. Undgå dog at færdiggøre alle regler, før du foretager den første ting. Vær i stedet for komfortabel med kaos tidlige og glatte detaljer, når et bibliotek tager form. Når du er i nærheden af ​​en større frigivelse, skal du låse konventioner og sikre, at værktøjer anvendes konsekvent.

Responsiv typografi

Systemer kan tilbyde centralt afstemte responsive typestørrelser på tværs af et forudsigeligt sæt af breakpoints. For tekst på tekst øges størrelsen langsomt. På den anden side kan større overskrifter stige dramatisk på tværs af de samme brudpunkter.

Hvis lydhørhed er inkluderet, skal et system vælge, om det er "altid tændt" eller valgfrit. Hvis det er valgfrit, er reaktionsevne tændt eller slukket som standard? Hvis det er slået fra som standard, kan reaktionsevnen muligvis aktiveres via et API for værktøjer som mixin som sys-overskrift-niveau-2:

@mixin sys-overskrift-niveau-2 ($ responsiv: falsk);

og CSS-modifikatorklasse som sys-header - lydhør:

  

  Overskrift      
...

Systemer kan frigive komponenter, der mangler lydhør typografi. Det er ok. Må ikke føle dig for dårlig. Faktisk mangler nogle systemer centraliserede responsive type-kontroller i måneder eller derover i et år. Dette risikerer dog en omkostning ned ad vejen. Så tidligt teknisk design kan være berettiget, så kodeværktøjer og testplaner forudser reaktionsevne i sidste ende.

Afhentning: Mens en MVP muligvis ikke løser det, er responsiv typografi et kendetegn ved et modent, stabilt system. Opret en skala pr. Breakpoint og gør det muligt at tilkaldes ved forskellige hierarkisammensætningsniveauer: efter element, efter komponent, efter en sides område og for en samlet side.

Forholdet typografi til komponenter

Hvis du er fristet til at nulstille sider, skal du kontrollere, hvad du kan kontrollere

I sjældnere økosystemer er et system centralt og autoritativt. Den definerer, hvordan al frontend-udvikling fungerer, og hvordan alle sider er konstrueret. I de fleste virksomheder, inklusive dem, jeg betjener, mangler et system den luksus. Et produkt kan integrere kode for mange produktgrupper afhængigt af forskellige systemversioner eller system helt.

I disse scenarier kan et system ikke stole på nulstillinger på sideniveau. I stedet nulstilles elementer ved en grænse, der kontrolleres, såsom en komponentblokmixin ...

.system-knap {
  @ inkluderer component-font-reset ();
  ...

... for at nulstille mindst en række typeegenskaber, såsom:

Takeaway: Der er hubris ved at tro, at et system kontrollerer alt på en side, overbevist om, at det ikke vil kollidere med noget andet stilarter. Så styrk det, du sender i den kontekst, du kontrollerer, herunder nulstilling af elementer til typografi.

Værktøjer til adopterere til at fremstille komponenter selv

Et system tilbyder aldrig "alle de komponenter, du nogensinde har brug for." Adoptører bygger hvor som helst fra 30% til 70% af deres resterende interface. Derfor er de afhængige af systemværktøjer til at style tekst i det, de bygger, såsom Sass-mixins.

For eksempel kan en adopter ønske at anvende en overskrift på titelelement ...

.my-brugerdefinerede-komponent-titel {
    @ inkluder system-niveau-3-overskrift ();
}

... for at få CSS-kompatibel CSS som:

.my-brugerdefinerede-komponent-titel {
  skriftstørrelse: 24px;
  font-familie: "Barlow", ...;
  font-stil: normal;
  font-vægt: "Semibold";
  linjehøjde: 1,2;
}

Selvom kodeværktøjer ikke bør overvælde smukke typografidokumenter, er denne side en rimelig placering, som mange udviklere burde finde nyttige, kraftfulde værktøjer.

Afhentning: Begræns ikke adgangen til typografi ved kun at bruge forudbyggede komponenter. Giv i stedet brugerne mulighed for at gøre deres komponenter på linje med systemets typografi. Værktøjer på lavere niveau hjælper og fører til rene bidrag også senere.

UI-typografi ≠ Artikler (tidligere mangler afstand)

En misforståelse jeg debunk tidligt og ofte: at udvikle et typografisystem til UI-komponenter svarer til at løse til langvarig læsningsskærme, der hovedsageligt involverer overskrifter og kropstekst.

Dette er ikke tilfældet, da:

  • Artikeltypografi er lavet af overskrifter, kropstekst og et par andre komponenter (som et billedtekst); UI-typografi adresserer en meget forskelligartet række komponenter og elementer inden i.
  • Artikeltypografitæthed er mere løs .; UI-typografitæthed varierer.
  • Overskrifter for artikeltypografi begynder ved 2 og stiger op ad gangen; UI-typografi bruger uregelmæssige kombinationer af overskriftsniveauer som 3, 4 og 5.
  • Artikler kommandoerer en hoved, ofte bred kolonne nederst på siden; UI-typografi optager mellemrum smalle og brede overalt på en side.
  • Artikeltypografi inkluderer et lille sæt forudsigelige kombinationer; UI-typografi adresserer en uberegnelig mængdekomponentkombination.
  • UI-typografi findes i layouts med mange søjler, på tværs af hvilken tekst umuligt kan justeres konsekvent på et delt baseline-gitter. Helt ærligt prøver jeg ikke engang. Alligevel dominerer baseline-gitre diskussionen om artikeltypografi.

Afhentning: Typografikontekster omkring en brugergrænseflade varierer meget, og et artikelformat er kun et blandt mange. Adskil regler, der finder anvendelse på et UI-komponentbibliotek, fra dem, der er relevante for snævrere sammenhænge som en artikel.

Header-komponenten

Stykker på overskriftniveau anvendes bredt i et komponentbibliotek. Men det betyder ikke, at sidesammensætninger ikke kunne oprette deres eget hierarki ved at inkludere en Header-komponent, der tilbyder et par klokker og en fløjte.

Headerkomponenten fra Morningstar Design System

For eksempel størkner Morningstars Header-komponent arrangementet af mange ofte-relaterede elementer, inklusive egenskaber til:

  • Et ikon (med indbygget værktøjstip?) Ved siden af ​​overskriftets etiket
  • Handlinger, hvad enten det er som knapper eller ikonknapper
  • Kantindstillinger for at skabe kontrast mellem sideregioner

Afhentning: Overskriftstypografi er kun en del af en potentiel overskriftskomponent, der relaterer denne type til tilstødende signaler, interaktioner og yderligere type. Pak disse regler og forhold i en overskriftskomponent efter behov, adskilt fra generiske værktøjer til overskriftstilgang.

Artikelkomponenten, inklusive linjelængde og elementparinger

En komponent (eller tekst i lang form) indeholder regler, der adskiller overskriftsniveauer, kropstekster, lister (uordnet og ordnet) og andre "basale" elementer, såsom et billede med en billedtekst. Det kan også tilbyde en forfatterbyline og et par andre elementtyper. I det væsentlige er intervallet af elementer, du gennemgår i en Medium-artikel som denne eller et systems komponentdokumentationsside.

Artikelkomponentens grundlæggende elementer, inklusive indlejret afstand

Jeg kan godt lide at sidestille en artikelkomponent til "Alle de stilarter, du har brug for for at formatere korrekt typisk indhold, der er indtastet i en CMS's rich text editor." Morningstar Design System inkluderer også en robust featured artikelkomponent.

Man skal være meget på vagt over for parrede forhold uden for kontekst kontrolleret af en komponent. Imidlertid tilbyder en artikelskontekst et lukket sæt forudsigelige elementkombinationer: h2 derefter h3, h3 derefter p eller h2 derefter p, og så videre. Hver af disse kombinationer kan perfektioneres baseret på afstandsmodel (f.eks. "Brugt margin-bund" eller "brug margin-top").

Takeaway: Vær meget omhyggelig med at forfining af dine brugers lange formlæsning. Udfordringen inkluderer ikke kun hierarki, men også linjelængde, mellemrum mellem linjer, forhold til andre artikelelementer - dæk, forfatter byline, billeder og mere - inden for den bredere, vidt genanvendelige blok.

Typografiens dybder kræver flere dage, måneder og år med læring, end denne artikel indeholder. Ikke desto mindre kan væbnede med et stærkt fundament, designsystemer og de hold, de understøtter, producere så meget hurtigere, bedre og konsistente oplevelser end før. Må disse værktøjer være en nyttig start.