Fan UI-kit oant ûntwerpsysteem

Ivy online bioskoopûnderfining

Doe't wy oan it begjin fan 2017 foar it earst tochten oer it meitsjen fan ús eigen design-to-code-leveringssysteem, wiene in protte der al oer en guon diene it sels. Oant hjoed de dei is lykwols net folle bekend oer de ûnderfining fan it bouwen fan cross-platform designsystemen, en d'r binne gjin dúdlike en bewiisde resepten west dy't technologyen en metoaden beskriuwe foar sa'n transformaasje fan it proses fan ûntwerpimplementaasje yn in al wurkjend produkt. En mei "komponinten yn 'e koade" betsjutte se faak hiel oare dingen.

Underwilens ferdûbele it bedriuw har personiel jier nei jier - it wie nedich om de ûntwerpôfdieling te skaaljen en de prosessen fan it meitsjen en oerdragen fan yndielingen foar ûntwikkeling te optimalisearjen. Wy fermannichfâldigje dit alles mei de "dierentuin" fan platfoarms dy't moatte wurde stipe, en wy krije in skyn fan Babyloanyske pandemonium, dat is gewoan net by steat om te "dwaan it normaal" en generearje ynkommen. De ûntwikkeling fan platfoarms gie faak parallel, en deselde funksjonaliteit koe wurde frijlitten op ferskate platfoarms mei in efterstân fan ferskate moannen.


Aparte opmaak sets foar elk platfoarm

Tradysjoneel begûnen wy mei problemen dy't in ûntwerpsysteem soe helpe oplosse en easken foar har ûntwerp formulearre. Neist it meitsjen fan in unifoarme fisuele taal, it fergrutsjen fan de snelheid fan yndieling en ûntwikkeling, en it ferbetterjen fan de kwaliteit fan it produkt yn 't algemien, wie it essinsjeel om it ûntwerp safolle mooglik te ferienigjen. Dit is nedich sadat de ûntwikkeling fan funksjonaliteit tagelyk mooglik wurdt op al ús platfoarms: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - sûnder elk fan har apart te wurkjen. En wy diene it!

Untwerp → gegevens

Doe't de fûnemintele ôfspraken tusken de produkt- en ûntwikkelingsôfdielingen waarden berikt, sieten wy om in technologystapel te selektearjen en de details fan it heule proses út te wurkjen - fan layout oant frijlitting. Om it proses fan it oerdragen fan it ûntwerp nei ûntwikkeling folslein te automatisearjen, hawwe wy de opsje ûndersocht om komponintparameters direkt te parsearjen fan Sketch-bestannen mei yndielingen. It die bliken dat it finen fan de stikken koade dy't wy nedich wiene en it ekstrahearje fan de parameters dy't wy nedich wiene in komplekse en gefaarlike ûndernimming wie. As earste sille ûntwerpers ekstreem foarsichtich wêze moatte by it neamen fan alle lagen fan 'e boarnekoade, twadde, dit wurket allinich foar de ienfâldichste komponinten, en as tredde, ôfhinklikens fan in oar syn technology en koadestruktuer fan' e orizjinele Sketch-yndieling bringt de takomst fan 'e heule yn gefaar projekt. Wy hawwe besletten om automatisearring yn dit gebiet te ferlitten. Dit is hoe't de earste persoan ferskynde yn it ûntwerpsysteemteam, wêrfan de ynfier is ûntwerplayouts, en de útfier is gegevens dy't alle parameters fan 'e komponinten beskriuwe en hiërargysk oardere neffens de atomyske ûntwerpmetodology.

It iennichste ding dat noch te dwaan wie wie wêr en hoe de gegevens op te slaan, hoe't se oerdroegen wurde oan ûntwikkeling en hoe't se yn ûntwikkeling kinne ynterpretearje op alle platfoarms dy't wy stypje. De jûn wie net langer lúster... It resultaat fan reguliere gearkomsten fan de wurkgroep besteande út ûntwerpers en teamleaders fan elk platfoarm wie de oerienkomst oer it folgjende.

Wy parse de fisuele mei de hân yn atomêre eleminten: lettertypen, kleuren, transparânsje, ynspringen, rûningen, ikoanen, ôfbyldings en durations foar animaasjes. En wy sammelje fan dizze knoppen, yngongen, karfakjes, bankkaartwidgets, ensfh. Wy jouwe net-semantyske nammen oan de stilen fan ien fan 'e nivo's, útsein ikoanen, bygelyks nammen fan stêden, nammen fan nimfen, Pokemon, auto merken ... D'r is mar ien betingst - de list moat net earder wurde útput, hoe't de stilen einigje - show moat gean! Jo moatte net mei semantyk meidwaan, sadat jo bygelyks gjin middelste knop hoege te foegjen tusken "lyts" en "medium".

Visuele taal

Untwikkelders waarden oerlitten om nei te tinken oer hoe't jo gegevens opslaan en oerdrage op in manier dy't past by alle platfoarms, en ûntwerp moast ynterface-eleminten ûntwerpe dy't goed koene sjen en effektyf wurkje oer de heule float fan stipe apparaten.

Earder wiene wy ​​​​al slagge om de measte ûntwerpeleminten te "testen" yn in applikaasje foar Windows 10, dy't op dat stuit in nij platfoarm foar ús wie, dat is, it fereasket rendering en ûntwikkeling "fanôf it begjin." Troch it te tekenjen, koene wy ​​de measte komponinten tariede en testen en begripe hokker fan har soene wurde opnommen yn it takomstige Eevee-ûntwerpsysteem. Sûnder sa'n sânbak koe sa'n ûnderfining allinich krigen wurde troch in grut oantal iteraasjes op al wurkjende platfoarms, en dit soe mear as in jier duorje.

It op 'e nij brûke fan deselde komponinten op ferskate platfoarms fermindert it oantal yndielingen en de array fan gegevens fan it ûntwerpsysteem signifikant, sadat it ûntwerp noch ien probleem moast oplosse, earder net beskreaun yn 'e praktiken fan produktûntwerp en -ûntwikkeling - hoe, bygelyks, kin in knop foar tillefoans en tablets opnij brûkt wurde op tv's? En wat moatte wy dwaan mei de grutte fan lettertypen en eleminten op sokke ferskillende platfoarms?

Fansels wie it nedich om in cross-platform modulêr raster te ûntwerpen dat de tekst- en elemintgrutte soe ynstelle dy't wy nedich wiene foar elk spesifyk platfoarm. As útgongspunt foar it raster hawwe wy de grutte en it oantal filmposters keazen dat wy op in bepaald skerm sjen wolle en op grûn dêrfan hawwe wy in regel formulearre foar it bouwen fan rasterkolommen, mits de breedte fan ien kolom gelyk is nei de breedte fan de poster.

No moatte wy alle grutte skermen nei deselde yndielingsgrutte bringe en se passe yn in mienskiplik raster. Apple TV en Roku binne ûntwurpen yn in grutte fan 1920x1080, Android TV - 960x540, Smart TV's, ôfhinklik fan de ferkeaper, binne itselde, mar soms 1280x720. As de app wurdt werjûn en werjûn op Full HD skermen, wurdt 960 fermannichfâldige mei 2, 1280 wurdt fermannichfâldige mei 1,33, en 1920 wurdt útfierd lykas is.

Troch saaie details oer te slaan, kamen wy ta de konklúzje dat yn 't algemien alle skermen, ynklusyf televyzjeskermen, yn termen fan eleminten en har maten, wurde bedutsen troch ien ûntwerpyndieling, en alle televyzjeskermen binne in spesjaal gefal fan it algemiene cross-platform raster, en bestiet út fiif of seis kolommen, lykas in gemiddelde tablet of buroblêd. Wa is ynteressearre yn details, gean yn 'e kommentaren.

Single UI foar alle platfoarms

No, om in nije funksje te tekenjen, hoege wy gjin layouts foar elk platfoarm te tekenjen, plus oanpassingsopsjes foar elk fan har. It is genôch om ien yndieling en har oanpassingsfermogen te sjen foar alle platfoarms en apparaten fan elke breedte: tillefoans - 320-599, al it oare - 600-1280.

Data → ûntwikkeling

Fansels, safolle as wy in folslein unifoarm ûntwerp wolle berikke, hat elk platfoarm syn eigen unike funksjes. Sels hoewol sawol it web as Smart TV de ReactJS + TypeScript-stapel brûke, rint de Smart TV-app op legacy WebKit- en Presto-kliïnten en kin dêrom stilen net diele mei it web. En e-nijsbrieven binne folslein twongen om te wurkjen mei tabellayout. Tagelyk brûkt gjin fan 'e net-html-platfoarms of is fan plan React Native of ien fan syn analogen te brûken, eangst foar degradaasje fan prestaasjes, om't wy tefolle oanpaste yndielingen hawwe, kolleksjes mei komplekse updatelogika, ôfbyldings en fideo's. Dêrom is it mienskiplike skema fan it leverjen fan klearmakke CSS-stilen as React-komponinten net geskikt foar ús. Dêrom besleaten wy gegevens oer te stjoeren yn JSON-formaat, en beskriuwe de wearden yn in abstrakte deklarative foarm.

Eigendom dus rounding: 8 Windows 10 app konvertearret nei CornerRadius="8", reach - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Besit offsetTop: 12 deselde web client yn ferskillende gefallen kin ynterpretearje as top, margin-top, padding-top of transform

Declarativeness fan 'e beskriuwing hâldt ek yn dat as it platfoarm technysk gjin eigendom of syn wearde kin brûke, it kin negearje. Wat terminology oanbelanget, hawwe wy in soarte fan Esperanto-taal makke: guon binne nommen fan Android, guon fan SVG, guon fan CSS.

As jo ​​op in bepaald platfoarm eleminten oars moatte werjaan, hawwe wy de mooglikheid ymplementearre om de oerienkommende gegevensgeneraasje oer te dragen yn 'e foarm fan in apart JSON-bestân. Bygelyks, de steat "yn fokus" foar Smart TV diktearret in feroaring yn 'e posysje fan' e tekst ûnder de poster, wat betsjut dat foar dit platfoarm dizze komponint yn 'e wearde fan' e "ynspring" eigenskip sil befetsje de 8 ynspringingspunten dy't it nedich is. Hoewol dit de ynfrastruktuer fan it ûntwerpsysteem komplisearret, jout it in ekstra graad fan frijheid, wêrtroch't wy de kâns hawwe om de fisuele "ûngelikens" fan 'e platfoarms sels te behearjen, en net gizele te wêzen foar de arsjitektuer dy't wy makke hawwe.

Piktogrammen

Ikonografy yn in digitaal produkt is altyd in voluminous en net it ienfâldichste subprojekt, dat faaks in aparte ûntwerper fereasket. D'r binne altyd in protte glyphs, elk fan har hat ferskate maten en kleuren, en platfoarms hawwe se normaal nedich yn ferskate formaten. Yn it algemien wie der gjin reden om dit alles net yn it ûntwerpsysteem te setten.

Glyfen wurde laden yn SVG-fektorformaat, en kleurwearden wurde automatysk ferfongen troch fariabelen. Klantapplikaasjes kinne se klear foar gebrûk ûntfange - yn elke opmaak en kleur.

Foarbyld

Boppe de JSON-gegevens hawwe wy in ark skreaun foar it besjen fan komponinten - in JS-applikaasje dy't JSON-gegevens op 'e flecht trochjaan troch syn markup- en stylgenerators, en ferskate farianten fan elke komponint yn 'e browser toant. Yn essinsje is preview krekt deselde klant as platfoarmapplikaasjes en wurket mei deselde gegevens.

De maklikste manier om te begripen hoe't in bepaalde komponint wurket is troch ynteraksje mei it. Dêrom hawwe wy gjin ark brûkt lykas Storybook, mar hawwe wy in ynteraktyf foarbyld makke - jo kinne oanreitsje, oanwize, klikke ... by it útfieren fan it.

Dokumintaasje

Op grûn fan de gegevens levere oan de platfoarms yn 'e foarm fan JSON, wurdt dokumintaasje foar de komponinten automatysk oanmakke. In list mei eigenskippen en mooglike soarten wearden yn elk fan harren wurde beskreaun. Nei auto-generaasje kin de ynformaasje mei de hân ferdúdlik wurde en kin in tekstbeskriuwing tafoege wurde. De foarbyld en dokumintaasje wurde krúsferwiisd nei elkoar op it nivo fan elke komponint, en alle ynformaasje opnommen yn 'e dokumintaasje is beskikber foar ûntwikkelders yn' e foarm fan ekstra JSON-bestannen.

Deprecator

In oare needsaak wie de mooglikheid om besteande komponinten oer de tiid te ferfangen en te aktualisearjen. It ûntwerpsysteem hat leard om ûntwikkelders te fertellen hokker eigenskippen of sels folsleine komponinten net kinne wurde brûkt en ferwiderje se sa gau as se net mear wurde brûkt op alle platfoarms. D'r is noch in protte "manuele" arbeid yn dit proses, mar wy stean net stil.

Client ûntwikkeling

Sûnder mis wie it meast komplekse poadium de ynterpretaasje fan ûntwerpsysteemgegevens yn 'e koade fan alle platfoarms dy't wy stypje. As bygelyks modulêre rasters op it web net wat nijs binne, dan hawwe ûntwikkelders fan native mobile applikaasjes foar iOS en Android hurd wurke foardat se útfûnen hoe't se dermei libje kinne.

Om iOS-applikaasjeskermen yn te setten, brûke wy twa basismeganismen levere troch iviUIKit: fergese yndieling fan eleminten en yndieling fan kolleksjes fan eleminten. Wy brûke VIPER, en alle ynteraksje mei iviUIKit is konsintrearre yn View, en de measte ynteraksje mei Apple UIKit is konsintrearre yn iviUIKit. De maten en arranzjeminten fan eleminten wurde spesifisearre yn termen fan kolommen en syntaktyske struktueren dy't wurkje boppe op 'e native iOS SDK-beheiningen, wêrtroch't se praktysk binne. Dit ferienfâldige foaral ús libben by it wurkjen mei UICollectionView. Wy hawwe ferskate oanpaste wrappers skreaun foar yndielingen, ynklusyf frij komplekse. D'r wie in minimum fan kliïntkoade en it waard deklaratyf.

Om stilen te generearjen yn it Android-projekt, brûke wy Gradle, omsette de ûntwerpsysteemgegevens yn stilen yn XML-formaat. Tagelyk hawwe wy ferskate generators fan ferskate nivo's:

• Basis. De gegevens fan primitiven foar generators op heger nivo wurde parseard.
• Helpmiddel. Download ôfbyldings, ikoanen en oare grafiken.
• Komponint. Se binne skreaun foar elke komponint, dy't beskriuwt hokker eigenskippen en hoe't se oersette yn stilen.

Applikaasje releases

Nei't ûntwerpers in nije komponint hawwe tekene of in besteande ien opnij ûntwurpen, wurde dizze wizigingen yn it ûntwerpsysteem ynfierd. De ûntwikkelders fan elk platfoarm fine har koade-generaasje fine om de wizigingen te stypjen. Hjirnei kin it brûkt wurde yn 'e ymplemintaasje fan nije funksjonaliteit wêr't dizze komponint nedich is. Sa komt ynteraksje mei it ûntwerpsysteem net yn echte tiid foar, mar allinich op it momint fan gearstalling fan nije releases. Dizze oanpak soarget ek foar bettere kontrôle oer it gegevensferfierproses en soarget foar koadefunksjonaliteit yn kliïntûntwikkelingsprojekten.

Resultaten

It is in jier lyn dat it ûntwerpsysteem diel waard fan 'e ynfrastruktuer dy't de ûntwikkeling fan' e online bioskoop Ivy stipet, en wy kinne al wat konklúzjes lûke:

• Dit is in grut en kompleks projekt dat konstante tawijde boarnen fereasket.
• Dit liet ús ús eigen unike cross-platform fisuele taal meitsje dy't foldocht oan de doelstellingen fan 'e online fideotsjinst.
• Wy hawwe gjin visueel en funksjoneel efterlizzende platfoarms mear.

Foarbyld fan Ivy-ûntwerpsysteemkomponinten - design.ivi.ru

Boarne: www.habr.com