Typografie in ontwerpsystemen

Kies lettertypen, stel een hiërarchie in en integreer met componenten

Dagelijkse digitale interfaces omvatten een rijke verscheidenheid aan afbeeldingen, visualisaties en andere afbeeldingen. Maar boven alles zijn ze gemaakt van woorden. Oh zoveel woorden. Omdat we teams uitrusten met het ontwerpen en coderen van bruikbare, consistente, mooie interfaces met behulp van systemen, is het essentieel dat woorden afhankelijk zijn van een sterke basis van typografie.

Ik geef toe dat ik geen typografie-expert ben. Ik mis een grafische graad. Ik ben nooit de persoon die een lettertype, schaaltype of lastige letterafstand kiest. Daarom ben ik altijd terughoudend geweest om over typografie te schrijven.

Aan de andere kant ben ik een patroonjager. In de loop der jaren heb ik bijgedragen aan vele ontwerpsystemen die een basis leggen voor typografie. Elke stap doorkruiste stappen en beslissingen om een ​​basis te leggen en toe te passen op een nieuwe bibliotheek van interface-componenten. Dit artikel vat die patronen samen.

Typografie begint met het leggen van een basis van lettertypefamilies en -gewichten samen met fallbacks. Vervolgens wordt onderzocht hoe hiërarchie kan worden opgebouwd met behulp van grootte, kleur, extra details zoals lijnhoogte en reactievermogen van lagen. Die modellen worden vervolgens toegepast op componenten in de bibliotheek van een systeem (zoals artikel en koptekst) en op aangepaste componenten die door andere teams zijn gemaakt.

fonts

Voordat u zich in details verdiept, moet u zich bezighouden met de basis: lettertype (s). Door exploratie, vergelijking, onderzoek en vaak - voor grote bedrijven - zelf een lettertype te maken, valt elke weergave uit en hangt af van deze keuze.

Families, gewichten en fallbacks

Hoewel systemen op basis van thema's kunnen variëren met lettertypen, aarden de meeste zichzelf aanvankelijk door primaire serif- en / of sans-serif-lettertypefamilies te identificeren. Elk lettertype wordt aangevuld met een waterval van fallbacks (Hallo, Arial en Times), en veel systemen voegen een monospace-lettertype toe voor codeweergaven (zelfs al is het hun eigen).

Typ specimens over drie gewichten van het Barlow-lettertype

Sommige systemen kunnen wegkomen met zo weinig als twee of drie gewichten van hun primaire lettertype, op zoek naar een evenwicht tussen variëteit en flexibiliteit met governance en downloadgewicht.

Afhalen: het is niet altijd moeilijk om naar een primair lettertype te gaan, maar het kiezen van de gewichten die u wilt opnemen, heeft gevolgen op de lange termijn. Lettertypen en gewichten toevoegen is eenvoudig. Het is moeilijk om de downloadgrootte te beheren en te wijzigen.

De lettertypen verkrijgen, hetzij door downloaden, koppelen of CDN

Of een ontwerpsysteemprogramma de lettertypen al dan niet bezit, gebruikers van een ontwerpsysteem verwachten dat een systeem de instructies levert die nodig zijn om de lettertypen te gebruiken.

Vanuit het perspectief van een ontwerper draait het allemaal om downloads. Sommige lettertypen zijn stevig intellectueel eigendom met zeer opzettelijk beperkte delen. Dus op zijn minst moet een typografiepagina directe download of instructies bevatten voor het verkrijgen van goedkeuring om ze te verkrijgen. De meeste teams bieden een downloadbare ZIP die alle bestanden bevat die u nodig hebt om lokaal lettertypen te installeren en te gebruiken.

Voor ontwikkelaars hangt het af van de aanpak en biedt opties zoals:

  • Direct downloaden van lettertypen om de lettertypen zelf te bedienen
  • Instructies voor het koppelen van een service zoals Google Fonts
  • CDN-verwijzingen waarnaar alle producten gezamenlijk verwijzen
  • Een uitnodiging om contact op te nemen met een technisch architect, aangezien een licentie voor het lettertype vereist is. Organisaties hebben dit nodig om de terugkerende en vaak niet-triviale kosten van het hosten en serveren van het lettertype te beheersen.

Afhaalmaaltijden: lettertypen zijn op verschillende manieren nodig door verschillende mensen. Systeemgebruikers verwachten dat het systeem uitlegt hoe alles gemakkelijk te gebruiken is, zelfs als het niet de taak van het systeemteam is om aangepaste lettertypen te maken of zelf lettertypen te bedienen.

Typografie schaal & hiërarchie

De meeste ontwerpsystemen tonen een typografische schaal in de documentatie aan als een verticale stapel. Dat is niet genoeg. Een typografisch systeem moet ook constructies zoals hoofdtekst, koppen, kleur, reactievermogen, kleur en andere fijne details vastleggen.

Lichaamstaal

Systemen maken gebruik van een typeschaal om kerntekstgroottes aan te bieden - vaak gewoon genoemd als tekst of hoofdtekst - die klein, gemiddeld, groot en, indien nodig, xs, xl, enzovoort omvatten. De meeste systemen hebben er ongeveer drie nodig (dus mijn comfort bij het gebruik van T-shirtmaten). Begin met een paar en breid zo nodig uit als componentontwerpen - en paginacomposities in het wild.

Kleine, middelgrote en grote tekstgroottes

Hoofdtekst kan ook een afzonderlijke paragraaf 'Lead' (of 'Lede') bieden om een ​​pagina te openen, zoals in een artikel (waarover later meer). Zo kan een eenvoudige S / M / L-schaal mogelijk ook andere varianten leiden. Dit is vooral relevant in systemen met meerdere formaten, omdat een kabel voor grotere displays met een lagere dichtheid groter zou zijn dan een kabel voor kleinere alternatieven met een hoge dichtheid.

Een hoofdalinea contrasteren met middelgrote of grote tekst

Afhaalmaaltijden: houd lichaamsgroottes eenvoudig en weinig, maar laat specifieke varianten buiten de schaal toe. Omdat body copy door de meeste componenten loopt, bieden deze opties elk eigenschappen - grootte, gewicht, lijnhoogte, ... - om af te stemmen om elk precies goed te krijgen.

Tekst kleur

Kleur speelt ook een belangrijke rol in de typografische hiërarchie van een interface, vaak door gevestigde typen zoals:

  • Primair, voor de meeste interfacetekst, zowel hoofd- als koptekst.
  • Secundair, voor verminderd contrast (vaak de "grijze tekst") voor aanvullende informatie.
  • Interactief, niet alleen voor koppelingen, maar ook platte knoppen, tablabels en meer
  • Uitgeschakeld, vaak resulterend, zijn vooral behandelingen met een lager contrast
  • Fout, meestal rood, voor het grootste contrast met zijn omgeving

Wat betreft het benoemen van tekstkleuren op basis van intentie, vind ik de Hudl Uniform-namen de meest intrigerende: standaard, contrast, subtiel en niet-essentieel. Dergelijke namen balanceren de afwegingen van sterkere controle met grotere abstractie (en dus minder vanzelfsprekend hergebruik).

Tekstkleur op achtergronden

Deze typen zijn typisch en worden aangetroffen tijdens vroege ontwerpen van componenten, zoals knop, invoer en koppeling. Naarmate een bibliotheek groeit, raken ze bezaaid in de hele componentencatalogus via tools zoals tokens en mixin. Ze worden met name nodig als componentontwerpen overspannen in lichte en donkere omgevingen.

In de eightshapes.com-bibliotheek (veel minder strikt onderhouden, kinderen van schoenmakers en zo), gebruiken we bijvoorbeeld een tekstkleurenmix die door achtergrondkleuren doorzoekt, per type.

Afhaalmaaltijden: typografische hiërarchie is niet beperkt tot grootte en gewicht; kleur heeft ook een aanzienlijke impact. Ontwerpsystemen vereisen een consistente kleurtoepassing om contrast te creëren binnen en tussen componenten, en vertrouwen op goed gemodelleerde types is essentieel voor het beheren van dergelijke relaties.

Richtingniveaus en speciale gevallen

Koppen leveren een cruciale bijdrage aan de paginahiërarchie. De meeste systemen bieden minstens vier, hoewel sommige veel meer bieden. Paginatitels komen meestal (maar niet altijd) overeen met het grootste kopniveau. De resterende niveaus zijn geweven doorheen de componenten: hier een kaarttitel, daar een waarschuwingsberichttitel en een modale titel op twee niveaus.

Bovendien bieden sommige systemen gespecialiseerde headers buiten de typische koersschaal, zoals het bijschrift van een afbeelding of een wenkbrauw (zie Morningstar Design System). Het feit dat er een koptekst buiten de traditionele schaal bestaat, betekent niet dat het geen koptekst is die herbruikbaar is in een catalogus.

Wenkbrauw kop

Systemen kunnen ook meer geavanceerde combinaties van koppen en hoofdtekst bieden. IBM grondeert bijvoorbeeld typografie in het IBM Plex-lettertype en onderscheidt koppen die relevant zijn voor zowel webgebaseerde product- (productieve) als digitale marketing (expressieve) interfaces.

Afhaalmaaltijden: los net voldoende koptypen op en leg meer gecompliceerde koptekstcontroles alleen als dat nodig is en de context is duidelijk. Meestal zijn vier tot zes koppen en een aantal speciale varianten voldoende.

Kopniveaus ≠ H # -tags

In HTML wijzen koptags semantische betekenis toe aan de rol van een element binnen de hiërarchie van een pagina. De tags van een component komen echter niet overeen met de HTML van elke pagina waarop deze wordt gebruikt, vooral op pagina's of een hele app. Wat mogelijk de grootste kop op het ene scherm is (zoals de paginatitel van een productspecificatie), kan bovendien de derde grootste kop zijn op een andere pagina (zoals de startpagina van een product).

Verschillende koersniveaus, maar met dezelfde HTML-tag

Daarom moedig ik teams sterk aan om het concept van kopniveau (het visuele resultaat van het toepassen van stijleigenschappen) te scheiden van de H-tag (HTML-elementen zoals H1, H2, H3, enzovoort).

Afhaalmaaltijden: voor het toepassen van kopschalen hoeft geen specifiek HTML-element te worden gebruikt. Plak in plaats daarvan de twee zorgen uit elkaar. Een systeem moet de koersniveaus consistent door alle componenten weven en biedt hulpmiddelen voor gebruikers om hetzelfde te doen met hun aangepaste creaties.

Lijnhoogte en andere eigenschappen

Typografie wordt beïnvloed door vele andere eigenschappen, waaronder:

  • lijnhoogte
  • uitlijning (zelden geregeld op systeemniveau, meestal standaard naar links)
  • letterafstand
  • tekst-transformatie (zoals hoofdletters)

Vooral lijnhoogte is een uitdaging. In sommige bibliotheken gebruiken we conventies en hulpmiddelen om negatieve ruimte, bepaald door de regelhoogte, weg te snijden van alle tekst in componenten, zoals beschreven in Space in Design Systems.

Bijgesneden lijnhoogte versus tekstelementen die effecten van lijnhoogte bevatten

Bibliotheken snijlijnhoogte omvatten Morningstar Design System, Comet Design System van Discovery Education en ~ 50% van anderen die we sinds 2016 hebben gemaakt. In alle andere bibliotheken hebben we "lijnhoogte zijn ding laten doen", voorspelbaar botsen met opvulling van bevattende elementen.

Afhaalmaaltijden: als een systeem aan de slag gaat met type, ga je in op details en begin je een aantal conventies, zoals hoe je omgaat met lijnhoogte. Vermijd echter de laatste hand aan alle regels voordat u het eerste maakt. Wees in plaats daarvan vertrouwd met vroege chaos en vloeiende details terwijl een bibliotheek vorm krijgt. Wanneer u een grote release nadert, sluit u conventies aan en zorgt u ervoor dat tools consistent worden toegepast.

Responsieve typografie

Systemen kunnen centraal afgestemde responsieve typen bieden voor een voorspelbaar aantal breekpunten. Voor hoofdtekst neemt de grootte langzaam toe. Aan de andere kant kunnen grotere koppen dramatisch toenemen over dezelfde breekpunten.

Als responsiviteit is inbegrepen, moet een systeem kiezen of het "altijd aan" of optioneel is. Als het optioneel is, is responsiviteit dan standaard ingeschakeld of uitgeschakeld? Als deze standaard is uitgeschakeld, kan responsiviteit worden ingeschakeld via een API voor tools zoals mixin zoals sys-header-level-2:

@mixin sys-header-level-2 ($ responsive: false);

en CSS-modificatieklasse zoals sys-header - responsief:

  

  Heading      
...

Systemen kunnen componenten vrijgeven zonder responsieve typografie. Het is ok. Voel je niet slecht. Sommige systemen hebben zelfs maanden of langer dan een jaar geen gecentraliseerde responsieve typecontroles. Dit riskeert echter kosten op de weg. Dus vroeg technisch ontwerp kan gerechtvaardigd zijn, zodat codetools en testplannen uiteindelijk op responsiviteit anticiperen.

Takeaway: hoewel een MVP er misschien niet voor oplost, is responsieve typografie een kenmerk van een volwassen, stabiel systeem. Stel een schaal per breekpunt in en maak invocabel op verschillende niveaus van de hiërarchiesamenstelling: per element, per component, per regio van een pagina en voor een algemene pagina.

Typografie relateren aan componenten

Als u in de verleiding komt pagina's opnieuw in te stellen, bepaalt u wat u kunt regelen

In zeldzamere ecosystemen staat een systeem centraal en gezaghebbend. Het definieert hoe alle front-end ontwikkeling werkt en hoe alle pagina's zijn opgebouwd. In de meeste ondernemingen, inclusief die waar ik werk, mist een systeem die luxe. Eén product kan de code van veel productteams integreren, afhankelijk van verschillende systeemversies of het systeem helemaal.

In die scenario's kan een systeem niet vertrouwen op resets op paginaniveau. In plaats daarvan worden elementen gereset op een grens die wordt geregeld, zoals een mix van componentenblokken ...

.system-button {
  @include component-font-reset ();
  ...

... om ten minste een reeks type-eigenschappen te resetten, zoals:

Afhaalmaaltijden: het doet er alles aan om te geloven dat een systeem alles op een pagina bestuurt, ervan overtuigd dat het niet in botsing komt met andere stijlen. Dus versterk wat u verzendt in de context die u beheert, inclusief het resetten van elementen voor typografie.

Hulpmiddelen voor adoptanten om zelf componenten te maken

Een systeem biedt nooit 'alle componenten die u ooit nodig zult hebben'. Adoptanten bouwen overal van 30% tot 70% van hun resterende interface. Daarom zijn ze afhankelijk van systeemtools om tekst op te maken in wat ze bouwen, zoals Sass-mixins.

Een adoptant zou bijvoorbeeld een kop op titelelement willen kunnen toepassen ...

.my-custom-component-title {
    @inclusief systeemniveau-3-kop ();
}

... om systeem-compatibele CSS te verkrijgen zoals:

.my-custom-component-title {
  lettergrootte: 24 px;
  font-family: "Barlow", ...;
  lettertype: normaal;
  font-weight: "Semibold";
  lijnhoogte: 1,2;
}

Hoewel codetools de prachtige typografie niet mogen overweldigen, is die pagina een redelijke locatie die veel ontwikkelaars handige, krachtige tools moeten vinden.

Afhaalmaaltijden: beperk de toegang tot typografie niet met alleen vooraf gebouwde componenten. Geef gebruikers in plaats daarvan de mogelijkheid om hun componenten uit te lijnen met de typografie van het systeem. Hulpmiddelen op een lager niveau helpen en leiden later ook tot schone bijdragen.

UI Typography ≠ Articles (eerstgenoemde mist spatie)

Een misvatting die ik vroeg en vaak heb ontkracht: het ontwikkelen van een typografiesysteem voor UI-componenten is hetzelfde als het oplossen van lange leesdisplays met voornamelijk koppen en hoofdtekst.

Dit is niet het geval, omdat:

  • Artikeltypografie bestaat uit koppen, hoofdtekst en enkele andere componenten (zoals een afbeelding met bijschriften); UI-typografie richt zich op een zeer divers scala aan componenten en elementen daarin.
  • De dichtheid van artikeltypografie neigt losser .; UI typografie dichtheid varieert.
  • De koppen van de artikeltypografie beginnen bij 2 en stijgen één voor één; UI-typografie maakt gebruik van onregelmatige combinaties van kopniveaus zoals 3, 4 en 5.
  • Artikelen hebben een hoofd, vaak brede kolom midden op een pagina; UI typografie beslaat spaties smal en breed over een hele pagina.
  • De typografie van artikelen omvat een kleine reeks voorspelbare combinaties; UI typografie adresseert een onberekenbare hoeveelheid componentcombinaties.
  • UI-typografie bevindt zich in lay-outs met veel kolommen waarover tekst onmogelijk consistent kan worden uitgelijnd op een gedeeld basislijnraster. Eerlijk gezegd probeer ik het niet eens. Toch domineren basislijnrasters de discussie over artikeltypografie.

Afhaalmaaltijden: typografiecontexten rond een gebruikersinterface variëren aanzienlijk, en een artikelindeling is slechts een van de vele. Afzonderlijke regels die van toepassing zijn op een UI-componentenbibliotheek en die welke relevant zijn voor smallere contexten zoals een artikel.

De koptekstcomponent

Stijlen op kopniveau worden breed toegepast in een componentenbibliotheek. Maar dat betekent niet dat paginacomposities geen eigen hiërarchie konden maken door een koptekstcomponent op te nemen die een paar toeters en bellen biedt.

De headercomponent van Morningstar Design System

Bijvoorbeeld, de component Header van Morningstar versterkt de indeling van veel vaak gerelateerde elementen, waaronder eigenschappen voor:

  • Een pictogram (met ingebouwde knopinfo?) Naast het koplabel
  • Acties, als knoppen of als pictogramknoppen
  • Randopties om contrast tussen paginagebieden te creëren

Afhaalmaaltijden: Koerstypografie is slechts een onderdeel van een potentiële koerscomponent, die dat type relateert aan aangrenzende signalen, interacties en extra type. Verpak indien nodig die regels en relaties in een rubriekonderdeel, los van generieke hulpmiddelen voor de kopstijl.

De artikelcomponent, inclusief lijnlengte en elementparen

Een component Artikel (of lange formuliertekst) bevat regels voor het scheiden van kopniveaus, hoofdteksten, lijsten (ongeordend en geordend) en andere 'basis'-elementen zoals een afbeelding met een bijschrift. Het kan ook een naamregel van de auteur en een paar andere elementtypen bieden. In wezen het bereik van elementen dat u doorkruist in een Medium-artikel zoals dit of de documentatiepagina van een systeemcomponent.

Basiselementen van artikelcomponenten, inclusief ingesloten afstand

Ik vergelijk een artikelonderdeel graag met "Alle stijlen die u nodig hebt om typische inhoud die is ingevoerd in de rich text-editor van een CMS correct op te maken." Het Morningstar-ontwerpsysteem bevat ook een robuust artikelonderdeel.

Men moet heel voorzichtig zijn met gepaarde relaties buiten de context die door een component wordt bestuurd. Een artikelcontext biedt echter een gesloten set voorspelbare elementcombinaties: h2 vervolgens h3, h3 vervolgens p, of h2 vervolgens p, enzovoort. Elk van deze combinaties kan worden geperfectioneerd op basis van het afstandsmodel (zoals "gebruikte marge-onder" of "gebruik marge-boven").

Afhaalmaaltijden: besteed veel aandacht aan het verfijnen van de lange leeservaring van uw gebruikers. De uitdaging omvat niet alleen hiërarchie, maar ook lijnlengte, ruimte tussen lijnen, relaties met andere artikelelementen - deck, auteur-byline, afbeeldingen en meer - binnen dat bredere, breed herbruikbare blok.

De diepten van typografie vereisen meer dagen, maanden en jaren van leren dan dit artikel biedt. Niettemin, gewapend met een sterke basis, kunnen ontwerpsystemen en de teams die ze ondersteunen zoveel snellere, betere en consistente ervaringen produceren dan voorheen. Mogen deze hulpmiddelen een nuttig begin zijn.