Od UI-kita do oblikovalskega sistema

Izkušnja spletnega kina Ivy

Ko smo v začetku leta 2017 prvič razmišljali o ustvarjanju lastnega sistema dostave design-to-code, so mnogi o tem že govorili, nekateri pa so to celo počeli. Vendar pa je do danes malo znanega o izkušnjah pri gradnji večplatformnih sistemov oblikovanja in ni bilo jasnih in preverjenih receptov, ki bi opisovali tehnologije in metode za takšno preoblikovanje procesa izvajanja načrtovanja v že delujoč izdelek. In s "komponentami v kodi" pogosto mislijo zelo različne stvari.

Medtem je podjetje vsako leto podvojilo svoje osebje - potrebno je bilo povečati oddelek za oblikovanje in optimizirati procese ustvarjanja in prenosa postavitev v razvoj. Vse to pomnožimo z »živalskim vrtom« platform, ki jih je treba podpirati, in dobimo podobo babilonskega pandemonija, ki preprosto ne zmore »normalno« delati in ustvarjati dohodka. Razvoj platform je pogosto potekal vzporedno, ista funkcionalnost pa je bila lahko izdana na različnih platformah z večmesečnim zamikom.


Ločeni sklopi postavitev za vsako platformo

Tradicionalno smo začeli s problemi, ki bi jih oblikovalski sistem pomagal rešiti, in oblikovali zahteve za njegovo zasnovo. Poleg ustvarjanja enotnega vizualnega jezika, povečanja hitrosti postavitve in razvoja ter splošne izboljšave kakovosti izdelka je bilo bistveno čim bolj poenotiti dizajn. To je potrebno, da postane razvoj funkcionalnosti mogoč na vseh naših platformah hkrati: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku – brez dela na vsaki od njih posebej. In uspelo nam je!

Oblikovanje → podatki

Ko so bili doseženi temeljni dogovori med produktnim in razvojnim oddelkom, smo se usedli za izbiro tehnološkega sklada in obdelali podrobnosti celotnega procesa – od postavitve do izdaje. Za popolno avtomatizacijo procesa prenosa načrta v razvoj smo raziskali možnost razčlenjevanja parametrov komponente neposredno iz datotek Sketch s postavitvami. Izkazalo se je, da je bilo iskanje delov kode, ki smo jih potrebovali, in pridobivanje potrebnih parametrov zapleten in nevaren podvig. Prvič, oblikovalci bodo morali biti zelo previdni pri poimenovanju vseh plasti izvorne kode, drugič, to deluje le za najpreprostejše komponente, in tretjič, odvisnost od tehnologije in kodne strukture nekoga drugega originalne postavitve Sketch ogroža prihodnost celotnega projekt. Odločili smo se, da opustimo avtomatizacijo na tem področju. Tako se je pojavila prva oseba v ekipi projektantskega sistema, katere vhod so načrtovalne postavitve, izhod pa podatki, ki opisujejo vse parametre komponent in so hierarhično urejeni po metodologiji atomskega načrtovanja.

Preostalo je le še, kje in kako shraniti podatke, kako jih prenesti v razvoj in kako jih interpretirati v razvoju na vseh platformah, ki jih podpiramo. Večer je prenehal biti dolgočasen ... Rezultat rednih sestankov delovne skupine, ki jo sestavljajo oblikovalci in vodje ekip iz vsake platforme, je bil dogovor o naslednjem.

Vizualno sliko ročno razčlenimo na atomske elemente: pisave, barve, prosojnost, zamike, zaokrožitve, ikone, slike in trajanje animacij. Iz tega zbiramo gumbe, vnose, potrditvena polja, pripomočke za bančne kartice itd. Slogom katere koli ravni, razen ikon, dodelimo nesemantična imena, na primer imena mest, imena nimf, Pokemon, avto blagovne znamke... Pogoj je samo en - seznam ne sme biti izčrpan pred tem, kako se stili končajo - show must go! Ne smete se zanesti s semantiko, da vam ne bo treba na primer dodati srednjega gumba med "majhen" in "srednji".

Vizualni jezik

Razvijalci so morali razmišljati o tem, kako shraniti in prenesti podatke na način, ki je ustrezal vsem platformam, oblikovanje pa je moralo oblikovati elemente vmesnika, ki bi lahko izgledali dobro in učinkovito delovali v celotni floti podprtih naprav.

Pred tem nam je že uspelo "testirati" večino oblikovalskih elementov v aplikaciji za Windows 10, ki je bila takrat za nas nova platforma, torej je zahtevala upodabljanje in razvoj "iz nič". Z risanjem smo lahko pripravili in preizkusili večino komponent in razumeli, katere od njih naj bi bile vključene v prihodnji oblikovalski sistem Eevee. Brez takšnega peskovnika bi takšno izkušnjo lahko pridobili le z velikim številom iteracij na že delujočih platformah, to pa bi trajalo več kot eno leto.

Ponovna uporaba istih komponent na različnih platformah občutno zmanjša število postavitev in niz podatkov oblikovalskega sistema, zato je bilo treba pri načrtovanju rešiti še en problem, ki prej ni bil opisan v praksah oblikovanja in razvoja izdelkov - kako npr. ali je mogoče gumb za telefone in tablice ponovno uporabiti na televizorjih? In kaj naj naredimo z velikostmi pisav in elementov na tako različnih platformah?

Očitno je bilo treba oblikovati modularno mrežo za več platform, ki bi nastavila velikost besedila in elementov, ki smo jih potrebovali za vsako posebno platformo. Kot izhodišče za mrežo smo izbrali velikost in število filmskih plakatov, ki jih želimo videti na določenem platnu, in na podlagi tega oblikovali pravilo za konstrukcijo stolpcev mreže, pod pogojem, da je širina enega stolpca enaka na širino plakata.

Zdaj moramo vse velike zaslone spraviti v enako velikost postavitve in jih umestiti v skupno mrežo. Apple TV in Roku sta zasnovana v velikosti 1920x1080, Android TV - 960x540, pametni televizorji so, odvisno od prodajalca, enaki, vendar včasih 1280x720. Ko je aplikacija upodobljena in prikazana na zaslonih Full HD, se 960 pomnoži z 2, 1280 pomnoži z 1,33, 1920 pa se prikaže, kot je.

Če preskočimo dolgočasne podrobnosti, smo prišli do zaključka, da so na splošno vsi zasloni, vključno s televizijskimi zasloni, glede na elemente in njihove velikosti, zajeti v eni oblikovni postavitvi, vsi televizijski zasloni pa so poseben primer splošne medplatformske mreže, in je sestavljen iz petih ali šestih stolpcev, kot povprečna tablica ali namizni računalnik. Kogar zanimajo podrobnosti naj se oglasi v komentarjih.

En sam uporabniški vmesnik za vse platforme

Za risanje nove funkcije nam zdaj ni treba risati postavitev za vsako platformo in možnosti prilagajanja za vsako od njih. Dovolj je prikazati eno postavitev in njeno prilagodljivost za vse platforme in naprave katere koli širine: telefoni - 320-599, vse ostalo - 600-1280.

Podatki → razvoj

Seveda pa ima vsaka platforma svoje edinstvene značilnosti, ne glede na to, kako si želimo doseči popolnoma enoten dizajn. Čeprav tako splet kot Smart TV uporabljata sklad ReactJS + TypeScript, aplikacija Smart TV deluje na podedovanih odjemalcih WebKit in Presto in zato ne more deliti slogov s spletom. In e-poštna glasila so popolnoma prisiljena delati s tabelarično postavitvijo. Hkrati nobena od platform, ki niso html, ne uporablja in ne načrtuje uporabe React Native ali katerega koli od njegovih analogov, saj se boji poslabšanja zmogljivosti, saj imamo preveč postavitev po meri, zbirk s kompleksno logiko posodabljanja, slik in videoposnetkov. Zato običajna shema dostave že pripravljenih slogov CSS ali komponent React za nas ni primerna. Zato smo se odločili za prenos podatkov v formatu JSON, ki opisuje vrednosti v abstraktni deklarativni obliki.

Torej lastnina rounding: 8 Aplikacija Windows 10 se pretvori v CornerRadius="8", splet - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Lastnina offsetTop: 12 lahko isti spletni odjemalec v različnih primerih razlaga kot top, margin-top, padding-top ali transform

Deklarativnost opisa prav tako pomeni, da če platforma tehnično ne more uporabiti lastnosti ali njene vrednosti, jo lahko prezre. Kar zadeva terminologijo, smo naredili nekakšen esperanto: nekaj smo vzeli iz Androida, nekaj iz SVG, nekaj iz CSS.

Če morate na določeni platformi elemente prikazati drugače, smo implementirali možnost prenosa ustrezne generacije podatkov v obliki ločene datoteke JSON. Na primer, stanje »v fokusu« za Smart TV narekuje spremembo položaja besedila pod plakatom, kar za to platformo pomeni, da bo ta komponenta v vrednosti lastnosti »indent« vsebovala 8 točk zamika, ki jih potrebuje. Čeprav to zaplete infrastrukturo oblikovalskega sistema, daje dodatno stopnjo svobode, kar nam pušča možnost, da sami upravljamo z vizualno »različnostjo« platform in ne smemo biti talci arhitekture, ki smo jo ustvarili.

Piktogrami

Ikonografija v digitalnem izdelku je vedno obsežen in ne najenostavnejši podprojekt, ki pogosto zahteva posebnega oblikovalca. Glifov je vedno veliko, vsak ima več velikosti in barv, platforme pa jih običajno potrebujejo v različnih formatih. Na splošno ni bilo razloga, da vsega tega ne bi vključili v sistem oblikovanja.

Glifi se naložijo v vektorski obliki SVG, barvne vrednosti pa se samodejno nadomestijo s spremenljivkami. Odjemalske aplikacije jih lahko prejmejo pripravljene za uporabo – v kateri koli obliki in barvi.

Predprosmotr

Poleg podatkov JSON smo napisali orodje za predogled komponent – ​​aplikacijo JS, ki posreduje podatke JSON sproti skozi generatorje oznak in slogov ter prikaže različne različice vsake komponente v brskalniku. V bistvu je predogled popolnoma enak odjemalec kot aplikacije platforme in deluje z istimi podatki.

Najlažji način, da razumete, kako določena komponenta deluje, je z interakcijo z njo. Zato nismo uporabili orodij, kot je Storybook, ampak smo naredili interaktivni predogled - lahko se dotaknete, pokažete, kliknete ... Ko dodate novo komponento v sistem oblikovanja, se le-ta prikaže v predogledu, tako da se imajo platforme na kaj osredotočiti, ko izvajati.

Dokumentacija

Na podlagi podatkov, dobavljenih platformam v obliki JSON, se samodejno ustvari dokumentacija za komponente. Opisani so seznam lastnosti in možne vrste vrednosti v vsaki od njih. Po samodejnem generiranju je mogoče informacije ročno pojasniti in dodati besedilni opis. Predogled in dokumentacija se navzkrižno sklicujeta na ravni vsake komponente, vse informacije, vključene v dokumentacijo, pa so na voljo razvijalcem v obliki dodatnih datotek JSON.

Deprecator

Druga nuja je bila zmožnost zamenjave in posodobitve obstoječih komponent skozi čas. Sistem oblikovanja se je naučil povedati razvijalcem, katerih lastnosti ali celo celotnih komponent ni mogoče uporabiti, in jih odstraniti takoj, ko se ne uporabljajo več na vseh platformah. V tem procesu je še vedno veliko »ročnega« dela, vendar ne stojimo na mestu.

Razvoj strank

Nedvomno najbolj zapletena faza je bila interpretacija sistemskih podatkov načrtovanja v kodi vseh platform, ki jih podpiramo. Če na primer modularna omrežja na spletu niso nekaj novega, pa so razvijalci nativnih mobilnih aplikacij za iOS in Android trdo delali, preden so ugotovili, kako s tem živeti.

Za postavitev zaslonov aplikacij iOS uporabljamo dva osnovna mehanizma, ki jih ponuja iviUIKit: prosto postavitev elementov in postavitev zbirk elementov. Uporabljamo VIPER in vsa interakcija z iviUIKit je skoncentrirana v View, večina interakcij z Apple UIKit pa je skoncentrirana v iviUIKit. Velikosti in razporeditev elementov so določene glede na stolpce in sintaktične strukture, ki delujejo poleg domačih omejitev iOS SDK, zaradi česar so bolj praktični. To nam je še posebej poenostavilo življenje pri delu z UICollectionView. Napisali smo več ovojov po meri za postavitve, vključno s precej zapletenimi. Koda odjemalca je bila minimalna in postala je deklarativna.

Za generiranje slogov v projektu Android uporabljamo Gradle, ki podatke sistema za oblikovanje spremeni v sloge v formatu XML. Hkrati imamo več generatorjev različnih nivojev:

• Osnovno. Podatki primitivov za generatorje višje ravni so razčlenjeni.
• Vir. Prenesite slike, ikone in drugo grafiko.
• Komponenta. Napisani so za vsako komponento, ki opisuje, katere lastnosti in kako jih prevesti v sloge.

Izdaje aplikacij

Ko oblikovalci narišejo novo komponento ali preoblikujejo obstoječo, se te spremembe vnesejo v sistem načrtovanja. Razvijalci vsake platforme izpopolnjujejo svojo kodo za podporo spremembam. Po tem se lahko uporabi pri implementaciji nove funkcionalnosti, kjer je ta komponenta potrebna. Tako interakcija z oblikovalskim sistemom ne poteka v realnem času, ampak samo v času sestavljanja novih izdaj. Ta pristop omogoča tudi boljši nadzor nad procesom prenosa podatkov in zagotavlja funkcionalnost kode v razvojnih projektih strank.

Rezultati

Minilo je leto dni, odkar je sistem oblikovanja postal del infrastrukture, ki podpira razvoj spletnega kina Ivy, in že lahko potegnemo nekaj zaključkov:

• To je obsežen in kompleksen projekt, ki zahteva stalna namenska sredstva.
• To nam je omogočilo, da smo ustvarili lasten edinstven vizualni jezik za več platform, ki izpolnjuje cilje spletne video storitve.
• Nimamo več vizualno in funkcionalno zaostalih platform.

Predogled komponent sistema Ivy design - design.ivi.ru

Vir: www.habr.com