Od UI-kitu až po dizajnový systém

Online zážitok z kina Ivy

Keď sme začiatkom roka 2017 prvýkrát uvažovali o vytvorení vlastného systému doručovania dizajnu do kódu, mnohí o tom už hovorili a niektorí to dokonca robili. Dodnes sa však málo vie o skúsenostiach s budovaním multiplatformových dizajnových systémov a neexistujú jasné a overené recepty popisujúce technológie a metódy takejto transformácie procesu implementácie dizajnu na už fungujúci produkt. A pod „komponentmi v kóde“ často znamenajú veľmi odlišné veci.

Od UI-kitu až po dizajnový systém
Spoločnosť medzitým zdvojnásobila počet zamestnancov rok čo rok – bolo potrebné škálovať dizajnové oddelenie a optimalizovať procesy vytvárania a prenosu layoutov pre vývoj. Toto všetko znásobíme „zoo“ platforiem, ktoré treba podporovať, a získame zdanie babylonského pandemónia, ktoré jednoducho nie je schopné „robiť to normálne“ a generovať príjem. Vývoj platforiem často prebiehal paralelne a rovnaká funkcionalita mohla byť uvoľnená na rôzne platformy s oneskorením niekoľkých mesiacov.

Od UI-kitu až po dizajnový systém
Samostatné sady rozloženia pre každú platformu

Tradične sme začínali problémami, ktoré by návrhový systém pomohol vyriešiť a sformulovali sme požiadavky na jeho návrh. Okrem vytvorenia jednotného vizuálneho jazyka, zvýšenia rýchlosti layoutu a vývoja a celkového zlepšenia kvality produktu bolo životne dôležité čo najviac zjednotiť dizajn. Je to potrebné, aby bol vývoj funkčnosti možný na všetkých našich platformách súčasne: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - bez toho, aby sme na každej z nich pracovali samostatne. A podarilo sa nám to!

Dizajn → údaje

Keď boli dosiahnuté základné dohody medzi produktovým a vývojovým oddelením, sadli sme si, aby sme vybrali technologický balík a vypracovali detaily celého procesu – od návrhu až po vydanie. Aby sme plne automatizovali proces prenosu návrhu do vývoja, preskúmali sme možnosť analýzy parametrov komponentov priamo zo súborov Sketch s rozložením. Ukázalo sa, že nájsť potrebné časti kódu a extrahovať parametre, ktoré sme potrebovali, bolo zložité a nebezpečné. Po prvé, dizajnéri budú musieť byť mimoriadne opatrní pri pomenovaní všetkých vrstiev zdrojového kódu, po druhé, toto funguje len pre najjednoduchšie komponenty a po tretie, závislosť na cudzej technológii a štruktúre kódu pôvodného rozloženia Sketch ohrozuje budúcnosť celého projektu. V tejto oblasti sme sa rozhodli opustiť automatizáciu. Takto sa objavil prvý človek v tíme návrhového systému, ktorého vstupom sú dizajnové rozloženia a výstupom sú dáta popisujúce všetky parametre komponentov a hierarchicky usporiadané podľa metodiky atomického dizajnu.

Zostávalo už len to, kde a ako dáta uložiť, ako ich preniesť do vývoja a ako ich interpretovať pri vývoji na všetkých platformách, ktoré podporujeme. Večer prestal byť mdlý... Výsledkom pravidelných stretnutí pracovnej skupiny zloženej z dizajnérov a vedúcich tímov z jednotlivých platforiem bola dohoda o nasledujúcom.

Manuálne analyzujeme vizuál na atómové prvky: fonty, farby, priehľadnosť, zarážky, zaoblenia, ikony, obrázky a trvanie animácií. A z toho zbierame tlačidlá, vstupy, zaškrtávacie políčka, widgety bankových kariet atď. Štýlom ktorejkoľvek úrovne okrem ikon priraďujeme nesémantické názvy, napríklad názvy miest, mená nýmf, pokémonov, áut značky... Je len jedna podmienka - zoznam by nemal byť vyčerpaný skôr, ako končia štýly - prehliadka musí ísť! Nemali by ste sa nechať uniesť sémantikou, aby ste napríklad medzi „malé“ a „stredné“ nemuseli pridávať stredné tlačidlo.

Vizuálny jazyk

Vývojári museli premýšľať o tom, ako ukladať a prenášať údaje spôsobom, ktorý vyhovuje všetkým platformám, a dizajn musel navrhnúť prvky rozhrania, ktoré by mohli vyzerať dobre a efektívne fungovať v rámci celej flotily podporovaných zariadení.

V minulosti sme už stihli „otestovať“ väčšinu dizajnových prvkov v aplikácii pre Windows 10, ktorá bola v tom čase pre nás novou platformou, čiže vyžadovala rendering a vývoj „od nuly“. Jeho nakreslením sme mohli pripraviť a otestovať väčšinu komponentov a pochopiť, ktoré z nich by mali byť zahrnuté v budúcom dizajnovom systéme Eevee. Bez takéhoto sandboxu by sa takéto skúsenosti dali získať iba veľkým počtom iterácií na už fungujúcich platformách, čo by trvalo viac ako rok.

Opätovné použitie tých istých komponentov na rôznych platformách výrazne znižuje počet rozložení a množstvo údajov návrhového systému, takže návrh musel vyriešiť ešte jeden problém, ktorý predtým nebol popísaný v postupoch dizajnu a vývoja produktu - ako napr. dá sa tlačidlo pre telefóny a tablety znovu použiť na televízoroch? A čo by sme mali robiť s veľkosťami fontov a prvkov na tak odlišných platformách?

Je zrejmé, že bolo potrebné navrhnúť multiplatformovú modulárnu mriežku, ktorá by nastavila veľkosti textu a prvkov, ktoré sme potrebovali pre každú konkrétnu platformu. Ako východiskový bod pre mriežku sme zvolili veľkosť a počet filmových plagátov, ktoré chceme vidieť na konkrétnej obrazovke a na základe toho sme sformulovali pravidlo pre konštrukciu mriežkových stĺpcov za predpokladu, že šírka jedného stĺpca je rovnaká na šírku plagátu.

Od UI-kitu až po dizajnový systém
Teraz musíme priviesť všetky veľké obrazovky na rovnakú veľkosť rozloženia a umiestniť ich do spoločnej mriežky. Apple TV a Roku sú navrhnuté vo veľkosti 1920x1080, Android TV - 960x540, Smart TV, v závislosti od predajcu, sú rovnaké, ale niekedy 1280x720. Keď je aplikácia vykreslená a zobrazená na obrazovkách s rozlíšením Full HD, hodnota 960 sa vynásobí 2, hodnota 1280 sa vynásobí 1,33 a hodnota 1920 sa zobrazí tak, ako je.

Preskočením nudných detailov sme dospeli k záveru, že vo všeobecnosti všetky obrazovky, vrátane televíznych obrazoviek, pokiaľ ide o prvky a ich veľkosti, sú pokryté jedným dizajnovým rozložením a všetky televízne obrazovky sú špeciálnym prípadom všeobecnej multiplatformovej siete, a pozostávajú z piatich alebo šiestich stĺpcov, ako priemerný tablet alebo počítač. Koho zaujímajú podrobnosti, nech napíše do komentárov.

Od UI-kitu až po dizajnový systém
Jediné používateľské rozhranie pre všetky platformy

Teraz, aby sme nakreslili novú funkciu, nemusíme kresliť rozloženia pre každú platformu, plus možnosti adaptability pre každú z nich. Stačí ukázať jedno rozloženie a jeho prispôsobivosť pre všetky platformy a zariadenia akejkoľvek šírky: telefóny - 320-599, všetko ostatné - 600-1280.

Dáta → voj

Samozrejme, akokoľvek by sme chceli dosiahnuť úplne jednotný dizajn, každá platforma má svoje jedinečné vlastnosti. Aj keď web aj Smart TV používajú zásobník ReactJS + TypeScript, aplikácia Smart TV beží na starších klientoch WebKit a Presto, a preto nemôže zdieľať štýly s webom. A e-mailové bulletiny sú úplne nútené pracovať s tabuľkovým usporiadaním. Zároveň žiadna z platforiem, ktoré nie sú html, nepoužíva ani neplánuje používať React Native alebo niektorú z jej analógov, pretože sa obáva zníženia výkonu, pretože máme príliš veľa vlastných rozložení, kolekcií s komplexnou logikou aktualizácií, obrázkov a videí. Preto nám nevyhovuje bežná schéma dodávania hotových CSS štýlov alebo komponentov React. Preto sme sa rozhodli prenášať údaje vo formáte JSON, popisujúce hodnoty v abstraktnej deklaratívnej forme.

Takže majetok rounding: 8 Aplikácia Windows 10 sa prevedie na CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Nehnuteľnosť offsetTop: 12 ten istý webový klient v rôznych prípadoch môže interpretovať ako top, margin-top, padding-top alebo transform

Z deklaratívnosti popisu tiež vyplýva, že ak platforma technicky nemôže použiť vlastnosť alebo jej hodnotu, môže ju ignorovať. Čo sa týka terminológie, vytvorili sme akýsi jazyk esperanta: časť bola prevzatá z Androidu, časť zo SVG, časť z CSS.

Ak na konkrétnej platforme potrebujete zobraziť prvky inak, implementovali sme možnosť preniesť príslušné generovanie údajov vo forme samostatného súboru JSON. Napríklad stav „zaostrený“ pre Smart TV diktuje zmenu polohy textu pod plagátom, čo znamená, že pre túto platformu bude tento komponent v hodnote vlastnosti „indent“ obsahovať 8 bodov odsadenia, ktoré potrebuje. Aj keď to komplikuje infraštruktúru návrhového systému, poskytuje to dodatočnú mieru slobody, vďaka čomu máme možnosť sami riadiť vizuálnu „odlišnosť“ platforiem a nebyť rukojemníkom architektúry, ktorú sme vytvorili.

Od UI-kitu až po dizajnový systém

Piktogramy

Ikonografia v digitálnom produkte je vždy objemný a nie najjednoduchší podprojekt, ktorý si často vyžaduje samostatného dizajnéra. Glyfov je vždy veľa, každý z nich má niekoľko veľkostí a farieb a platformy ich zvyčajne potrebujú v rôznych formátoch. Vo všeobecnosti nebol dôvod toto všetko nevložiť do konštrukčného systému.

Od UI-kitu až po dizajnový systém
Glyfy sa načítajú vo vektorovom formáte SVG a hodnoty farieb sa automaticky nahradia premennými. Klientske aplikácie ich môžu dostať pripravené na použitie – v akomkoľvek formáte a farbe.

náhľad

Okrem údajov JSON sme napísali nástroj na zobrazenie ukážky komponentov – aplikáciu JS, ktorá prenáša údaje JSON za behu cez generátory značiek a štýlov a zobrazuje rôzne variácie každého komponentu v prehliadači. Preview je v podstate rovnaký klient ako platformové aplikácie a pracuje s rovnakými údajmi.

Najjednoduchší spôsob, ako pochopiť, ako konkrétny komponent funguje, je interakcia s ním. Preto sme nepoužili nástroje ako Storybook, ale urobili sme interaktívny náhľad – môžete sa ho dotýkať, ukazovať, klikať... Pri pridávaní nového komponentu do dizajnového systému sa tento zobrazí v náhľade, aby sa platformy mali na čo sústrediť, keď implementovať.

Záznamy

Na základe údajov dodávaných platformám vo forme JSON sa automaticky generuje dokumentácia ku komponentom. Je popísaný zoznam vlastností a možných typov hodnôt v každej z nich. Po automatickom vygenerovaní je možné informácie objasniť manuálne a pridať textový popis. Náhľad a dokumentácia sú navzájom prepojené na úrovni každého komponentu a všetky informácie zahrnuté v dokumentácii sú vývojárom k dispozícii vo forme ďalších súborov JSON.

Deprecator

Ďalšou nevyhnutnosťou bola možnosť časom nahradiť a aktualizovať existujúce komponenty. Dizajnový systém sa naučil vývojárom povedať, ktoré vlastnosti alebo dokonca celé komponenty nemožno použiť a odstrániť ich hneď, ako sa už nepoužívajú na všetkých platformách. V tomto procese je stále veľa „manuálnej“ práce, ale nezostávame stáť na mieste.

Rozvoj klienta

Najzložitejšou etapou bola nepochybne interpretácia údajov návrhového systému v kóde všetkých nami podporovaných platforiem. Ak napríklad modulárne gridy na webe nie sú novinkou, tak vývojári natívnych mobilných aplikácií pre iOS a Android tvrdo pracovali, kým prišli na to, ako sa s tým dá žiť.

Na rozloženie obrazoviek aplikácií pre iOS používame dva základné mechanizmy, ktoré poskytuje iviUIKit: voľné rozloženie prvkov a rozloženie kolekcií prvkov. Používame VIPER a všetka interakcia s iviUIKit je sústredená v View a väčšina interakcií s Apple UIKit je sústredená v iviUIKit. Veľkosti a usporiadanie prvkov sú špecifikované z hľadiska stĺpcov a syntaktických štruktúr, ktoré fungujú nad rámec natívnych obmedzení iOS SDK, vďaka čomu sú praktickejšie. To nám najmä zjednodušilo život pri práci s UICollectionView. Napísali sme niekoľko vlastných obalov pre rozloženia, vrátane pomerne zložitých. Bolo tam minimum klientskeho kódu a stal sa deklaratívnym.

Na generovanie štýlov v projekte Android používame Gradle, ktorý premieňa údaje návrhového systému na štýly vo formáte XML. Zároveň máme niekoľko generátorov rôznych úrovní:

  • Základné. Analyzujú sa údaje primitív pre generátory vyššej úrovne.
  • Zdroj. Stiahnite si obrázky, ikony a inú grafiku.
  • Komponent. Pre každý komponent sú napísané, ktoré popisujú aké vlastnosti a ako ich previesť do štýlov.

Vydania aplikácie

Potom, čo dizajnéri nakreslia nový komponent alebo prerobia existujúci, tieto zmeny sa vložia do konštrukčného systému. Vývojári každej platformy dolaďujú generovanie kódu, aby podporili zmeny. Potom môže byť použitý pri implementácii novej funkcionality tam, kde je tento komponent potrebný. Interakcia s dizajnovým systémom teda nenastáva v reálnom čase, ale až v čase zostavovania nových vydaní. Tento prístup tiež umožňuje lepšiu kontrolu nad procesom prenosu údajov a zabezpečuje funkčnosť kódu v projektoch vývoja klientov.

Výsledky

Je tomu už rok, čo sa dizajnový systém stal súčasťou infraštruktúry podporujúcej rozvoj online kina Ivy a už teraz môžeme vyvodiť nejaké závery:

  • Ide o rozsiahly a komplexný projekt, ktorý si vyžaduje neustále vyhradené zdroje.
  • To nám umožnilo vytvoriť náš vlastný jedinečný vizuálny jazyk naprieč platformami, ktorý spĺňa ciele online video služby.
  • Už nemáme vizuálne a funkčne zaostávajúce platformy.

Ukážka komponentov dizajnového systému Ivy - design.ivi.ru

Zdroj: hab.com

Pridať komentár