Alates kasutajaliidese komplektist kuni disainisüsteemini

Ivy veebikino kogemus

Kui 2017. aasta alguses mõtlesime esimest korda oma design-to-code edastamissüsteemi loomisele, siis paljud rääkisid sellest juba ja mõned isegi tegid seda. Kuid tänaseni on platvormideüleste projekteerimissüsteemide ehitamise kogemustest vähe teada ning puuduvad selged ja tõestatud retseptid, mis kirjeldaksid tehnoloogiaid ja meetodeid disaini rakendamise protsessi selliseks muutmiseks juba toimivaks tooteks. Ja "koodi komponentide" all mõeldakse sageli väga erinevaid asju.

Vahepeal kahekordistas ettevõte aasta-aastalt oma personali - oli vaja projekteerimisosakonda skaleerida ning optimeerida paigutuste loomise ja arendamiseks ülekandmise protsesse. Korrutame selle kõik toetamist vajavate platvormide “loomaaiaga” ja saame justkui Babüloonia pandemooniumi, mis lihtsalt ei suuda “seda normaalselt teha” ja tulu teenida. Platvormide arendus kulges sageli paralleelselt ning sama funktsionaalsust sai mitmekuulise viivitusega erinevatele platvormidele välja anda.


Iga platvormi jaoks eraldi paigutuskomplektid

Traditsiooniliselt alustasime probleemidest, mida projekteerimissüsteem aitaks lahendada ja sõnastasime nõuded selle projekteerimisele. Lisaks ühtse visuaalse keele loomisele, küljendamise ja arenduse kiiruse suurendamisele ning toote üldise kvaliteedi parandamisele oli ülioluline disaini võimalikult ühtlustada. See on vajalik selleks, et funktsionaalsuse arendamine oleks võimalik samaaegselt kõigil meie platvormidel: veeb, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - ilma nende kõigi kallal eraldi töötamata. Ja saime hakkama!

Disain → andmed

Kui toote- ja arendusosakondade vahel saavutati põhimõttelised kokkulepped, istusime maha, et valida tehnoloogiapakk ja töötada välja kogu protsessi detailid – küljendusest väljalaskmiseni. Disaini arendusse ülekandmise protsessi täielikuks automatiseerimiseks uurisime võimalust sõeluda komponentide parameetreid otse Sketchi failidest koos paigutustega. Selgus, et vajalike koodijuppide leidmine ja vajalike parameetrite eraldamine oli keeruline ja ohtlik ettevõtmine. Esiteks peavad disainerid olema äärmiselt ettevaatlikud lähtekoodi kõikide kihtide nimetamisel, teiseks töötab see ainult kõige lihtsamate komponentide puhul ja kolmandaks seab sõltuvus kellegi teise tehnoloogiast ja algse Sketchi küljenduse koodistruktuurist ohtu kogu tuleviku. projekt. Otsustasime selles valdkonnas automatiseerimisest loobuda. Nii tekkis projekteerimissüsteemi meeskonda esimene inimene, kelle sisendiks on disainilahendused ning väljundiks kõiki komponentide parameetreid kirjeldavad ja atomaarse projekteerimise metoodika järgi hierarhiliselt järjestatud andmed.

Teha jäi vaid see, kuhu ja kuidas andmeid salvestada, kuidas neid arendusse üle kanda ja kuidas tõlgendada arenduses kõigil meie poolt toetatavatel platvormidel. Õhtu lakkas olema vaikne... Iga platvormi disaineritest ja meeskonnajuhtidest koosneva töörühma regulaarsete koosolekute tulemuseks oli kokkulepe järgmises.

Sõelume visuaali käsitsi aatomielementideks: fondid, värvid, läbipaistvus, taanded, ümardamised, ikoonid, pildid ja animatsioonide kestused. Ja siit kogume nuppe, sisendeid, märkeruutusid, pangakaardi vidinaid jne. Määrame mis tahes taseme stiilidele mittesemantilised nimed, välja arvatud ikoonid, näiteks linnade nimed, nümfide nimed, pokemonid, auto kaubamärgid... On ainult üks tingimus - nimekiri ei tohi enne otsa lõppeda , kuidas stiilid lõppevad - show must go! Te ei tohiks semantikast meelt lahutada, et te ei peaks lisama keskmist nuppu näiteks „väikese” ja „keskmise” vahele.

Visuaalne keel

Arendajad jäid mõtlema, kuidas andmeid salvestada ja edastada viisil, mis sobiks kõikidele platvormidele, ning projekteerimisel tuli kujundada liideseelemendid, mis näeksid hea välja ja töötaksid tõhusalt kogu toetatud seadmete pargis.

Varem olime juba jõudnud "testida" enamikku kujunduselemente Windows 10 rakenduses, mis oli tol ajal meie jaoks uus platvorm, st nõudis renderdamist ja arendamist "nullist". Seda joonistades saime ette valmistada ja testida enamikke komponente ning aru saada, millised neist pidid tulevasse Eevee projekteerimissüsteemi kaasama. Ilma sellise liivakastita saaks selliseid kogemusi vaid suure hulga iteratsioonidega juba töötavatel platvormidel ja selleks kuluks rohkem kui aasta.

Samade komponentide taaskasutamine erinevatel platvormidel vähendab oluliselt disainisüsteemi paigutuste arvu ja andmemassiivi, mistõttu tuli projekteerimisel lahendada veel üks probleem, mida varem tootedisaini ja -arenduse praktikates ei kirjeldatud – kuidas nt. kas telefonide ja tahvelarvutite nuppu saab telerites uuesti kasutada? Ja mida peaksime tegema selliste erinevate platvormide fontide ja elementide suurustega?

Ilmselgelt oli vaja kujundada platvormideülene moodulvõrk, mis määraks iga konkreetse platvormi jaoks vajalikud teksti- ja elementide suurused. Ruudustiku lähtepunktiks valisime filmiplakatite suuruse ja arvu, mida konkreetsel ekraanil näha tahame ning selle põhjal sõnastasime ruudustiku veergude koostamise reegli eeldusel, et ühe veeru laius on võrdne plakati laiusele.

Nüüd peame viima kõik suured ekraanid samasse paigutuse suurusesse ja sobitama need ühisesse võrku. Apple TV ja Roku on disainitud suurusega 1920x1080, Android TV - 960x540, nutitelerid on olenevalt müüjast samad, kuid mõnikord 1280x720. Kui rakendus renderdatakse ja kuvatakse Full HD ekraanidel, korrutatakse 960 2-ga, 1280 korrutatakse 1,33-ga ja 1920 väljastatakse sellisel kujul.

Igavad üksikasjad vahele jättes jõudsime järeldusele, et üldiselt on kõik ekraanid, sealhulgas teleriekraanid, nii elementide kui ka suuruste poolest kaetud ühe kujunduspaigutusega ning kõik teleriekraanid on üldise platvormidevahelise ruudustiku erijuht, ja koosneb viiest või kuuest veerust, nagu keskmine tahvelarvuti või töölaud. Keda huvitavad üksikasjad, minge kommentaaridesse.

Üks kasutajaliides kõigi platvormide jaoks

Nüüd ei pea me uue funktsiooni joonistamiseks iga platvormi jaoks kujundust joonistama ja iga platvormi jaoks kohandamisvõimalusi. Piisab, kui näidata ühte paigutust ja selle kohandatavust kõigile platvormidele ja mis tahes laiusega seadmetele: telefonid - 320-599, kõik muu - 600-1280.

Andmed → arendus

Muidugi, kuigi me sooviksime saavutada täiesti ühtset disaini, on igal platvormil oma ainulaadsed omadused. Kuigi nii veebis kui ka nutiteleris kasutatakse ReactJS + TypeScripti pinu, töötab Smart TV rakendus WebKiti ja Presto pärandklientidel ega saa seetõttu stiile veebiga jagada. Ja meiliuudiskirjad on täiesti sunnitud töötama tabelipaigutusega. Samal ajal ei kasuta ega plaani ükski mitte-HTML-platvorm React Native'i ega selle analooge kasutada, kartes jõudluse halvenemist, kuna meil on liiga palju kohandatud paigutusi, keeruka värskendusloogikaga kogusid, pilte ja videoid. Seetõttu ei sobi meile levinud CSS-i valmisstiilide või React-komponentide tarnimise skeem. Seetõttu otsustasime edastada andmed JSON-vormingus, kirjeldades väärtusi abstraktsel deklaratiivsel kujul.

Seega vara rounding: 8 Windows 10 rakendus teisendab järgmiseks CornerRadius="8", võrk - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Kinnisvara offsetTop: 12 sama veebiklient võib erinevatel juhtudel tõlgendada kui top, margin-top, padding-top või transform

Kirjelduse deklaratiivsus tähendab ka seda, et kui platvorm tehniliselt ei saa omadust või selle väärtust kasutada, võib ta seda ignoreerida. Terminoloogia poolest tegime omamoodi esperanto keele: osa võeti Androidist, osa SVG-st, osa CSS-ist.

Kui konkreetsel platvormil on vaja elemente teistmoodi kuvada, oleme juurutanud võimaluse edastada vastav andmete genereerimine eraldi JSON-failina. Näiteks nutiteleri olek "fookuses" määrab plakati all oleva teksti positsiooni muutmise, mis tähendab, et selle platvormi jaoks sisaldab see atribuudi "taane" väärtuses komponent 8 vajalikku taandepunkti. Kuigi see muudab projekteerimissüsteemi taristu keerulisemaks, annab see täiendava vabadusastme, jättes meile võimaluse hallata platvormide visuaalset “erinevust” ise, mitte olla enda loodud arhitektuuri pantvangis.

Piktogrammid

Ikonograafia digitaalses tootes on alati mahukas ja mitte just kõige lihtsam alamprojekt, mis nõuab sageli eraldi kujundajat. Glüüfe on alati palju, igal neist on mitu suurust ja värvi ning platvormid vajavad neid tavaliselt erinevas vormingus. Üldiselt polnud põhjust seda kõike projekteerimissüsteemi mitte panna.

Glüüfid laaditakse SVG-vektorivormingus ja värviväärtused asendatakse automaatselt muutujatega. Kliendirakendused saavad need kasutusvalmis vastu võtta – mis tahes formaadis ja värvitoonis.

Eelvaade

Lisaks JSON-i andmetele kirjutasime komponentide eelvaate kuvamiseks tööriista – JS-rakenduse, mis edastab JSON-andmed käigu pealt läbi märgistus- ja stiiligeneraatorite ning kuvab brauseris iga komponendi erinevaid variatsioone. Põhimõtteliselt on eelvaade täpselt sama klient kui platvormirakendused ja töötab samade andmetega.

Lihtsaim viis konkreetse komponendi toimimise mõistmiseks on sellega suhelda. Seetõttu ei kasutanud me tööriistu nagu Storybook, vaid tegime interaktiivse eelvaate - saab puudutada, osutada, klõpsata... Kujundussüsteemi uue komponendi lisamisel ilmub see eelvaatesse, et platvormidel oleks millele keskenduda, kui selle rakendamine.

Документация

Platvormidele JSON-vormingus edastatud andmete põhjal genereeritakse komponentide dokumentatsioon automaatselt. Kirjeldatakse atribuutide loendit ja võimalikke väärtuste tüüpe igaühes neist. Pärast automaatset genereerimist saab teavet käsitsi täpsustada ja lisada tekstikirjelduse. Eelvaade ja dokumentatsioon on iga komponendi tasemel üksteisele ristviidatud ning kogu dokumentatsioonis sisalduv teave on arendajatele saadaval täiendavate JSON-failide kujul.

Deprekator

Teine vajadus oli võimalus olemasolevaid komponente aja jooksul asendada ja värskendada. Disainisüsteem on õppinud arendajatele ütlema, milliseid omadusi või isegi terveid komponente ei saa kasutada, ja eemaldama need niipea, kui neid enam kõigil platvormidel ei kasutata. Selles protsessis on veel palju “käsitööd”, kuid me ei seisa paigal.

Kliendi arendamine

Kõige keerulisem etapp oli kahtlemata disainisüsteemi andmete tõlgendamine kõigi meie poolt toetatavate platvormide koodis. Kui näiteks moodulvõrgud veebis pole midagi uut, siis iOS-i ja Androidi natiivsete mobiilirakenduste arendajad nägid kõvasti vaeva, enne kui said aru, kuidas sellega edasi elada.

iOS-i rakenduste ekraanide paigutuseks kasutame kahte iviUIKiti pakutavat põhimehhanismi: elementide tasuta paigutust ja elementide kogumite paigutust. Kasutame VIPER-i ja kogu interaktsioon iviUIKitiga on koondunud vaatesse ning suurem osa Apple UIKitiga suhtlemisest on koondunud iviUIKiti. Elementide suurused ja paigutus määratakse veergude ja süntaktiliste struktuuride järgi, mis töötavad iOS-i SDK algpiirangute peal, muutes need praktilisemaks. See lihtsustas meie elu eriti UICollectionView'ga töötades. Paigutuste jaoks oleme kirjutanud mitu kohandatud ümbrist, sealhulgas üsna keerukaid. Kliendikoodi oli minimaalselt ja see muutus deklaratiivseks.

Androidi projektis stiilide genereerimiseks kasutame Gradle'i, muutes disainisüsteemi andmed XML-vormingus stiilideks. Samal ajal on meil mitu erineva tasemega generaatorit:

• Põhiline. Kõrgema taseme generaatorite primitiivide andmed sõelutakse.
• Ressurss. Laadige alla pilte, ikoone ja muud graafikat.
• Komponent. Need on kirjutatud iga komponendi jaoks, mis kirjeldab, milliseid omadusi ja kuidas neid stiilideks tõlkida.

Rakenduste väljalasked

Pärast seda, kui disainerid on uue komponendi joonistanud või olemasoleva ümber kujundanud, sisestatakse need muudatused projekteerimissüsteemi. Iga platvormi arendajad viimistlevad muudatuste toetamiseks oma koodi genereerimist. Pärast seda saab seda kasutada uute funktsioonide juurutamisel, kui seda komponenti vajatakse. Seega interaktsioon disainisüsteemiga ei toimu reaalajas, vaid ainult uute väljaannete kokkupanemise ajal. Selline lähenemine võimaldab ka paremini kontrollida andmeedastusprotsessi ning tagab koodi funktsionaalsuse kliendiarendusprojektides.

Tulemused

Möödunud on aasta, kui disainisüsteem sai osaks Ivy online-kino arendust toetavast taristust ja juba võib teha mõned järeldused:

• See on suur ja keeruline projekt, mis nõuab pidevat pühendunud ressurssi.
• See võimaldas meil luua oma ainulaadse platvormideülese visuaalse keele, mis vastab võrguvideoteenuse eesmärkidele.
• Meil ei ole enam visuaalselt ja funktsionaalselt mahajäänud platvorme.

Ivy disainisüsteemi komponentide eelvaade - design.ivi.ru

Allikas: www.habr.com