Från UI-kit till designsystem

Ivy onlinebioupplevelse

När vi i början av 2017 först funderade på att skapa vårt eget design-to-code-leveranssystem var det många som redan pratade om det och några gjorde det till och med. Än i dag är dock lite känt om erfarenheten av att bygga plattformsoberoende designsystem, och det har inte funnits några tydliga och beprövade recept som beskriver teknologier och metoder för sådan omvandling av processen för designimplementering till en redan fungerande produkt. Och med "komponenter i koden" menar de ofta väldigt olika saker.

Samtidigt fördubblade företaget sin personal år efter år - det var nödvändigt att skala designavdelningen och optimera processerna för att skapa och överföra layouter för utveckling. Vi multiplicerar allt detta med "zoo" av plattformar som behöver stödjas, och vi får ett sken av babylonisk pandemonium, som helt enkelt inte kan "göra det normalt" och generera inkomster. Utvecklingen av plattformar pågick ofta parallellt och samma funktionalitet kunde släppas på olika plattformar med flera månaders fördröjning.


Separata layoutuppsättningar för varje plattform

Traditionellt började vi med problem som ett designsystem skulle hjälpa till att lösa och formulerade krav på sin design. Förutom att skapa ett enhetligt visuellt språk, öka hastigheten på layout och utveckling, och förbättra kvaliteten på produkten överlag, var det viktigt att förena designen så mycket som möjligt. Detta är nödvändigt så att utvecklingen av funktionalitet blir möjlig på alla våra plattformar samtidigt: webben, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - utan att arbeta på var och en av dem separat. Och vi gjorde det!

Design → data

När de grundläggande överenskommelserna mellan produkt- och utvecklingsavdelningarna nåtts satte vi oss för att välja en teknikstack och arbeta fram detaljerna i hela processen - från layout till release. För att helt automatisera processen att överföra designen till utveckling, undersökte vi möjligheten att analysera komponentparametrar direkt från Sketch-filer med layouter. Det visade sig att det var en komplex och farlig uppgift att hitta de kodbitar vi behövde och extrahera parametrarna vi behövde. För det första måste designers vara extremt försiktiga med att namnge alla lager i källkoden, för det andra fungerar detta bara för de enklaste komponenterna, och för det tredje äventyrar beroendet av någon annans teknologi och kodstrukturen för den ursprungliga Sketch-layouten framtiden för hela projekt. Vi bestämde oss för att överge automatiseringen på detta område. Så här dök den första personen upp i designsystemteamet, vars input är designlayouter, och resultatet är data som beskriver komponenternas alla parametrar och är hierarkiskt ordnade enligt den atomära designmetoden.

Det enda som återstod att göra var var och hur man lagrar datan, hur man överför det till utveckling och hur man tolkar det i utvecklingen på alla plattformar vi stödjer. Kvällen upphörde att vara trög... Resultatet av regelbundna möten i arbetsgruppen bestående av designers och teamledare från varje plattform blev överenskommelsen om följande.

Vi analyserar det visuella manuellt i atomiska element: typsnitt, färger, transparens, indrag, avrundningar, ikoner, bilder och varaktigheter för animationer. Och från denna samlar vi in ​​knappar, ingångar, kryssrutor, bankkortswidgets, etc. Vi tilldelar stilarna på någon av nivåerna icke-semantiska namn, förutom ikoner, till exempel namn på städer, namn på nymfer, Pokemon, bil varumärken... Det finns bara ett villkor - listan bör inte uttömmas innan, hur stilarna slutar - show must go! Du bör inte ryckas med i semantik, så att du inte behöver lägga till en mittknapp mellan till exempel "small" och "medium".

Visuellt språk

Utvecklare fick fundera över hur de skulle lagra och överföra data på ett sätt som passade alla plattformar, och design var tvungen att designa gränssnittselement som kunde se bra ut och fungera effektivt över hela flottan av enheter som stöds.

Tidigare hade vi redan lyckats "testa" de flesta designelementen i en applikation för Windows 10, som vid den tiden var en ny plattform för oss, det vill säga det krävde rendering och utveckling "från grunden." Genom att rita den kunde vi förbereda och testa de flesta komponenterna och förstå vilka av dem som skulle ingå i det framtida Eevee designsystemet. Utan en sådan sandlåda skulle sådan erfarenhet bara kunna erhållas genom ett stort antal iterationer på redan fungerande plattformar, och detta skulle ta mer än ett år.

Att återanvända samma komponenter på olika plattformar minskar antalet layouter och mängden data i designsystemet avsevärt, så designen var tvungen att lösa ytterligare ett problem, som tidigare inte beskrivits i praxis för produktdesign och utveckling - hur t.ex. kan en knapp för telefoner och surfplattor återanvändas på tv? Och vad ska vi göra med storleken på typsnitt och element på så olika plattformar?

Uppenbarligen var det nödvändigt att designa ett modulärt rutnät för flera plattformar som skulle ställa in text- och elementstorlekarna vi behövde för varje specifik plattform. Som utgångspunkt för rutnätet valde vi storleken och antalet filmaffischer som vi vill se på en viss skärm och utifrån detta formulerade vi en regel för att konstruera rutkolumner, förutsatt att bredden på en kolumn är lika stor. till affischens bredd.

Nu måste vi få alla stora skärmar till samma layoutstorlek och passa in dem i ett gemensamt rutnät. Apple TV och Roku är designade i storleken 1920x1080, Android TV - 960x540, Smart TV, beroende på leverantör, är desamma, men ibland 1280x720. När appen renderas och visas på Full HD-skärmar multipliceras 960 med 2, 1280 multipliceras med 1,33 och 1920 matas ut som den är.

Genom att hoppa över tråkiga detaljer kom vi till slutsatsen att i allmänhet alla skärmar, inklusive tv-skärmar, vad gäller element och deras storlekar, täcks av en designlayout, och alla tv-skärmar är ett specialfall av det allmänna plattformsnätet, och består av fem eller sex kolumner, som en vanlig surfplatta eller dator. Vem är intresserad av detaljer, gå in i kommentarerna.

Ett enda användargränssnitt för alla plattformar

Nu, för att rita en ny funktion, behöver vi inte rita layouter för varje plattform, plus anpassningsmöjligheter för var och en av dem. Det räcker att visa en layout och dess anpassningsförmåga för alla plattformar och enheter av vilken bredd som helst: telefoner - 320-599, allt annat - 600-1280.

Data → utveckling

Naturligtvis, så mycket som vi skulle vilja uppnå en helt enhetlig design, har varje plattform sina egna unika egenskaper. Även om både webben och Smart TV använder ReactJS + TypeScript-stacken, kör Smart TV-appen på äldre WebKit- och Presto-klienter och kan därför inte dela stilar med webben. Och nyhetsbrev via e-post är helt tvingade att arbeta med tabellform. Samtidigt använder eller planerar ingen av de icke-html-plattformar att använda React Native eller någon av dess analoger, av rädsla för prestandaförsämring, eftersom vi har för många anpassade layouter, samlingar med komplex uppdateringslogik, bilder och videor. Därför är det vanliga schemat att leverera färdiga CSS-stilar eller React-komponenter inte lämpligt för oss. Därför bestämde vi oss för att överföra data i JSON-format och beskriva värdena i en abstrakt deklarativ form.

Egendom alltså rounding: 8 Windows 10-appen konverteras till CornerRadius="8", webb - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Fast egendom offsetTop: 12 samma webbklient i olika fall kan tolka som top, margin-top, padding-top eller transform

Beskrivningens deklarativitet innebär också att om plattformen tekniskt sett inte kan använda en egenskap eller dess värde, kan den ignorera den. Terminologiskt gjorde vi ett slags esperantospråk: en del togs från Android, en del från SVG, en del från CSS.

Om du på en viss plattform behöver visa element annorlunda har vi implementerat möjligheten att överföra motsvarande datagenerering i form av en separat JSON-fil. Till exempel, tillståndet "i fokus" för Smart TV dikterar en förändring av textens position under affischen, vilket innebär att för denna plattform kommer denna komponent i värdet för egenskapen "indent" att innehålla de 8 indragspunkter som den behöver. Även om detta komplicerar designsystemets infrastruktur, ger det en ytterligare grad av frihet, vilket ger oss möjlighet att hantera den visuella "olikheten" mellan plattformarna själva, och inte vara gisslan för arkitekturen vi skapade.

Piktogram

Ikonografi i en digital produkt är alltid ett voluminöst och inte det enklaste delprojektet, som ofta kräver en separat designer. Det finns alltid många glyfer, var och en av dem har flera storlekar och färger, och plattformar behöver dem vanligtvis i olika format. Generellt sett fanns det ingen anledning att inte lägga in allt detta i designsystemet.

Glyfer laddas i SVG-vektorformat och färgvärden ersätts automatiskt med variabler. Klientapplikationer kan ta emot dem redo att användas - i alla format och färger.

förhandsvisning

Utöver JSON-data skrev vi ett verktyg för att förhandsgranska komponenter - en JS-applikation som skickar JSON-data i farten genom sina markup- och stilgeneratorer, och visar olika varianter av varje komponent i webbläsaren. I huvudsak är förhandsvisning exakt samma klient som plattformsapplikationer och fungerar med samma data.

Det enklaste sättet att förstå hur en viss komponent fungerar är att interagera med den. Därför använde vi inte verktyg som Storybook utan gjorde en interaktiv förhandsgranskning – du kan peka, peka, klicka... När du lägger till en ny komponent i designsystemet visas den i förhandsgranskningen så att plattformar har något att fokusera på när genomföra den.

Документация

Baserat på den data som tillförs plattformarna i form av JSON genereras automatiskt dokumentation för komponenterna. En lista över egenskaper och möjliga typer av värden i var och en av dem beskrivs. Efter autogenerering kan informationen förtydligas manuellt och en textbeskrivning kan läggas till. Förhandsgranskningen och dokumentationen korsrefereras till varandra på nivån för varje komponent, och all information som ingår i dokumentationen är tillgänglig för utvecklare i form av ytterligare JSON-filer.

Deprecator

En annan nödvändighet var möjligheten att byta ut och uppdatera befintliga komponenter över tid. Designsystemet har lärt sig att tala om för utvecklare vilka egenskaper eller till och med hela komponenter som inte kan användas och ta bort dem så fort de inte längre används på alla plattformar. Det finns fortfarande mycket "manuellt" arbete i denna process, men vi står inte stilla.

Kundutveckling

Utan tvekan var det mest komplexa steget tolkningen av designsystemdata i koden för alla plattformar vi stödjer. Om till exempel modulära rutnät på webben inte är något nytt, så har utvecklare av inbyggda mobilapplikationer för iOS och Android arbetat hårt innan de kom på hur de skulle leva med det.

För att layouta iOS-applikationsskärmar använder vi två grundläggande mekanismer som tillhandahålls av iviUIKit: fri layout av element och layout av samlingar av element. Vi använder VIPER, och all interaktion med iviUIKit är koncentrerad till View, och den mesta interaktionen med Apple UIKit är koncentrerad till iviUIKit. Storleken och arrangemanget av element specificeras i termer av kolumner och syntaktiska strukturer som fungerar ovanpå de ursprungliga iOS SDK-begränsningarna, vilket gör dem mer praktiska. Detta förenklade särskilt vårt liv när vi arbetade med UICollectionView. Vi har skrivit flera anpassade omslag för layouter, inklusive ganska komplexa. Det fanns ett minimum av klientkod och det blev deklarativt.

För att generera stilar i Android-projektet använder vi Gradle, förvandlar designsystemdata till stilar i XML-format. Samtidigt har vi flera generatorer på olika nivåer:

• Grundläggande. Primitiva data för högre nivågeneratorer analyseras.
• Resurs. Ladda ner bilder, ikoner och annan grafik.
• Komponent. De är skrivna för varje komponent, som beskriver vilka egenskaper och hur man översätter dem till stilar.

Applikationer

Efter att designers har ritat en ny komponent eller gjort om en befintlig, matas dessa ändringar in i designsystemet. Utvecklarna av varje plattform finjusterar sin kodgenerering för att stödja förändringarna. Efter detta kan den användas vid implementering av ny funktionalitet där denna komponent behövs. Således sker interaktion med designsystemet inte i realtid, utan endast vid tidpunkten för montering av nya utgåvor. Detta tillvägagångssätt möjliggör också bättre kontroll över dataöverföringsprocessen och säkerställer kodfunktionalitet i klientutvecklingsprojekt.

Resultat av

Det har gått ett år sedan designsystemet blev en del av den infrastruktur som stöder utvecklingen av Ivy onlinebiograf, och vi kan redan dra några slutsatser:

• Detta är ett stort och komplext projekt som kräver konstant dedikerade resurser.
• Detta gjorde det möjligt för oss att skapa vårt eget unika plattformsoberoende visuella språk som uppfyller målen för onlinevideotjänsten.
• Vi har inte längre visuellt och funktionellt eftersläpande plattformar.

Förhandsvisning av Ivy designsystemkomponenter - design.ivi.ru

Källa: will.com