Od UI-kita do sistema dizajna

Ivy online bioskopsko iskustvo

Kada smo početkom 2017. prvi put razmišljali o stvaranju vlastitog sistema isporuke dizajna u kod, mnogi su već pričali o tome, a neki su to čak i radili. Međutim, do danas se malo zna o iskustvu izgradnje cross-platform dizajn sistema, a ne postoje jasni i provjereni recepti koji opisuju tehnologije i metode za takvu transformaciju procesa implementacije dizajna u već radni proizvod. A pod "komponentama u kodu" često podrazumijevaju vrlo različite stvari.

U međuvremenu, kompanija je iz godine u godinu udvostručavala svoje osoblje - bilo je potrebno skalirati odjel dizajna i optimizirati procese kreiranja i prijenosa izgleda za razvoj. Sve to pomnožimo sa “zoološkim vrtom” platformi koje treba podržati i dobijemo privid babilonskog pandemonijuma, koji jednostavno nije u stanju da “radi normalno” i ostvaruje prihod. Razvoj platformi se često odvijao paralelno, a ista funkcionalnost je mogla biti objavljena na različitim platformama sa zakašnjenjem od nekoliko mjeseci.


Odvojeni setovi izgleda za svaku platformu

Tradicionalno smo započeli sa problemima koje bi projektantski sistem mogao da reši i formulisali zahteve za njegovo projektovanje. Pored stvaranja jedinstvenog vizuelnog jezika, povećanja brzine izgleda i razvoja, i poboljšanja kvaliteta proizvoda u celini, bilo je od vitalnog značaja da se dizajn što je više moguće ujednači. Ovo je neophodno kako bi razvoj funkcionalnosti postao moguć na svim našim platformama istovremeno: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - bez rada na svakoj od njih posebno. I uspjeli smo!

Dizajn → podaci

Kada su postignuti temeljni dogovori između odjela za proizvode i razvoj, sjeli smo da odaberemo tehnološku grupu i razradimo detalje cijelog procesa - od izgleda do izdanja. Kako bismo u potpunosti automatizirali proces prijenosa dizajna u razvoj, istražili smo opciju raščlanjivanja parametara komponenti direktno iz Sketch datoteka sa rasporedom. Ispostavilo se da je pronalaženje dijelova koda koji su nam bili potrebni i izdvajanje potrebnih parametara složen i opasan poduhvat. Prvo, dizajneri će morati biti izuzetno oprezni u imenovanju svih slojeva izvornog koda, drugo, ovo funkcionira samo za najjednostavnije komponente, i treće, ovisnost o tuđoj tehnologiji i strukturi koda originalnog izgleda Sketcha ugrožava budućnost čitavog projekat. Odlučili smo da napustimo automatizaciju u ovoj oblasti. Tako se pojavila prva osoba u timu projektantskog sistema, čiji su ulazni izgledi dizajna, a izlaz podaci koji opisuju sve parametre komponenti i hijerarhijski poredani prema metodologiji atomskog dizajna.

Jedino što je preostalo je gdje i kako pohraniti podatke, kako ih prenijeti u razvoj i kako ih interpretirati u razvoju na svim platformama koje podržavamo. Veče je prestalo da bude tmurno... Rezultat redovnih sastanaka radne grupe koju čine dizajneri i vođe timova sa svake platforme bio je dogovor o sledećem.

Ručno raščlanjamo vizual na atomske elemente: fontove, boje, prozirnost, uvlake, zaokruživanja, ikone, slike i trajanja animacija. I od toga prikupljamo dugmad, unose, potvrdne okvire, widgete bankovne kartice, itd. Dodjeljujemo nesemantička imena stilovima bilo kojeg nivoa, osim ikona, na primjer, imena gradova, imena nimfi, Pokemona, automobila brendovi... Postoji samo jedan uslov - lista ne treba iscrpljivati ​​pre , kako završavaju stilovi - show must go! Ne biste se trebali zanositi semantikom, tako da ne morate dodavati srednje dugme između "mali" i "srednji", na primjer.

Vizuelni jezik

Programerima je prepušteno da razmišljaju o tome kako pohraniti i prenijeti podatke na način koji odgovara svim platformama, a dizajn je morao dizajnirati elemente interfejsa koji bi mogli izgledati dobro i efikasno raditi na cijeloj floti podržanih uređaja.

Ranije smo već uspjeli “testirati” većinu elemenata dizajna u aplikaciji za Windows 10, koja je u to vrijeme za nas bila nova platforma, odnosno zahtijevala je renderiranje i razvoj “od nule”. Njegovim crtanjem smo bili u mogućnosti da pripremimo i testiramo većinu komponenti i shvatimo koje od njih treba da budu uključene u budući Eevee sistem dizajna. Bez takvog sandboxa, takvo iskustvo bi se moglo steći samo kroz veliki broj iteracija na već radnim platformama, a to bi potrajalo više od godinu dana.

Ponovna upotreba istih komponenti na različitim platformama značajno smanjuje broj rasporeda i niz podataka dizajn sistema, pa je dizajn morao da reši još jedan problem, koji ranije nije opisan u praksi dizajna i razvoja proizvoda – kako npr. da li se dugme za telefone i tablete može ponovo koristiti na televizorima? A što da radimo s veličinama fontova i elemenata na tako različitim platformama?

Očigledno, bilo je potrebno dizajnirati višeplatformsku modularnu mrežu koja će postaviti potrebne veličine teksta i elemenata za svaku specifičnu platformu. Kao polaznu tačku za mrežu, odabrali smo veličinu i broj filmskih postera koje želimo da vidimo na određenom ekranu i na osnovu toga formulisali pravilo za izgradnju kolona mreže, pod uslovom da je širina jednog stupca jednaka na širinu postera.

Sada moramo sve velike ekrane dovesti na istu veličinu rasporeda i uklopiti ih u zajedničku mrežu. Apple TV i Roku su dizajnirani u veličini 1920x1080, Android TV - 960x540, Smart TV-i, ovisno o dobavljaču, su isti, ali ponekad 1280x720. Kada se aplikacija prikaže i prikaže na Full HD ekranima, 960 se množi sa 2, 1280 se množi sa 1,33, a 1920 se ispisuje onako kako jeste.

Preskačući dosadne detalje, došli smo do zaključka da su generalno svi ekrani, uključujući i televizijske ekrane, po elementima i njihovim veličinama, pokriveni jednim dizajnom, a svi televizijski ekrani su poseban slučaj opšte platformske mreže, i sastoje se od pet ili šest kolona, ​​poput prosječnog tableta ili desktopa. Koga zanimaju detalji neka u komentarima.

Jedinstveni korisnički interfejs za sve platforme

Sada, da bismo nacrtali novu funkciju, ne moramo crtati rasporede za svaku platformu, plus opcije prilagodljivosti za svaku od njih. Dovoljno je prikazati jedan raspored i njegovu prilagodljivost za sve platforme i uređaje bilo koje širine: telefoni - 320-599, sve ostalo - 600-1280.

Podaci → razvoj

Naravno, koliko god želimo da postignemo potpuno jedinstven dizajn, svaka platforma ima svoje jedinstvene karakteristike. Iako i web i Smart TV koriste ReactJS + TypeScript stog, Smart TV aplikacija radi na starim WebKit i Presto klijentima i stoga ne može dijeliti stilove s webom. A email bilteni su u potpunosti prisiljeni da rade sa tabelarnim izgledom. Istovremeno, nijedna od ne-html platformi ne koristi niti planira da koristi React Native ili bilo koji od njegovih analoga, plašeći se degradacije performansi, jer imamo previše prilagođenih izgleda, kolekcija sa složenom logikom ažuriranja, slika i video zapisa. Stoga, uobičajena shema isporuke gotovih CSS stilova ili React komponenti nije prikladna za nas. Stoga smo odlučili prenijeti podatke u JSON formatu, opisujući vrijednosti u apstraktnom deklarativnom obliku.

Dakle vlasništvo rounding: 8 Windows 10 aplikacija se pretvara u CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Nekretnina offsetTop: 12 isti web klijent u različitim slučajevima može tumačiti kao top, margin-top, padding-top ili transform

Deklarativnost opisa također implicira da ako platforma tehnički ne može koristiti svojstvo ili njegovu vrijednost, može ga zanemariti. Što se tiče terminologije, napravili smo neku vrstu esperanto jezika: neki su preuzeti sa Androida, neki iz SVG-a, neki iz CSS-a.

Ako na određenoj platformi trebate drugačije prikazati elemente, implementirali smo mogućnost prijenosa odgovarajuće generacije podataka u obliku zasebne JSON datoteke. Na primjer, stanje “u fokusu” za Smart TV diktira promjenu položaja teksta ispod postera, što znači da će za ovu platformu ova komponenta u vrijednosti svojstva “indent” sadržavati 8 tačaka uvlačenja koje su joj potrebne. Iako ovo komplikuje infrastrukturu sistema dizajna, daje dodatni stepen slobode, ostavljajući nam mogućnost da sami upravljamo vizuelnom „različitošću“ platformi, a ne da budemo taoci arhitekture koju smo kreirali.

Piktogrami

Ikonografija u digitalnom proizvodu uvijek je obiman i ne najjednostavniji podprojekat, koji često zahtijeva posebnog dizajnera. Uvijek ima puno glifova, svaki od njih ima nekoliko veličina i boja, a platformama su obično potrebni u različitim formatima. Generalno, nije bilo razloga da se sve ovo ne stavi u sistem dizajna.

Glifovi se učitavaju u SVG vektorskom formatu, a vrijednosti boja se automatski zamjenjuju varijablama. Klijentske aplikacije mogu ih primiti spremne za upotrebu - u bilo kojem formatu i boji.

Predprosmotr

Povrh JSON podataka, napisali smo alat za pregled komponenti - JS aplikaciju koja prenosi JSON podatke u hodu kroz svoje markere i generatore stilova, i prikazuje različite varijacije svake komponente u pretraživaču. U suštini, pregled je potpuno isti klijent kao platformske aplikacije i radi sa istim podacima.

Najlakši način da shvatite kako određena komponenta funkcionira je interakcija s njom. Stoga nismo koristili alate kao što je Storybook, već smo napravili interaktivni pregled - možete dodirnuti, pokazati, kliknuti... Prilikom dodavanja nove komponente u sistem dizajna, ona se pojavljuje u pregledu tako da platforme imaju na šta da se fokusiraju kada implementirajući ga.

Dokumentacija

Na osnovu podataka koji se dostavljaju platformama u obliku JSON-a, dokumentacija za komponente se automatski generiše. Opisana je lista svojstava i mogućih tipova vrijednosti u svakoj od njih. Nakon automatskog generiranja, informacije se mogu razjasniti ručno i dodati tekstualni opis. Pregled i dokumentacija su međusobno povezani na nivou svake komponente, a sve informacije uključene u dokumentaciju dostupne su programerima u obliku dodatnih JSON datoteka.

Deprecator

Još jedna potreba bila je mogućnost zamjene i ažuriranja postojećih komponenti tokom vremena. Dizajnerski sistem je naučio da kaže programerima koja svojstva ili čak čitave komponente ne mogu da se koriste i da ih ukloni čim se više ne koriste na svim platformama. U ovom procesu ima još dosta „manualnog“ rada, ali ne stojimo na mjestu.

Razvoj klijenata

Nesumnjivo, najkompleksnija faza je bila interpretacija podataka dizajn sistema u kodu svih platformi koje podržavamo. Ako, na primjer, modularne mreže na webu nisu nešto novo, onda su programeri nativnih mobilnih aplikacija za iOS i Android naporno radili prije nego što su shvatili kako živjeti s tim.

Za raspored ekrana iOS aplikacija koristimo dva osnovna mehanizma koje pruža iviUIKit: besplatni raspored elemenata i raspored kolekcija elemenata. Koristimo VIPER, a sva interakcija sa iviUIKit-om je koncentrisana u View-u, a većina interakcija sa Apple UIKit-om je koncentrisana u iviUIKit-u. Veličine i raspored elemenata su specificirani u smislu kolona i sintaksičkih struktura koje rade na vrhu nativnih iOS SDK ograničenja, čineći ih praktičnijim. Ovo nam je posebno pojednostavilo život pri radu sa UICollectionView. Napisali smo nekoliko prilagođenih omota za rasporede, uključujući prilično složene. Postojao je minimum klijentskog koda i postao je deklarativni.

Za generiranje stilova u Android projektu koristimo Gradle, pretvarajući podatke sistema dizajna u stilove u XML formatu. Istovremeno, imamo nekoliko generatora različitih nivoa:

• Osnovno. Podaci primitiva za generatore višeg nivoa se analiziraju.
• Resurs. Preuzmite slike, ikone i drugu grafiku.
• Komponenta. Oni su napisani za svaku komponentu, koja opisuje koja svojstva i kako ih prevesti u stilove.

Izdanja aplikacija

Nakon što su dizajneri nacrtali novu komponentu ili redizajnirali postojeću, ove promjene se unose u sistem dizajna. Programeri svake platforme fino podešavaju generisanje koda kako bi podržali promjene. Nakon toga može se koristiti u implementaciji nove funkcionalnosti gdje je ova komponenta potrebna. Dakle, interakcija sa dizajnerskim sistemom se ne dešava u realnom vremenu, već samo u trenutku sklapanja novih izdanja. Ovaj pristup također omogućava bolju kontrolu nad procesom prijenosa podataka i osigurava funkcionalnost koda u projektima razvoja klijenata.

Ishodi

Prošlo je godinu dana otkako je sistem dizajna postao dio infrastrukture koja podržava razvoj Ivy online kina, a već možemo izvući neke zaključke:

• Ovo je veliki i složen projekat koji zahtijeva stalne namjenske resurse.
• To nam je omogućilo da kreiramo sopstveni jedinstveni vizuelni jezik na više platformi koji ispunjava ciljeve onlajn video usluge.
• Više nemamo vizuelno i funkcionalno zaostale platforme.

Pregled komponenti Ivy dizajn sistema - design.ivi.ru

izvor: www.habr.com