Mula sa UI-kit hanggang sa sistema ng disenyo

Ivy online cinema karanasan

Noong simula ng 2017 una naming naisipang gumawa ng sarili naming design-to-code delivery system, marami na ang nag-uusap tungkol dito at may ilan pa ngang gumagawa nito. Gayunpaman, hanggang ngayon ay kakaunti ang nalalaman tungkol sa karanasan ng pagbuo ng mga cross-platform na sistema ng disenyo, at walang malinaw at napatunayang mga recipe na naglalarawan ng mga teknolohiya at pamamaraan para sa naturang pagbabago ng proseso ng pagpapatupad ng disenyo sa isang gumagana nang produkto. At sa pamamagitan ng "mga bahagi sa code" madalas silang nangangahulugang ibang mga bagay.

Samantala, dinoble ng kumpanya ang mga tauhan nito taon-taon - kinakailangang sukatin ang departamento ng disenyo at i-optimize ang mga proseso ng paglikha at paglilipat ng mga layout para sa pag-unlad. Pinaparami namin ang lahat ng ito sa "zoo" ng mga platform na kailangang suportahan, at nakakakuha kami ng pagkakahawig ng Babylonian pandemonium, na hindi lang "gawin ito nang normal" at makabuo ng kita. Ang pagbuo ng mga platform ay madalas na nagpapatuloy nang magkatulad, at ang parehong pag-andar ay maaaring ilabas sa iba't ibang mga platform na may lag ng ilang buwan.


Paghiwalayin ang mga set ng layout para sa bawat platform

Ayon sa kaugalian, nagsimula kami sa mga problema na makakatulong ang isang sistema ng disenyo sa paglutas at pagbalangkas ng mga kinakailangan para sa disenyo nito. Bilang karagdagan sa paglikha ng isang pinag-isang visual na wika, pagtaas ng bilis ng layout at pag-unlad, at pagpapabuti ng kalidad ng produkto sa pangkalahatan, napakahalaga na pag-isahin ang disenyo hangga't maaari. Ito ay kinakailangan upang ang pagbuo ng functionality ay maging posible sa lahat ng aming mga platform nang sabay-sabay: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - nang hindi gumagana sa bawat isa sa kanila nang hiwalay . At ginawa namin ito!

Disenyo → data

Nang naabot ang mga pangunahing kasunduan sa pagitan ng mga departamento ng produkto at pag-unlad, umupo kami upang pumili ng stack ng teknolohiya at ayusin ang mga detalye ng buong proseso - mula sa layout hanggang sa paglabas. Upang ganap na i-automate ang proseso ng paglilipat ng disenyo sa pagbuo, ginalugad namin ang opsyon ng pag-parse ng mga parameter ng bahagi nang direkta mula sa mga Sketch file na may mga layout. Ito ay lumabas na ang paghahanap ng mga piraso ng code na kailangan namin at pagkuha ng mga parameter na kailangan namin ay isang kumplikado at mapanganib na gawain. Una, ang mga taga-disenyo ay kailangang maging lubhang maingat sa pagbibigay ng pangalan sa lahat ng mga layer ng source code, pangalawa, ito ay gumagana lamang para sa pinakasimpleng mga bahagi, at pangatlo, ang pag-asa sa teknolohiya ng ibang tao at istraktura ng code ng orihinal na layout ng Sketch ay nanganganib sa hinaharap ng buong proyekto. Nagpasya kaming iwanan ang automation sa lugar na ito. Ito ay kung paano lumitaw ang unang tao sa koponan ng sistema ng disenyo, na ang input ay mga layout ng disenyo, at ang output ay ang data na naglalarawan sa lahat ng mga parameter ng mga bahagi at ayon sa hierarchical na pagkakasunud-sunod ayon sa pamamaraan ng atomic na disenyo.

Ang tanging bagay na natitira upang gawin ay kung saan at kung paano mag-imbak ng data, kung paano ilipat ito sa pag-unlad at kung paano i-interpret ito sa pag-unlad sa lahat ng mga platform na sinusuportahan namin. Ang gabi ay tumigil sa pagiging matamlay... Ang resulta ng mga regular na pagpupulong ng working group na binubuo ng mga designer at team leads mula sa bawat platform ay ang kasunduan sa mga sumusunod.

Manu-mano naming na-parse ang visual sa mga atomic na elemento: mga font, kulay, transparency, indent, roundings, icon, larawan at tagal para sa mga animation. At kinokolekta namin mula sa mga pindutan, input, checkbox, widget ng bank card, atbp. Nagtatalaga kami ng mga non-semantic na pangalan sa mga istilo ng alinman sa mga antas, maliban sa mga icon, halimbawa, mga pangalan ng mga lungsod, pangalan ng mga nymph, Pokemon, kotse brands... Isa lang ang kundisyon - ang listahan ay hindi dapat maubos bago , kung paano magtatapos ang mga istilo - ang palabas ay dapat pumunta! Hindi ka dapat madala sa semantics, para hindi mo na kailangang magdagdag ng gitnang button sa pagitan ng "maliit" at "medium," halimbawa.

Visual na wika

Hinayaan ang mga developer na mag-isip tungkol sa kung paano mag-imbak at maglipat ng data sa paraang angkop sa lahat ng platform, at ang disenyo ay kailangang magdisenyo ng mga elemento ng interface na maaaring magmukhang maganda at epektibong gumana sa buong fleet ng mga sinusuportahang device.

Noong nakaraan, nagawa na naming "subukan" ang karamihan sa mga elemento ng disenyo sa isang application para sa Windows 10, na sa oras na iyon ay isang bagong platform para sa amin, iyon ay, nangangailangan ito ng pag-render at pag-unlad "mula sa simula." Sa pamamagitan ng pagguhit nito, naihanda at nasubukan namin ang karamihan sa mga bahagi at nauunawaan kung alin sa mga ito ang dapat isama sa hinaharap na sistema ng disenyo ng Eevee. Kung walang ganoong sandbox, ang ganitong karanasan ay makukuha lamang sa pamamagitan ng malaking bilang ng mga pag-ulit sa gumagana nang mga platform, at aabutin ito ng higit sa isang taon.

Ang muling paggamit ng parehong mga bahagi sa iba't ibang mga platform ay makabuluhang binabawasan ang bilang ng mga layout at ang hanay ng data ng sistema ng disenyo, kaya ang disenyo ay kailangang lutasin ang isa pang problema, na dati ay hindi inilarawan sa mga kasanayan sa disenyo at pag-unlad ng produkto - kung paano, halimbawa, maaari bang magamit muli ang isang button para sa mga telepono at tablet sa mga TV? At ano ang dapat nating gawin sa mga laki ng mga font at elemento sa iba't ibang mga platform?

Malinaw, kinakailangan na magdisenyo ng cross-platform modular grid na magtatakda ng mga laki ng teksto at elemento na kailangan namin para sa bawat partikular na platform. Bilang panimulang punto para sa grid, pinili namin ang laki at bilang ng mga poster ng pelikula na gusto naming makita sa isang partikular na screen at, batay dito, bumuo kami ng panuntunan para sa pagbuo ng mga grid column, sa kondisyon na ang lapad ng isang column ay pantay. sa lapad ng poster.

Ngayon ay kailangan nating dalhin ang lahat ng malalaking screen sa parehong laki ng layout at magkasya ang mga ito sa isang karaniwang grid. Ang Apple TV at Roku ay idinisenyo sa laki na 1920x1080, Android TV - 960x540, Ang mga Smart TV, depende sa vendor, ay pareho, ngunit minsan ay 1280x720. Kapag ang app ay na-render at ipinakita sa mga Full HD na screen, ang 960 ay minu-multiply sa 2, ang 1280 ay minu-multiply sa 1,33, at ang 1920 ay ang output.

Nilaktawan ang mga nakakainip na detalye, napagpasyahan namin na sa pangkalahatan ang lahat ng mga screen, kabilang ang mga screen ng telebisyon, sa mga tuntunin ng mga elemento at ang kanilang mga sukat, ay sakop ng isang layout ng disenyo, at lahat ng mga screen ng telebisyon ay isang espesyal na kaso ng pangkalahatang cross-platform grid, at binubuo ng lima o anim na column, tulad ng isang average na tablet o desktop. Sino ang interesado sa mga detalye, pumunta sa mga komento.

Isang UI para sa lahat ng platform

Ngayon, para gumuhit ng bagong feature, hindi namin kailangang gumuhit ng mga layout para sa bawat platform, kasama ang mga opsyon sa adaptability para sa bawat isa sa kanila. Ito ay sapat na upang ipakita ang isang layout at ang kakayahang umangkop nito para sa lahat ng mga platform at device ng anumang lapad: mga telepono - 320-599, lahat ng iba pa - 600-1280.

Data → pag-unlad

Siyempre, hangga't gusto nating makamit ang isang ganap na pinag-isang disenyo, ang bawat platform ay may sariling natatanging tampok. Kahit na parehong ginagamit ng web at Smart TV ang ReactJS + TypeScript stack, tumatakbo ang Smart TV app sa mga legacy na kliyente ng WebKit at Presto at samakatuwid ay hindi makakapagbahagi ng mga istilo sa web. At ang mga newsletter ng email ay ganap na napipilitang gumana sa layout ng tabular. Kasabay nito, wala sa mga non-html na platform ang gumagamit o nagpaplanong gumamit ng React Native o alinman sa mga analogue nito, na natatakot sa pagkasira ng performance, dahil marami kaming custom na layout, mga koleksyon na may kumplikadong logic ng update, mga larawan at video. Samakatuwid, ang karaniwang pamamaraan ng paghahatid ng mga yari na istilo ng CSS o mga bahagi ng React ay hindi angkop para sa amin. Samakatuwid, nagpasya kaming magpadala ng data sa format na JSON, na naglalarawan sa mga halaga sa isang abstract na deklaratibong anyo.

Kaya ari-arian rounding: 8 Nagko-convert ang Windows 10 app sa CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Ari-arian offsetTop: 12 ang parehong web client sa iba't ibang mga kaso ay maaaring bigyang-kahulugan bilang top, margin-top, padding-top o transform

Ipinahihiwatig din ng pagiging deklarasyon ng paglalarawan na kung teknikal na hindi magagamit ng platform ang isang property o ang halaga nito, maaari itong balewalain. Sa mga tuntunin ng terminolohiya, gumawa kami ng isang uri ng wikang Esperanto: ang ilan ay kinuha mula sa Android, ang ilan ay mula sa SVG, ang ilan ay mula sa CSS.

Kung sa isang partikular na platform kailangan mong magpakita ng mga elemento sa ibang paraan, ipinatupad namin ang kakayahang ilipat ang kaukulang pagbuo ng data sa anyo ng isang hiwalay na JSON file. Halimbawa, ang "in focus" na estado para sa Smart TV ay nagdidikta ng pagbabago sa posisyon ng text sa ilalim ng poster, na nangangahulugang para sa platform na ito ang bahaging ito sa halaga ng property na "indent" ay maglalaman ng 8 indentation point na kailangan nito. Bagama't pinapalubha nito ang imprastraktura ng sistema ng disenyo, nagbibigay ito ng karagdagang antas ng kalayaan, na nag-iiwan sa amin ng pagkakataong pamahalaan ang visual na "pagkakaiba" ng mga platform mismo, at hindi maging hostage sa arkitektura na aming ginawa.

Pictograms

Ang iconography sa isang digital na produkto ay palaging isang malaking-malaki at hindi ang pinakasimpleng subproject, kadalasang nangangailangan ng hiwalay na designer. Palaging maraming mga glyph, bawat isa sa kanila ay may iba't ibang laki at kulay, at karaniwang kailangan ng mga platform ang mga ito sa iba't ibang format. Sa pangkalahatan, walang dahilan upang hindi ilagay ang lahat ng ito sa sistema ng disenyo.

Ang mga glyph ay nilo-load sa SVG na vector format, at ang mga halaga ng kulay ay awtomatikong pinapalitan ng mga variable. Maaaring matanggap ng mga application ng kliyente ang mga ito na handa nang gamitin - sa anumang format at kulay.

Silipin

Sa itaas ng data ng JSON, nagsulat kami ng tool para sa pag-preview ng mga bahagi - isang JS application na nagpapasa ng data ng JSON nang mabilis sa pamamagitan ng mga markup at style generator nito, at nagpapakita ng iba't ibang variation ng bawat component sa browser. Sa pangkalahatan, ang preview ay eksaktong kapareho ng kliyente ng mga application sa platform at gumagana sa parehong data.

Ang pinakamadaling paraan upang maunawaan kung paano gumagana ang isang partikular na bahagi ay sa pamamagitan ng pakikipag-ugnayan dito. Samakatuwid, hindi kami gumamit ng mga tool tulad ng Storybook, ngunit gumawa ng isang interactive na preview - maaari mong hawakan, ituro, i-click... Kapag nagdaragdag ng bagong bahagi sa sistema ng disenyo, ito ay lilitaw sa preview upang ang mga platform ay may pagtuunan ng pansin kapag pagpapatupad nito.

Records

Batay sa data na ibinigay sa mga platform sa anyo ng JSON, awtomatikong nabubuo ang dokumentasyon para sa mga bahagi. Ang isang listahan ng mga katangian at posibleng mga uri ng mga halaga sa bawat isa sa kanila ay inilarawan. Pagkatapos ng awtomatikong pagbuo, ang impormasyon ay maaaring linawin nang manu-mano at maaaring magdagdag ng isang paglalarawan ng teksto. Ang preview at dokumentasyon ay cross-reference sa bawat isa sa antas ng bawat bahagi, at lahat ng impormasyong kasama sa dokumentasyon ay available sa mga developer sa anyo ng mga karagdagang JSON file.

Deprecator

Ang isa pang pangangailangan ay ang kakayahang palitan at i-update ang mga kasalukuyang bahagi sa paglipas ng panahon. Natutunan ng sistema ng disenyo na sabihin sa mga developer kung aling mga pag-aari o kahit na buong bahagi ang hindi maaaring gamitin at alisin ang mga ito sa sandaling hindi na sila magamit sa lahat ng platform. Marami pa ring "manual" na paggawa sa prosesong ito, ngunit hindi tayo nakatayo.

Pag-unlad ng kliyente

Walang alinlangan, ang pinakamasalimuot na yugto ay ang interpretasyon ng data ng sistema ng disenyo sa code ng lahat ng platform na sinusuportahan namin. Kung, halimbawa, ang mga modular grids sa web ay hindi isang bagay na bago, kung gayon ang mga developer ng mga katutubong mobile application para sa iOS at Android ay nagsumikap nang husto bago nila naisip kung paano mamuhay dito.

Upang mag-layout ng mga screen ng application ng iOS, gumagamit kami ng dalawang pangunahing mekanismo na ibinigay ng iviUIKit: libreng layout ng mga elemento at layout ng mga koleksyon ng mga elemento. Gumagamit kami ng VIPER, at lahat ng pakikipag-ugnayan sa iviUIKit ay puro sa View, at karamihan sa pakikipag-ugnayan sa Apple UIKit ay puro sa iviUIKit. Ang mga sukat at pagsasaayos ng mga elemento ay tinukoy sa mga tuntunin ng mga column at syntactic na istruktura na gumagana sa itaas ng mga native na hadlang sa iOS SDK, na ginagawang mas praktikal ang mga ito. Lalo nitong pinasimple ang aming buhay kapag nagtatrabaho sa UICollectionView. Sumulat kami ng ilang custom na wrapper para sa mga layout, kabilang ang mga medyo kumplikado. Mayroong isang minimum na code ng kliyente at ito ay naging deklaratibo.

Upang bumuo ng mga istilo sa proyekto ng Android, ginagamit namin ang Gradle, na ginagawang mga istilo ang data ng system ng disenyo sa XML na format. Kasabay nito, mayroon kaming ilang mga generator ng iba't ibang antas:

• Batayan. Ang data ng mga primitive para sa mga generator ng mas mataas na antas ay na-parse.
• mapagkukunan. Mag-download ng mga larawan, icon, at iba pang graphics.
• Component. Ang mga ito ay isinulat para sa bawat bahagi, na naglalarawan kung anong mga katangian at kung paano isalin ang mga ito sa mga istilo.

Mga release ng application

Matapos iguhit ng mga designer ang isang bagong bahagi o muling idisenyo ang isang umiiral na, ang mga pagbabagong ito ay ipapakain sa sistema ng disenyo. Inaayos ng mga developer ng bawat platform ang kanilang pagbuo ng code upang suportahan ang mga pagbabago. Pagkatapos nito, maaari itong magamit sa pagpapatupad ng bagong pag-andar kung saan kailangan ang bahaging ito. Kaya, ang pakikipag-ugnayan sa sistema ng disenyo ay hindi nangyayari sa real time, ngunit sa oras lamang ng pag-assemble ng mga bagong release. Ang diskarte na ito ay nagbibigay-daan din para sa mas mahusay na kontrol sa proseso ng paglilipat ng data at tinitiyak ang pagpapagana ng code sa mga proyekto sa pagpapaunlad ng kliyente.

Mga resulta ng

Isang taon na ang nakalipas mula nang ang sistema ng disenyo ay naging bahagi ng imprastraktura na sumusuporta sa pagbuo ng Ivy online cinema, at maaari na tayong gumawa ng ilang konklusyon:

• Ito ay isang malaki at kumplikadong proyekto na nangangailangan ng patuloy na nakatuong mapagkukunan.
• Nagbigay-daan ito sa amin na lumikha ng sarili naming natatanging cross-platform na visual na wika na nakakatugon sa mga layunin ng online na serbisyo ng video.
• Wala na kaming visually at functional na lagging na mga platform.

Preview ng mga bahagi ng sistema ng disenyo ng Ivy - disenyo.ivi.ru

Pinagmulan: www.habr.com