Nuo vartotojo sąsajos rinkinio iki projektavimo sistemos

Ivy internetinio kino patirtis

Kai 2017 metų pradžioje pirmą kartą galvojome apie savo dizaino į kodą pristatymo sistemos kūrimą, daugelis apie tai jau kalbėjo, o kai kurie net darė. Tačiau iki šiol mažai žinoma apie kelių platformų projektavimo sistemų kūrimo patirtį, taip pat nebuvo aiškių ir patikrintų receptų, aprašančių technologijas ir metodus tokiam dizaino įgyvendinimo proceso pavertimui jau veikiančiu produktu. O „kode esantys komponentai“ dažnai reiškia labai skirtingus dalykus.

Tuo tarpu įmonė metai iš metų padvigubino darbuotojų skaičių – reikėjo išplėsti projektavimo skyrių ir optimizuoti maketų kūrimo ir perdavimo plėtrai procesus. Visa tai padauginame iš platformų, kurias reikia palaikyti, „zoologijos sodo“ ir gauname Babilono pandemonijos įvaizdį, kuris tiesiog negali „padaryti normaliai“ ir uždirbti pajamų. Platformų kūrimas dažnai vyko lygiagrečiai, o tas pats funkcionalumas galėjo būti išleistas skirtingose ​​platformose su kelių mėnesių vėlavimu.


Atskiri išdėstymo rinkiniai kiekvienai platformai

Tradiciškai pradėjome nuo problemų, kurias padėtų išspręsti projektavimo sistema ir suformulavome reikalavimus jos projektavimui. Be vieningos vaizdinės kalbos kūrimo, maketavimo ir kūrimo greičio didinimo bei bendros gaminio kokybės gerinimo, labai svarbu buvo kuo labiau suvienodinti dizainą. Tai būtina, kad funkcionalumą būtų galima plėtoti visose mūsų platformose vienu metu: žiniatinklyje, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku – nedirbant su kiekviena iš jų atskirai. Ir mes tai padarėme!

Dizainas → duomenys

Kai buvo pasiekti esminiai susitarimai tarp produktų ir plėtros skyrių, susėdome pasirinkti technologijų krūvą ir išsiaiškinti viso proceso detales – nuo ​​maketavimo iki išleidimo. Norėdami visiškai automatizuoti dizaino perkėlimo į kūrimą procesą, išnagrinėjome galimybę analizuoti komponentų parametrus tiesiai iš Sketch failų su maketais. Paaiškėjo, kad rasti mums reikalingus kodo fragmentus ir išgauti reikalingus parametrus buvo sudėtingas ir pavojingas darbas. Pirma, dizaineriai turės būti ypač atsargūs vardydami visus šaltinio kodo sluoksnius, antra, tai veikia tik paprasčiausiems komponentams, ir trečia, priklausomybė nuo kažkieno kito technologijos ir originalaus Sketch išdėstymo kodo struktūros kelia pavojų viso pasaulio ateičiai. projektą. Šioje srityje nusprendėme atsisakyti automatizavimo. Taip projektavimo sistemos komandoje atsirado pirmasis žmogus, kurio įvestis – projektiniai maketai, o išvestis – visus komponentų parametrus aprašantys ir pagal atominio projektavimo metodiką hierarchiškai surikiuoti duomenys.

Liko tik kur ir kaip saugoti duomenis, kaip juos perkelti į kūrimą ir kaip juos interpretuoti kuriant visose mūsų palaikomose platformose. Vakaras nustojo būti niūrus... Darbo grupės, susidedančios iš dizainerių ir kiekvienos platformos vadovų, reguliarių susitikimų rezultatas buvo susitarimas dėl to.

Mes rankiniu būdu analizuojame vaizdą į atominius elementus: šriftus, spalvas, skaidrumą, įtraukas, apvalinimus, piktogramas, paveikslėlius ir animacijų trukmę. Ir iš to renkame mygtukus, įvestis, žymimuosius langelius, banko kortelių valdiklius ir t.t. Bet kurio lygio stiliams priskiriame ne semantinius pavadinimus, išskyrus piktogramas, pavyzdžiui, miestų pavadinimus, nimfų pavadinimus, pokemonus, mašinas. prekiniai ženklai... Yra tik viena sąlyga - sąrašas neturėtų būti išnaudotas anksčiau, kaip baigiasi stiliai - šou turi eiti! Neturėtumėte pasinerti į semantiką, kad, pavyzdžiui, nereikėtų pridėti vidurinio mygtuko tarp „mažo“ ir „vidutinio“.

Vaizdinė kalba

Kūrėjams beliko galvoti, kaip saugoti ir perduoti duomenis taip, kad jie tiktų visoms platformoms, o projektuojant reikėjo sukurti sąsajos elementus, kurie galėtų gerai atrodyti ir efektyviai veikti visame palaikomų įrenginių parke.

Anksčiau daugumą dizaino elementų jau spėjome „išbandyti“ programoje, skirtoje „Windows 10“, kuri tuo metu mums buvo nauja platforma, tai yra, reikėjo pateikti ir kurti „nuo nulio“. Ją nubraižydami galėjome paruošti ir išbandyti daugumą komponentų ir suprasti, kurie iš jų turėjo būti įtraukti į būsimą Eevee projektavimo sistemą. Be tokios smėlio dėžės tokią patirtį būtų galima įgyti tik atliekant daugybę iteracijų jau veikiančiose platformose, ir tai užtruktų daugiau nei metus.

Pakartotinis tų pačių komponentų panaudojimas skirtingose ​​platformose kelis kartus sumažina projektavimo sistemos maketų skaičių ir duomenų masyvą, todėl projektuojant teko išspręsti dar vieną problemą, kuri anksčiau nebuvo aprašyta gaminių projektavimo ir kūrimo praktikoje – kaip, Pavyzdžiui, ar telefonams ir planšetiniams kompiuteriams skirtą mygtuką galima pakartotinai naudoti televizoriuose? O ką turėtume daryti su šriftų ir elementų dydžiais tokiose skirtingose ​​platformose?

Akivaizdu, kad reikėjo sukurti kelių platformų modulinį tinklelį, kuris nustatytų teksto ir elementų dydžius, kurių mums reikia kiekvienai konkrečiai platformai. Kaip atspirties tašką tinkleliui, pasirinkome filmo plakatų dydį ir skaičių, kuriuos norime matyti konkrečiame ekrane, ir pagal tai suformulavome tinklelio stulpelių konstravimo taisyklę, su sąlyga, kad vieno stulpelio plotis yra lygus. iki plakato pločio.

Dabar turime visus didelius ekranus sutalpinti į vienodą išdėstymo dydį ir sutalpinti juos į bendrą tinklelį. Apple TV ir Roku yra suprojektuoti 1920x1080 dydžio, Android TV - 960x540, Smart TV, priklausomai nuo pardavėjo, yra vienodi, bet kartais 1280x720. Kai programa pateikiama ir rodoma Full HD ekranuose, 960 padauginamas iš 2, 1280 padauginamas iš 1,33, o 1920 išvesta tokia, kokia yra.

Praleisdami nuobodžias detales, priėjome prie išvados, kad apskritai visi ekranai, įskaitant televizorių ekranus, pagal elementus ir jų dydžius yra padengti vieno dizaino išdėstymu, o visi televizorių ekranai yra ypatingas bendro kelių platformų tinklelio atvejis, ir susideda iš penkių ar šešių stulpelių, kaip vidutinis planšetinis kompiuteris arba darbalaukis. Kam įdomi smulkmena, eikite į komentarus.

Viena vartotojo sąsaja visoms platformoms

Dabar, norėdami nubrėžti naują funkciją, mums nereikia piešti kiekvienos platformos maketų ir kiekvienos iš jų pritaikymo parinkčių. Pakanka parodyti vieną maketą ir jo pritaikomumą visoms platformoms ir bet kokio pločio įrenginiams: telefonams - 320-599, visa kita - 600-1280.

Duomenys → plėtra

Žinoma, kad ir kaip norėtume pasiekti visiškai vieningą dizainą, kiekviena platforma turi savo unikalių savybių. Nors žiniatinklis ir išmanioji televizija naudoja „ReactJS + TypeScript“ krūvą, „Smart TV“ programa veikia senuose „WebKit“ ir „Presto“ klientuose, todėl negali bendrinti stilių su žiniatinkliu. Ir naujienlaiškiai el. paštu yra visiškai priversti dirbti su lentelių išdėstymu. Tuo pačiu metu nė viena iš ne html platformų nenaudoja ir neplanuoja naudoti „React Native“ ar bet kurio jo analogo, bijodama pabloginti našumą, nes turime per daug tinkintų maketų, kolekcijų su sudėtinga atnaujinimo logika, vaizdų ir vaizdo įrašų. Todėl įprasta paruoštų CSS stilių ar React komponentų pristatymo schema mums netinka. Todėl nusprendėme duomenis perduoti JSON formatu, apibūdindami reikšmes abstrakčia deklaratyvia forma.

Taigi turtas rounding: 8 „Windows 10“ programa konvertuojama į CornerRadius="8", žiniatinklis - border-radius: 8px, Android – android:radius="8dp", iOS – self.layer.cornerRadius = 8.0.
Nuosavybė offsetTop: 12 tas pats žiniatinklio klientas skirtingais atvejais gali interpretuoti kaip top, margin-top, padding-top arba transform

Aprašymo deklaratyvumas taip pat reiškia, kad jei platforma techniškai negali naudoti nuosavybės ar jos vertės, ji gali į tai nepaisyti. Kalbant apie terminologiją, padarėme savotišką esperanto kalbą: dalis buvo paimta iš Android, dalis iš SVG, dalis iš CSS.

Jei tam tikroje platformoje elementus reikia rodyti kitaip, įdiegėme galimybę perkelti atitinkamą duomenų generavimą atskiro JSON failo forma. Pavyzdžiui, „Smart TV“ būsena „fokusuota“ lemia teksto pozicijos po plakatu pakeitimą, o tai reiškia, kad šioje platformoje šis „įtraukos“ ypatybės vertės komponentas turės 8 jai reikalingus įtraukos taškus. Nors tai apsunkina projektavimo sistemos infrastruktūrą, tačiau suteikia papildomo laisvės, paliekant galimybę patiems valdyti vizualinį platformų „nepanašumą“, o ne būti savo sukurtos architektūros įkaitais.

Piktogramos

Ikonografija skaitmeniniame gaminyje visada yra didelis ir ne pats paprasčiausias subprojektas, kuriam dažnai reikia atskiro dizainerio. Visada yra daug glifų, kiekvienas iš jų turi keletą dydžių ir spalvų, o platformoms jų dažniausiai reikia skirtingais formatais. Apskritai nebuvo jokios priežasties viso to neįtraukti į projektavimo sistemą.

Glifai įkeliami SVG vektoriniu formatu, o spalvų reikšmės automatiškai pakeičiamos kintamaisiais. Klientų programos gali gauti jas paruoštas naudoti – bet kokio formato ir spalvos.

Peržiūra

Be JSON duomenų, sukūrėme komponentų peržiūros įrankį – JS programą, kuri perduoda JSON duomenis per savo žymėjimo ir stiliaus generatorius ir naršyklėje rodo įvairius kiekvieno komponento variantus. Iš esmės peržiūra yra lygiai toks pat klientas kaip ir platformos programos ir veikia su tais pačiais duomenimis.

Lengviausias būdas suprasti, kaip veikia tam tikras komponentas, yra sąveikaujant su juo. Todėl nenaudojome tokių įrankių kaip Storybook, o padarėme interaktyvią peržiūrą – galima liesti, rodyti, spustelėti... Pridedant naują komponentą į projektavimo sistemą, jis pasirodo peržiūroje, kad platformos turėtų į ką orientuotis, kai ją įgyvendinant.

Įrašai

Remiantis platformoms JSON forma pateiktais duomenimis, komponentų dokumentacija generuojama automatiškai. Aprašytas kiekvienos iš jų savybių sąrašas ir galimi verčių tipai. Po automatinio generavimo informaciją galima patikslinti rankiniu būdu ir pridėti tekstinį aprašymą. Peržiūra ir dokumentacija yra kryžminės nuorodos viena į kitą kiekvieno komponento lygiu, o visa į dokumentaciją įtraukta informacija kūrėjams pasiekiama papildomų JSON failų pavidalu.

Deprecator

Kita būtinybė buvo galimybė laikui bėgant pakeisti ir atnaujinti esamus komponentus. Projektavimo sistema išmoko pasakyti kūrėjams, kurių savybių ar net visų komponentų negalima naudoti, ir pašalinti juos, kai tik jie nebenaudojami visose platformose. Šiame procese dar yra daug „rankinio“ darbo, bet mes nestovime vietoje.

Kliento vystymas

Neabejotinai sudėtingiausias etapas buvo projektavimo sistemos duomenų interpretavimas visų mūsų palaikomų platformų kode. Jei, pavyzdžiui, moduliniai tinkleliai žiniatinklyje nėra kažkas naujo, tai vietinių mobiliųjų programų, skirtų iOS ir Android, kūrėjai sunkiai dirbo, kol suprato, kaip su jais gyventi.

IOS programų ekranams maketuoti naudojame du pagrindinius iviUIKit teikiamus mechanizmus: nemokamą elementų išdėstymą ir elementų rinkinių išdėstymą. Mes naudojame VIPER ir visa sąveika su iviUIKit yra sutelkta rodinyje, o didžioji sąveika su Apple UIKit yra sutelkta į iviUIKit. Elementų dydžiai ir išdėstymas nurodomi pagal stulpelius ir sintaksines struktūras, kurios veikia kartu su vietiniais iOS SDK apribojimais, todėl jie yra praktiškesni. Tai ypač supaprastino mūsų gyvenimą dirbant su UICollectionView. Esame parašę keletą pasirinktinių maketų įvynioklių, įskaitant gana sudėtingus. Buvo minimalus kliento kodas ir jis tapo deklaratyvus.

Norėdami generuoti stilius Android projekte, naudojame Gradle, projektavimo sistemos duomenis paverčiant stiliais XML formatu. Tuo pačiu metu turime kelis įvairaus lygio generatorius:

• Pagrindinis. Išanalizuojami aukštesnio lygio generatorių primityvų duomenys.
• Išteklius. Atsisiųskite paveikslėlius, piktogramas ir kitą grafiką.
• Komponentas. Jie parašyti kiekvienam komponentui, kuriame aprašomos savybės ir kaip jas paversti stiliais.

Programų leidimai

Po to, kai dizaineriai nubraižo naują komponentą arba perprojektuoja esamą, šie pakeitimai įtraukiami į projektavimo sistemą. Kiekvienos platformos kūrėjai tobulina kodo generavimą, kad palaikytų pakeitimus. Po to jis gali būti naudojamas diegiant naujas funkcijas ten, kur reikalingas šis komponentas. Taigi sąveika su projektavimo sistema vyksta ne realiu laiku, o tik surenkant naujus leidimus. Šis metodas taip pat leidžia geriau kontroliuoti duomenų perdavimo procesą ir užtikrina kodo funkcionalumą klientų kūrimo projektuose.

rezultatai

Praėjo metai, kai projektavimo sistema tapo „Ivy“ internetinio kino kūrimą palaikančios infrastruktūros dalimi, ir jau galime padaryti keletą išvadų:

• Tai didelis ir sudėtingas projektas, reikalaujantis nuolatinių išteklių.
• Tai leido mums sukurti savo unikalią kelių platformų vaizdinę kalbą, atitinkančią internetinės vaizdo paslaugos tikslus.
• Nebeturime vizualiai ir funkcionaliai atsiliekančių platformų.

Ivy dizaino sistemos komponentų peržiūra - design.ivi.ru

Šaltinis: www.habr.com