Fra UI-kit til designsystem

Ivy online biografoplevelse

Da vi i begyndelsen af ​​2017 først tænkte på at skabe vores eget design-til-kode leveringssystem, talte mange allerede om det, og nogle gjorde det endda. Men indtil i dag er lidt kendt om erfaringerne med at bygge designsystemer på tværs af platforme, og der har ikke været nogen klare og gennemprøvede opskrifter, der beskriver teknologier og metoder til en sådan transformation af processen med designimplementering til et allerede fungerende produkt. Og med "komponenter i koden" mener de ofte meget forskellige ting.

I mellemtiden fordoblede virksomheden sit personale år efter år - det var nødvendigt at skalere designafdelingen og optimere processerne med at skabe og overføre layouts til udvikling. Vi multiplicerer alt dette med "zoo" af platforme, der skal understøttes, og vi får et udseende af babylonsk pandemonium, som simpelthen ikke er i stand til at "gøre det normalt" og generere indkomst. Udviklingen af ​​platforme forløb ofte parallelt, og den samme funktionalitet kunne frigives på forskellige platforme med en forsinkelse på flere måneder.


Separate layoutsæt for hver platform

Traditionelt startede vi med problemer, som et designsystem ville hjælpe med at løse og formulerede krav til dets design. Ud over at skabe et samlet visuelt sprog, øge hastigheden af ​​layout og udvikling og forbedre kvaliteten af ​​produktet generelt, var det afgørende at forene designet så meget som muligt. Dette er nødvendigt, så udviklingen af ​​funktionalitet bliver mulig på alle vores platforme samtidigt: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - uden at arbejde på hver af dem separat. Og vi gjorde det!

Design → data

Da de grundlæggende aftaler mellem produkt- og udviklingsafdelingerne var indgået, satte vi os for at vælge en teknologistack og udarbejde detaljerne i hele processen - fra layout til release. For fuldt ud at automatisere processen med at overføre designet til udvikling, undersøgte vi muligheden for at parse komponentparametre direkte fra Sketch-filer med layout. Det viste sig, at det var en kompleks og farlig opgave at finde de stykker kode, vi havde brug for, og udtrække de parametre, vi havde brug for. For det første skal designere være ekstremt omhyggelige med at navngive alle lag af kildekoden, for det andet virker dette kun for de enkleste komponenter, og for det tredje bringer afhængighed af en andens teknologi og kodestruktur i det originale Sketch-layout fremtiden for hele projekt. Vi besluttede at opgive automatisering på dette område. Sådan optrådte den første person i designsystemteamet, hvis input er designlayouts, og outputtet er data, der beskriver alle komponenternes parametre og er hierarkisk ordnet efter den atomare designmetodologi.

Det eneste, der var tilbage at gøre, var hvor og hvordan man opbevarer dataene, hvordan man overfører dem til udvikling og hvordan man fortolker dem i udvikling på alle de platforme, vi understøtter. Aftenen holdt op med at være sløv... Resultatet af regelmæssige møder i arbejdsgruppen bestående af designere og teamledere fra hver platform var enigheden om følgende.

Vi parser manuelt det visuelle i atomare elementer: skrifttyper, farver, gennemsigtighed, indrykning, afrundinger, ikoner, billeder og varigheder for animationer. Og vi indsamler fra dette knapper, input, afkrydsningsfelter, bankkort-widgets osv. Vi tildeler ikke-semantiske navne til stilene på et hvilket som helst af niveauerne, undtagen ikoner, for eksempel navne på byer, navne på nymfer, Pokemon, bil mærker... Der er kun én betingelse - listen skal ikke udtømmes før, hvordan styles ender - show must go! Du skal ikke lade dig rive med af semantik, så du ikke behøver at tilføje en midterknap mellem for eksempel "small" og "medium".

Visuelt sprog

Udviklere blev overladt til at tænke over, hvordan de skulle gemme og overføre data på en måde, der passede til alle platforme, og design skulle designe grænsefladeelementer, der kunne se godt ud og fungere effektivt på tværs af hele flåden af ​​understøttede enheder.

Tidligere havde vi allerede formået at "teste" de fleste af designelementerne i en applikation til Windows 10, som på det tidspunkt var en ny platform for os, det vil sige, det krævede gengivelse og udvikling "fra bunden". Ved at tegne det var vi i stand til at forberede og teste de fleste af komponenterne og forstå, hvilke af dem der skulle indgå i det fremtidige Eevee designsystem. Uden sådan en sandkasse kunne en sådan erfaring kun opnås gennem et stort antal iterationer på allerede fungerende platforme, og det ville tage mere end et år.

Genbrug af de samme komponenter på forskellige platforme reducerer antallet af layouts og rækken af ​​data i designsystemet betydeligt, så designet skulle løse endnu et problem, som tidligere ikke er beskrevet i praksis for produktdesign og udvikling - hvordan f.eks. kan en knap til telefoner og tablets genbruges på tv? Og hvad skal vi gøre med størrelserne af skrifttyper og elementer på så forskellige platforme?

Det var klart, at det var nødvendigt at designe et modulært gitter på tværs af platforme, der ville indstille de tekst- og elementstørrelser, vi havde brug for til hver specifik platform. Som udgangspunkt for gitteret valgte vi størrelsen og antallet af filmplakater, som vi ønsker at se på en bestemt skærm, og ud fra dette formulerede vi en regel for konstruktion af gitterkolonner, forudsat at bredden af ​​en kolonne er ens. til plakatens bredde.

Nu skal vi bringe alle store skærme til den samme layoutstørrelse og passe dem ind i et fælles gitter. Apple TV og Roku er designet i størrelsen 1920x1080, Android TV - 960x540, Smart TV'er, afhængigt af leverandøren, er de samme, men nogle gange 1280x720. Når appen gengives og vises på Full HD-skærme, ganges 960 med 2, 1280 ganges med 1,33, og 1920 udlæses, som det er.

Ved at springe kedelige detaljer over, kom vi til den konklusion, at generelt er alle skærme, inklusive tv-skærme, hvad angår elementer og deres størrelser, dækket af ét designlayout, og alle tv-skærme er et specialtilfælde af det generelle tværplatformsnet, og består af fem eller seks kolonner, som en gennemsnitlig tablet eller desktop. Hvem er interesseret i detaljer, gå i kommentarerne.

Enkelt brugergrænseflade til alle platforme

Nu, for at tegne en ny funktion, behøver vi ikke at tegne layouts for hver platform, plus tilpasningsmuligheder for hver af dem. Det er nok at vise et layout og dets tilpasningsevne til alle platforme og enheder af enhver bredde: telefoner - 320-599, alt andet - 600-1280.

Data → udvikling

Selvfølgelig, så meget som vi gerne vil opnå et fuldstændigt ensartet design, har hver platform sine egne unikke funktioner. Selvom både nettet og Smart TV bruger ReactJS + TypeScript-stakken, kører Smart TV-appen på ældre WebKit- og Presto-klienter og kan derfor ikke dele stilarter med nettet. Og e-mail nyhedsbreve er helt tvunget til at arbejde med tabellayout. Samtidig er der ingen af ​​de ikke-html-platforme, der bruger eller planlægger at bruge React Native eller nogen af ​​dets analoger, af frygt for forringelse af ydeevnen, da vi har for mange brugerdefinerede layouts, samlinger med kompleks opdateringslogik, billeder og videoer. Derfor er den almindelige ordning med at levere færdiglavede CSS-stile eller React-komponenter ikke egnet for os. Derfor besluttede vi at overføre data i JSON-format, der beskriver værdierne i en abstrakt deklarativ form.

Altså ejendom rounding: 8 Windows 10 app konverteres til CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Ejendom offsetTop: 12 den samme webklient i forskellige tilfælde kan fortolke som top, margin-top, padding-top eller transform

Deklarativiteten af ​​beskrivelsen indebærer også, at hvis platformen teknisk set ikke kan bruge en ejendom eller dens værdi, kan den ignorere den. Med hensyn til terminologi lavede vi en slags esperantosprog: nogle er taget fra Android, nogle fra SVG, nogle fra CSS.

Hvis du på en bestemt platform skal vise elementer anderledes, har vi implementeret muligheden for at overføre den tilsvarende datagenerering i form af en separat JSON-fil. For eksempel dikterer "i fokus"-tilstanden for Smart TV en ændring af tekstens position under plakaten, hvilket betyder, at denne komponent i værdien af ​​"indent"-egenskaben for denne platform vil indeholde de 8 indrykningspunkter, den har brug for. Selvom dette komplicerer designsystemets infrastruktur, giver det en ekstra grad af frihed, hvilket giver os muligheden for selv at styre den visuelle "ulighed" af platformene og ikke være gidsler for den arkitektur, vi har skabt.

Piktogrammer

Ikonografi i et digitalt produkt er altid et omfangsrigt og ikke det enkleste delprojekt, der ofte kræver en separat designer. Der er altid mange glyffer, hver af dem har flere størrelser og farver, og platforme har normalt brug for dem i forskellige formater. Generelt var der ingen grund til ikke at lægge alt dette ind i designsystemet.

Glyfer indlæses i SVG-vektorformat, og farveværdier erstattes automatisk med variabler. Klientapplikationer kan modtage dem klar til brug - i ethvert format og farve.

Forhåndsvisning

Oven i JSON-dataene skrev vi et værktøj til forhåndsvisning af komponenter - en JS-applikation, der sender JSON-data på farten gennem sine markup- og stilgeneratorer og viser forskellige variationer af hver komponent i browseren. Grundlæggende er preview nøjagtig den samme klient som platformsapplikationer og fungerer med de samme data.

Den nemmeste måde at forstå, hvordan en bestemt komponent fungerer, er ved at interagere med den. Derfor brugte vi ikke værktøjer som Storybook, men lavede et interaktivt preview - du kan røre, pege, klikke... Når du tilføjer en ny komponent til designsystemet, vises det i previewet, så platforme har noget at fokusere på, når implementere det.

Records

Baseret på de data, der leveres til platformene i form af JSON, genereres der automatisk dokumentation for komponenterne. En liste over egenskaber og mulige typer værdier i hver af dem er beskrevet. Efter autogenerering kan oplysningerne afklares manuelt, og der kan tilføjes en tekstbeskrivelse. Forhåndsvisningen og dokumentationen er krydsreferencer til hinanden på niveauet af hver komponent, og al information inkluderet i dokumentationen er tilgængelig for udviklere i form af yderligere JSON-filer.

Deprecator

En anden nødvendighed var muligheden for at udskifte og opdatere eksisterende komponenter over tid. Designsystemet har lært at fortælle udviklere, hvilke egenskaber eller endda hele komponenter, der ikke kan bruges og fjerne dem, så snart de ikke længere bruges på alle platforme. Der er stadig meget "manuelt" arbejde i denne proces, men vi står ikke stille.

Kundeudvikling

Den mest komplekse fase var utvivlsomt fortolkningen af ​​designsystemdata i koden for alle platforme, vi understøtter. Hvis for eksempel modulære grids på nettet ikke er noget nyt, så arbejdede udviklere af native mobilapplikationer til iOS og Android hårdt, før de fandt ud af, hvordan de skulle leve med det.

Til layout af iOS-applikationsskærme bruger vi to grundlæggende mekanismer leveret af iviUIKit: gratis layout af elementer og layout af samlinger af elementer. Vi bruger VIPER, og al interaktion med iviUIKit er koncentreret i View, og det meste interaktion med Apple UIKit er koncentreret i iviUIKit. Størrelsen og arrangementet af elementer er specificeret i form af kolonner og syntaktiske strukturer, der fungerer oven på de native iOS SDK-begrænsninger, hvilket gør dem mere praktiske. Dette forenklede især vores liv, når vi arbejdede med UICollectionView. Vi har skrevet flere brugerdefinerede wrappers til layouts, herunder ret komplekse. Der var et minimum af klientkode, og det blev deklarativt.

For at generere stilarter i Android-projektet bruger vi Gradle, der omdanner designsystemdata til stile i XML-format. Samtidig har vi flere generatorer på forskellige niveauer:

• Grundlæggende. Primitivernes data for generatorer på højere niveau analyseres.
• Ressource. Download billeder, ikoner og anden grafik.
• Komponent. De er skrevet for hver komponent, som beskriver hvilke egenskaber og hvordan man oversætter dem til stilarter.

Applikationsudgivelser

Efter at designere har tegnet en ny komponent eller redesignet en eksisterende, føres disse ændringer ind i designsystemet. Udviklerne af hver platform finjusterer deres kodegenerering for at understøtte ændringerne. Herefter kan den bruges til implementering af ny funktionalitet, hvor denne komponent er nødvendig. Interaktion med designsystemet sker således ikke i realtid, men kun på tidspunktet for samling af nye udgivelser. Denne tilgang giver også mulighed for bedre kontrol over dataoverførselsprocessen og sikrer kodefunktionalitet i klientudviklingsprojekter.

Resultaterne af

Det er et år siden, at designsystemet blev en del af den infrastruktur, der understøtter udviklingen af ​​Ivy online-biografen, og vi kan allerede nu drage nogle konklusioner:

• Dette er et stort og komplekst projekt, der kræver konstante dedikerede ressourcer.
• Dette gjorde det muligt for os at skabe vores eget unikke visuelt sprog på tværs af platforme, der opfylder målene for online videotjenesten.
• Vi har ikke længere visuelt og funktionelt haltende platforme.

Forhåndsvisning af Ivy design systemkomponenter - design.ivi.ru

Kilde: www.habr.com