O UI-kit i system ddylunio

Profiad sinema ar-lein Ivy

Pan wnaethom feddwl am y tro cyntaf ar ddechrau 2017 am greu ein system gyflenwi dylunio-i-god ein hunain, roedd llawer eisoes yn siarad amdano ac roedd rhai hyd yn oed yn ei wneud. Fodd bynnag, hyd heddiw ychydig a wyddys am y profiad o adeiladu systemau dylunio traws-lwyfan, ac ni fu unrhyw ryseitiau clir a phrofedig yn disgrifio technolegau a dulliau ar gyfer trawsnewid y broses o weithredu'r dyluniad yn gynnyrch sydd eisoes yn gweithio. Ac wrth “gydrannau yn y cod” maent yn aml yn golygu pethau gwahanol iawn.

O UI-kit i system ddylunio
Yn y cyfamser, dyblodd y cwmni ei staff flwyddyn ar ôl blwyddyn - roedd angen graddio'r adran ddylunio a gwneud y gorau o'r prosesau o greu a throsglwyddo cynlluniau i'w datblygu. Rydyn ni'n lluosi hyn i gyd â'r “sŵ” o lwyfannau y mae angen eu cefnogi, a chawn semblance o pandemoniwm Babylonaidd, nad yw'n gallu ei “wneud fel arfer” a chynhyrchu incwm. Roedd datblygiad platfformau yn aml yn mynd rhagddo ochr yn ochr, a gellid rhyddhau'r un swyddogaeth ar wahanol lwyfannau gydag oedi o sawl mis.

O UI-kit i system ddylunio
Setiau cynllun ar wahân ar gyfer pob platfform

Yn draddodiadol, fe wnaethom ddechrau gyda phroblemau y byddai system ddylunio yn helpu i'w datrys a llunio gofynion ar gyfer ei dyluniad. Yn ogystal â chreu iaith weledol unedig, cynyddu cyflymder gosodiad a datblygiad, a gwella ansawdd y cynnyrch yn gyffredinol, roedd yn hanfodol uno'r dyluniad cymaint â phosibl. Mae hyn yn angenrheidiol fel bod datblygiad ymarferoldeb yn dod yn bosibl ar ein holl lwyfannau ar yr un pryd: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - heb weithio ar bob un ohonynt ar wahân. Ac fe wnaethom ni!

Dyluniad → data

Pan gyrhaeddwyd y cytundebau sylfaenol rhwng yr adrannau cynnyrch a datblygu, eisteddasom i lawr i ddewis pentwr technoleg a gweithio allan fanylion y broses gyfan - o'r gosodiad i'r rhyddhau. Er mwyn awtomeiddio'r broses o drosglwyddo'r dyluniad i ddatblygiad yn llawn, gwnaethom archwilio'r opsiwn o ddosrannu paramedrau cydran yn uniongyrchol o ffeiliau Braslun gyda chynlluniau. Daeth i'r amlwg bod dod o hyd i'r darnau o god yr oedd eu hangen arnom a thynnu'r paramedrau yr oedd eu hangen arnom yn dasg gymhleth a pheryglus. Yn gyntaf, bydd yn rhaid i ddylunwyr fod yn hynod ofalus wrth enwi pob haen o'r cod ffynhonnell, yn ail, dim ond ar gyfer y cydrannau symlaf y mae hyn yn gweithio, ac yn drydydd, mae dibyniaeth ar dechnoleg rhywun arall a strwythur cod y cynllun Braslun gwreiddiol yn peryglu dyfodol y cyfan. prosiect. Fe wnaethom benderfynu rhoi'r gorau i awtomeiddio yn y maes hwn. Dyma sut yr ymddangosodd y person cyntaf yn nhîm y system ddylunio, y mae ei fewnbwn yn gynllun dylunio, a'r allbwn yw data sy'n disgrifio holl baramedrau'r cydrannau ac wedi'u trefnu'n hierarchaidd yn unol â'r fethodoleg dylunio atomig.

Yr unig beth oedd ar ôl i'w wneud oedd ble a sut i storio'r data, sut i'w drosglwyddo i ddatblygiad a sut i'w ddehongli mewn datblygiad ar yr holl lwyfannau rydyn ni'n eu cefnogi. Daeth y noson i ben... Canlyniad cyfarfodydd rheolaidd y gweithgor a oedd yn cynnwys dylunwyr ac arweinwyr tîm o bob platfform oedd y cytundeb ar y canlynol.

Rydym yn dosrannu'r gweledol â llaw yn elfennau atomig: ffontiau, lliwiau, tryloywder, mewnoliadau, talgrynnu, eiconau, lluniau a hyd ar gyfer animeiddiadau. Ac rydym yn casglu o'r botymau hyn, mewnbynnau, blychau ticio, teclynnau cerdyn banc, ac ati Rydym yn aseinio enwau nad ydynt yn semantig i arddulliau unrhyw un o'r lefelau, ac eithrio eiconau, er enghraifft, enwau dinasoedd, enwau nymffau, Pokémon, car brandiau... Dim ond un amod sydd - ni ddylid dihysbyddu'r rhestr o'r blaen , sut mae'r arddulliau'n dod i ben - mae'n rhaid i sioe fynd! Ni ddylech gael eich cario i ffwrdd â semanteg, fel nad oes rhaid i chi ychwanegu botwm canol rhwng “bach” a “canolig,” er enghraifft.

Iaith weledol

Gadawyd datblygwyr i feddwl am sut i storio a throsglwyddo data mewn ffordd a oedd yn addas ar gyfer pob platfform, ac roedd yn rhaid i ddylunio ddylunio elfennau rhyngwyneb a allai edrych yn dda a gweithio'n effeithiol ar draws y fflyd gyfan o ddyfeisiau â chymorth.

Yn flaenorol, roeddem eisoes wedi llwyddo i “brofi” y rhan fwyaf o'r elfennau dylunio mewn cymhwysiad Windows 10, a oedd bryd hynny yn blatfform newydd i ni, hynny yw, roedd angen ei rendro a'i ddatblygu “o'r dechrau.” Trwy ei luniadu, roeddem yn gallu paratoi a phrofi'r rhan fwyaf o'r cydrannau a deall pa rai ohonynt oedd i fod i gael eu cynnwys yn system ddylunio Eevee yn y dyfodol. Heb flwch tywod o'r fath, dim ond trwy nifer fawr o iteriadau ar lwyfannau sydd eisoes yn gweithio y gellid cael profiad o'r fath, a byddai hyn yn cymryd mwy na blwyddyn.

Mae ailddefnyddio'r un cydrannau ar wahanol lwyfannau yn lleihau nifer y cynlluniau a'r amrywiaeth o ddata o'r system ddylunio yn sylweddol, felly roedd yn rhaid i'r dyluniad ddatrys un broblem arall, nas disgrifiwyd yn flaenorol yn arferion dylunio a datblygu cynnyrch - sut, er enghraifft, a ellir ailddefnyddio botwm ar gyfer ffonau a thabledi ar setiau teledu? A beth ddylem ni ei wneud gyda maint ffontiau ac elfennau ar lwyfannau mor wahanol?

Yn amlwg, roedd angen dylunio grid modiwlaidd traws-lwyfan a fyddai'n gosod maint y testun a'r elfennau yr oedd eu hangen arnom ar gyfer pob platfform penodol. Fel man cychwyn ar gyfer y grid, gwnaethom ddewis maint a nifer y posteri ffilm yr ydym am eu gweld ar sgrin benodol ac, yn seiliedig ar hyn, gwnaethom lunio rheol ar gyfer adeiladu colofnau grid, ar yr amod bod lled un golofn yn gyfartal. i led y poster.

O UI-kit i system ddylunio
Nawr mae angen i ni ddod â phob sgrin fawr i'r un maint gosodiad a'u gosod mewn grid cyffredin. Mae Apple TV a Roku wedi'u cynllunio mewn maint o 1920x1080, teledu Android - 960x540, mae setiau teledu clyfar, yn dibynnu ar y gwerthwr, yr un peth, ond weithiau 1280x720. Pan fydd yr ap yn cael ei rendro a'i arddangos ar sgriniau Llawn HD, mae 960 yn cael ei luosi â 2, mae 1280 yn cael ei luosi â 1,33, ac mae 1920 yn allbwn fel y mae.

Gan hepgor manylion diflas, daethom i'r casgliad yn gyffredinol bod pob sgrin, gan gynnwys sgriniau teledu, o ran elfennau a'u maint, wedi'u gorchuddio gan un cynllun dylunio, ac mae pob sgrin deledu yn achos arbennig o'r grid traws-lwyfan cyffredinol, ac yn cynnwys pump neu chwe cholofn, fel tabled neu bwrdd gwaith arferol. Pwy sydd â diddordeb mewn manylion, ewch i'r sylwadau.

O UI-kit i system ddylunio
UI sengl ar gyfer pob platfform

Nawr, i lunio nodwedd newydd, nid oes angen i ni luniadu cynlluniau ar gyfer pob platfform, ynghyd ag opsiynau addasrwydd ar gyfer pob un ohonynt. Mae'n ddigon i ddangos un cynllun a'i allu i addasu ar gyfer pob llwyfan a dyfais o unrhyw led: ffonau - 320-599, popeth arall - 600-1280.

Data → datblygiad

Wrth gwrs, cymaint ag yr hoffem gyflawni dyluniad cwbl unedig, mae gan bob platfform ei nodweddion unigryw ei hun. Er bod y we a Smart TV yn defnyddio stac ReactJS + TypeScript, mae'r ap Smart TV yn rhedeg ar gleientiaid blaenorol WebKit a Presto ac felly ni all rannu arddulliau gyda'r we. Ac mae cylchlythyrau e-bost yn cael eu gorfodi'n llwyr i weithio gyda chynllun tabl. Ar yr un pryd, nid yw'r un o'r llwyfannau nad ydynt yn rhai html yn defnyddio nac yn bwriadu defnyddio React Native nac unrhyw un o'i analogau, gan ofni dirywiad perfformiad, gan fod gennym ormod o gynlluniau personol, casgliadau gyda rhesymeg diweddaru cymhleth, delweddau a fideos. Felly, nid yw'r cynllun cyffredin o gyflwyno arddulliau CSS parod neu gydrannau React yn addas i ni. Felly, penderfynasom drosglwyddo data ar ffurf JSON, gan ddisgrifio'r gwerthoedd ar ffurf datganiadol haniaethol.

Felly eiddo rounding: 8 Windows 10 app yn trosi i CornerRadius="8", gwe - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Eiddo offsetTop: 12 gall yr un cleient gwe mewn gwahanol achosion ddehongli fel top, margin-top, padding-top neu transform

Mae datganoldeb y disgrifiad hefyd yn awgrymu, os na all y platfform yn dechnegol ddefnyddio eiddo neu ei werth, y gall ei anwybyddu. O ran terminoleg, gwnaethom fath o iaith Esperanto: cymerwyd rhai o Android, rhai o SVG, rhai o CSS.

Os oes angen i chi arddangos elfennau yn wahanol ar lwyfan penodol, rydym wedi gweithredu'r gallu i drosglwyddo'r cynhyrchiad data cyfatebol ar ffurf ffeil JSON ar wahân. Er enghraifft, mae’r cyflwr “mewn ffocws” ar gyfer Teledu Clyfar yn pennu newid yn safle’r testun o dan y poster, sy’n golygu ar gyfer y platfform hwn y bydd y gydran hon yng ngwerth yr eiddo “indent” yn cynnwys yr 8 pwynt mewnoliad sydd eu hangen arno. Er bod hyn yn cymhlethu seilwaith y system ddylunio, mae’n rhoi gradd ychwanegol o ryddid, gan adael inni’r cyfle i reoli “annhebygrwydd” gweledol y llwyfannau ein hunain, a pheidio â bod yn wystl i’r bensaernïaeth a grëwyd gennym.

O UI-kit i system ddylunio

Pictogramau

Eiconograffeg mewn cynnyrch digidol bob amser yn swmpus ac nid yw'r is-brosiect symlaf, yn aml yn gofyn am ddylunydd ar wahân. Mae yna lawer o glyffau bob amser, mae gan bob un ohonyn nhw sawl maint a lliw, ac fel arfer mae eu hangen ar lwyfannau mewn gwahanol fformatau. Yn gyffredinol, nid oedd unrhyw reswm i beidio â rhoi hyn i gyd yn y system ddylunio.

O UI-kit i system ddylunio
Mae glyffs yn cael eu llwytho mewn fformat fector SVG, ac mae gwerthoedd lliw yn cael eu disodli'n awtomatig â newidynnau. Gall ceisiadau cleient eu derbyn yn barod i'w defnyddio - mewn unrhyw fformat a lliw.

rhagolwg

Ar ben y data JSON, fe wnaethom ysgrifennu offeryn ar gyfer rhagolwg cydrannau - cymhwysiad JS sy'n pasio data JSON ar y hedfan trwy ei generaduron marcio ac arddull, ac yn arddangos amrywiadau amrywiol o bob cydran yn y porwr. Yn y bôn, mae rhagolwg yn union yr un cleient â chymwysiadau platfform ac mae'n gweithio gyda'r un data.

Y ffordd hawsaf o ddeall sut mae cydran benodol yn gweithio yw trwy ryngweithio ag ef. Felly, ni wnaethom ddefnyddio offer fel Storybook, ond gwnaethom ragolwg rhyngweithiol - gallwch gyffwrdd, pwyntio, clicio... Wrth ychwanegu cydran newydd i'r system ddylunio, mae'n ymddangos yn y rhagolwg fel bod gan lwyfannau rywbeth i ganolbwyntio arno pryd ei weithredu.

Cofnodion

Yn seiliedig ar y data a ddarparwyd i'r llwyfannau ar ffurf JSON, mae dogfennaeth ar gyfer y cydrannau'n cael ei chynhyrchu'n awtomatig. Disgrifir rhestr o briodweddau a mathau posibl o werthoedd ym mhob un ohonynt. Ar ôl cynhyrchu ceir, gellir egluro'r wybodaeth â llaw a gellir ychwanegu disgrifiad testun. Mae'r rhagolwg a'r ddogfennaeth yn cael eu croesgyfeirio â'i gilydd ar lefel pob cydran, ac mae'r holl wybodaeth sydd wedi'i chynnwys yn y ddogfennaeth ar gael i ddatblygwyr ar ffurf ffeiliau JSON ychwanegol.

Deprecator

Anghenraid arall oedd y gallu i ddisodli a diweddaru cydrannau presennol dros amser. Mae'r system ddylunio wedi dysgu dweud wrth ddatblygwyr pa eiddo neu hyd yn oed gydrannau cyfan na ellir eu defnyddio a chael gwared arnynt cyn gynted ag na chânt eu defnyddio mwyach ar bob platfform. Mae llawer o lafur “â llaw” yn y broses hon o hyd, ond nid ydym yn sefyll yn ein hunfan.

Datblygiad cleient

Yn ddi-os, y cam mwyaf cymhleth oedd dehongli data system ddylunio yng nghod pob platfform yr ydym yn ei gefnogi. Er enghraifft, os nad yw gridiau modiwlaidd ar y we yn rhywbeth newydd, yna bu datblygwyr cymwysiadau symudol brodorol ar gyfer iOS ac Android yn gweithio'n galed cyn iddynt ddarganfod sut i fyw ag ef.

I osod sgriniau cymhwysiad iOS, rydym yn defnyddio dau fecanwaith sylfaenol a ddarperir gan iviUIKit: cynllun am ddim o elfennau a chynllun casgliadau o elfennau. Rydym yn defnyddio VIPER, ac mae'r holl ryngweithio ag iviUIKit wedi'i ganoli yn View, ac mae'r rhan fwyaf o ryngweithio ag Apple UIKit wedi'i ganoli yn iviUIKit. Mae meintiau a threfniant elfennau wedi'u pennu yn nhermau colofnau a strwythurau cystrawennol sy'n gweithio ar ben y cyfyngiadau SDK iOS brodorol, gan eu gwneud yn fwy ymarferol. Fe wnaeth hyn symleiddio ein bywyd yn arbennig wrth weithio gydag UICollectionView. Rydym wedi ysgrifennu sawl papur lapio arferol ar gyfer cynlluniau, gan gynnwys rhai eithaf cymhleth. Roedd isafswm o god cleient a daeth yn ddatganiadol.

I gynhyrchu arddulliau yn y prosiect Android, rydym yn defnyddio Gradle, gan droi data'r system ddylunio yn arddulliau ar ffurf XML. Ar yr un pryd, mae gennym sawl generadur o wahanol lefelau:

  • Syml. Mae data cyntefig ar gyfer generaduron lefel uwch yn cael ei ddosrannu.
  • Adnodd. Dadlwythwch luniau, eiconau a graffeg arall.
  • Cydran. Cânt eu hysgrifennu ar gyfer pob cydran, sy'n disgrifio pa briodweddau a sut i'w trosi'n arddulliau.

Datganiadau cais

Ar ôl i ddylunwyr dynnu llun cydran newydd neu ailgynllunio un sy'n bodoli eisoes, caiff y newidiadau hyn eu bwydo i'r system ddylunio. Mae datblygwyr pob platfform yn mireinio eu cynhyrchu cod i gefnogi'r newidiadau. Ar ôl hyn, gellir ei ddefnyddio wrth weithredu swyddogaeth newydd lle mae angen y gydran hon. Felly, nid yw rhyngweithio â'r system ddylunio yn digwydd mewn amser real, ond dim ond ar adeg cydosod datganiadau newydd. Mae'r dull hwn hefyd yn caniatáu gwell rheolaeth dros y broses trosglwyddo data ac yn sicrhau ymarferoldeb cod mewn prosiectau datblygu cleientiaid.

Canlyniadau

Mae blwyddyn wedi mynd heibio ers i’r system ddylunio ddod yn rhan o’r seilwaith sy’n cefnogi datblygiad sinema ar-lein Ivy, a gallwn ddod i rai casgliadau eisoes:

  • Mae hwn yn brosiect mawr a chymhleth sy'n gofyn am adnoddau pwrpasol cyson.
  • Caniataodd hyn i ni greu ein hiaith weledol traws-lwyfan unigryw ein hunain sy’n bodloni amcanion y gwasanaeth fideo ar-lein.
  • Nid oes gennym lwyfannau ar ei hôl hi mwyach yn weledol ac yn swyddogaethol.

Rhagolwg o gydrannau system dylunio Ivy - dylunio.ivi.ru

Ffynhonnell: hab.com

Ychwanegu sylw