UI-sarjasta suunnittelujärjestelmään

Ivy-verkkoelokuvakokemus

Kun vuoden 2017 alussa mietimme ensimmäisen kerran oman design-to-code -toimitusjärjestelmän luomista, monet puhuivat siitä jo ja jotkut jopa tekivät sitä. Kuitenkaan tähän päivään mennessä tiedetään vähän kokemuksista cross-platform-suunnittelujärjestelmien rakentamisesta, eikä ole olemassa selkeitä ja todistettuja reseptejä, jotka kuvaavat teknologioita ja menetelmiä suunnittelun toteutusprosessin muuttamiseksi jo toimivaksi tuotteeksi. Ja "koodin komponenteilla" ne tarkoittavat usein hyvin erilaisia ​​asioita.

Samaan aikaan yritys kaksinkertaisti henkilöstönsä vuosi toisensa jälkeen - oli tarpeen skaalata suunnitteluosastoa ja optimoida asettelujen luonti- ja siirtoprosessit kehitystä varten. Kerromme kaiken tämän tuettavien alustojen "eläintarhalla", ja saamme vaikutelman Babylonian pandemoniasta, joka ei yksinkertaisesti pysty "tekemään sitä normaalisti" ja tuottamaan tuloja. Alustajen kehitys eteni usein rinnakkain, ja samat toiminnot voitiin julkaista eri alustoille useiden kuukausien viiveellä.


Jokaiselle alustalle erilliset asettelusarjat

Perinteisesti aloitimme ongelmista, joita suunnittelujärjestelmä auttaisi ratkaisemaan ja muotoilimme sen suunnittelulle vaatimuksia. Yhtenäisen visuaalisen kielen luomisen, layout- ja kehitysnopeuden lisäämisen sekä tuotteen kokonaislaadun parantamisen lisäksi oli tärkeää yhtenäistää suunnittelua mahdollisimman paljon. Tämä on välttämätöntä, jotta toiminnallisuuden kehittäminen tulee mahdolliseksi kaikilla alustoillamme samanaikaisesti: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - ilman, että niitä tarvitsee käsitellä erikseen . Ja me teimme sen!

Suunnittelu → tiedot

Kun perussopimukset tuote- ja kehitysosastojen välillä saatiin aikaan, istuimme alas valitsemaan teknologiapinon ja pohtimaan koko prosessin yksityiskohdat - layoutista julkaisuun. Suunnittelun siirtämisen kehitysvaiheeseen täysin automatisoimiseksi tutkimme mahdollisuutta jäsentää komponenttiparametreja suoraan Sketch-tiedostoista asettelujen kanssa. Kävi ilmi, että tarvitsemamme koodin osien löytäminen ja tarvittavien parametrien purkaminen oli monimutkaista ja vaarallista työtä. Ensinnäkin suunnittelijoiden on oltava erittäin varovaisia ​​nimeäessään kaikki lähdekoodin kerrokset, toiseksi tämä toimii vain yksinkertaisimmilla komponenteilla ja kolmanneksi riippuvuus jonkun muun tekniikasta ja alkuperäisen Sketch-asettelun koodirakenteesta vaarantaa koko tulevaisuuden. hanke. Päätimme luopua automaatiosta tällä alueella. Näin ilmestyi ensimmäinen henkilö suunnittelujärjestelmätiimiin, jonka syötteenä ovat suunnittelun layoutit ja ulostulona komponenttien kaikki parametrit kuvaava ja atomisuunnittelumetodologian mukaisesti hierarkkisesti järjestetty data.

Jäljelle jäi vain se, mihin ja miten data tallennetaan, miten se siirretään kehitystyöhön ja miten sitä tulkitaan kehitystyössä kaikilla tukemillamme alustoilla. Ilta lakkasi olemasta laiska... Kummankin alustan suunnittelijoista ja tiiminvetäjistä koostuvan työryhmän säännöllisten tapaamisten tuloksena syntyi sopimus seuraavista.

Jäsennämme visuaalin manuaalisesti atomielementeiksi: fontit, värit, läpinäkyvyys, sisennykset, pyöristykset, kuvakkeet, kuvat ja animaatioiden kestot. Ja keräämme tästä painikkeita, syötteitä, valintaruutuja, pankkikorttiwidgetejä jne. Annamme ei-semanttisia nimiä minkä tahansa tason tyyleille, paitsi kuvakkeille, esimerkiksi kaupunkien nimet, nymfien nimet, Pokemonit, auto merkit... On vain yksi ehto - lista ei saa olla loppuun kulunut ennen , miten tyylit loppuvat - show on go! Sinun ei pitäisi hukata semantiikkaa, jotta sinun ei tarvitse lisätä keskipainiketta esimerkiksi "pienen" ja "keskikokoisen" väliin.

Visuaalinen kieli

Kehittäjät jäivät miettimään, kuinka tietoja tallennettaisiin ja siirrettäisiin kaikille alustoille sopivalla tavalla, ja suunnittelussa oli suunniteltava käyttöliittymäelementtejä, jotka voisivat näyttää hyvältä ja toimia tehokkaasti koko tuetuilla laitteilla.

Aiemmin olimme jo onnistuneet ”testaamaan” suurimman osan suunnitteluelementeistä Windows 10:n sovelluksessa, joka oli tuolloin meille uusi alusta, eli se vaati renderöinnin ja kehittämisen ”tyhjästä”. Sen piirtämällä pystyimme valmistelemaan ja testaamaan suurimman osan komponenteista ja ymmärtämään, mitkä niistä oli tarkoitus sisällyttää tulevaan Eevee-suunnittelujärjestelmään. Ilman tällaista hiekkalaatikkoa tällaista kokemusta voitaisiin saada vain useilla iteraatioilla jo toimivilla alustoilla, ja tämä kestäisi yli vuoden.

Samojen komponenttien uudelleenkäyttö eri alustoilla vähentää merkittävästi suunnittelujärjestelmän asettelujen määrää ja datamatriisia, joten suunnittelussa jouduttiin ratkaisemaan vielä yksi ongelma, jota ei aiemmin tuotesuunnittelun ja -kehityksen käytännöissä kuvattu - miten esim. Voiko puhelimien ja tablettien painiketta käyttää uudelleen televisioissa? Ja mitä meidän pitäisi tehdä fonttien ja elementtien kokoille niin erilaisissa alustoissa?

Ilmeisesti oli tarpeen suunnitella alustat ylittävä modulaarinen ruudukko, joka asettaisi kullekin tietylle alustalle tarvitsemamme teksti- ja elementtikoot. Valitsimme ruudukon lähtökohdaksi elokuvajulisteiden koon ja lukumäärän, jotka haluamme nähdä tietyllä näytöllä ja tämän perusteella muotoilimme säännön ruudukon sarakkeiden rakentamiselle edellyttäen, että yhden sarakkeen leveys on yhtä suuri. julisteen leveydelle.

Nyt meidän on saatava kaikki suuret näytöt samaan asettelun kokoon ja sovitettava ne yhteiseen ruudukkoon. Apple TV ja Roku on suunniteltu kokoon 1920x1080, Android TV - 960x540, älytelevisiot ovat myyjästä riippuen samat, mutta joskus 1280x720. Kun sovellus renderöidään ja näytetään Full HD -näytöillä, 960 kerrotaan kahdella, 2 kerrotaan 1280:lla ja 1,33 näytetään sellaisenaan.

Tylsät yksityiskohdat ohittaen päädyimme siihen tulokseen, että yleensä kaikki näytöt, mukaan lukien televisioruudut, elementtien ja niiden koon osalta ovat yhden suunnitteluasetelman kattamia, ja kaikki televisioruudut ovat yleisen cross-platform-ruudukon erikoistapaus, ja koostuu viidestä tai kuudesta sarakkeesta, kuten keskimääräinen tabletti tai työpöytä. Ketä kiinnostaa yksityiskohdat, mene kommentteihin.

Yksi käyttöliittymä kaikille alustoille

Nyt, jotta voimme piirtää uuden ominaisuuden, meidän ei tarvitse piirtää asetteluja jokaiselle alustalle sekä mukautumisvaihtoehtoja jokaiselle niistä. Riittää, kun näyttää yhden asettelun ja sen soveltuvuuden kaikille alustoille ja laitteille minkä tahansa leveyden kanssa: puhelimet - 320-599, kaikki muu - 600-1280.

Data → kehitys

Tietysti, vaikka haluaisimmekin saavuttaa täysin yhtenäisen suunnittelun, jokaisella alustalla on omat ainutlaatuiset ominaisuutensa. Vaikka sekä verkko että Smart TV käyttävät ReactJS + TypeScript -pinoa, Smart TV -sovellus toimii vanhoilla WebKit- ja Presto-asiakkailla, eikä siksi voi jakaa tyylejä verkon kanssa. Ja sähköpostiuutiskirjeet on täysin pakotettu toimimaan taulukkoasettelulla. Samanaikaisesti mikään ei-html-alustoista ei käytä tai aio käyttää React Nativea tai sen analogeja, koska pelkäät suorituskyvyn heikkenemistä, koska meillä on liian monia mukautettuja asetteluja, kokoelmia monimutkaisilla päivityslogiikalla, kuvia ja videoita. Siksi yleinen malli, jossa toimitetaan valmiita CSS-tyylejä tai React-komponentteja, ei sovellu meille. Siksi päätimme lähettää tiedot JSON-muodossa, kuvaamalla arvot abstraktissa deklaratiivisessa muodossa.

Omaisuutta siis rounding: 8 Windows 10 -sovellus muuntaa muotoon CornerRadius="8", verkko - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Omaisuus offsetTop: 12 sama web-asiakas voi eri tapauksissa tulkita kuin top, margin-top, padding-top tai transform

Kuvauksen deklaratiivisuus tarkoittaa myös sitä, että jos alusta ei teknisesti voi käyttää ominaisuutta tai sen arvoa, se voi jättää sen huomiotta. Terminologian suhteen teimme eräänlaisen esperanton kielen: osa oli otettu Androidista, osa SVG:stä, osa CSS:stä.

Jos tietyllä alustalla joudut näyttämään elementtejä eri tavalla, olemme toteuttaneet mahdollisuuden siirtää vastaava tiedon generointi erillisen JSON-tiedoston muodossa. Esimerkiksi Smart TV:n "infocus"-tila sanelee muutoksen tekstin sijaintiin julisteen alla, mikä tarkoittaa, että tälle alustalle tämä "indent" -ominaisuuden arvon komponentti sisältää sen tarvitsemat 8 sisennyspistettä. Vaikka tämä monimutkaistaa suunnittelujärjestelmän infrastruktuuria, se antaa lisää vapautta jättäen meille mahdollisuuden hallita alustojen visuaalista "eräisyyttä" itse, emmekä joutua luomamme arkkitehtuurin panttivangiksi.

Piktogrammit

Ikonografia digitaalisessa tuotteessa on aina mittava eikä yksinkertaisin osaprojekti, joka vaatii usein erillisen suunnittelijan. Glyyfejä on aina paljon, jokaisella niistä on useita kokoja ja värejä, ja alustat tarvitsevat niitä yleensä eri muodoissa. Yleisesti ottaen ei ollut mitään syytä olla sisällyttämättä tätä kaikkea suunnittelujärjestelmään.

Glyfit ladataan SVG-vektorimuodossa, ja väriarvot korvataan automaattisesti muuttujilla. Asiakassovellukset voivat vastaanottaa ne käyttövalmiina - missä tahansa muodossa ja värissä.

Esikatselu

JSON-tietojen päälle kirjoitimme työkalun komponenttien esikatseluun - JS-sovelluksen, joka välittää JSON-tiedot lennossa merkintä- ja tyyligeneraattoreidensa kautta ja näyttää selaimessa erilaisia ​​muunnelmia kustakin komponentista. Pohjimmiltaan esikatselu on täsmälleen sama asiakas kuin alustasovellukset ja toimii samoilla tiedoilla.

Helpoin tapa ymmärtää, miten tietty komponentti toimii, on olla vuorovaikutuksessa sen kanssa. Siksi emme käyttäneet työkaluja, kuten Storybook, vaan teimme interaktiivisen esikatselun - voit koskettaa, osoittaa, klikata... Kun suunnittelujärjestelmään lisätään uusi komponentti, se näkyy esikatselussa, jotta alustoilla on johonkin keskittyä, kun toteuttamalla sitä.

Asiakirjat

Alustalle JSON-muodossa toimitettujen tietojen perusteella komponenttien dokumentaatio luodaan automaattisesti. Luettelo ominaisuuksista ja mahdollisista arvotyypeistä kussakin niistä on kuvattu. Automaattisen generoinnin jälkeen tiedot voidaan selventää manuaalisesti ja lisätä tekstikuvauksen. Esikatselussa ja dokumentaatiossa on ristiviittaukset toisiinsa kunkin komponentin tasolla, ja kaikki dokumentaatioon sisältyvät tiedot ovat kehittäjien saatavilla ylimääräisten JSON-tiedostojen muodossa.

Poistaja

Toinen välttämättömyys oli kyky korvata ja päivittää olemassa olevia komponentteja ajan myötä. Suunnittelujärjestelmä on oppinut kertomaan kehittäjille, mitä ominaisuuksia tai jopa kokonaisia ​​komponentteja ei voi käyttää, ja poistamaan ne heti, kun niitä ei enää käytetä kaikilla alustoilla. Tässä prosessissa on vielä paljon "käsityötä", mutta emme pysy paikallaan.

Asiakkaan kehittäminen

Epäilemättä monimutkaisin vaihe oli suunnittelujärjestelmätietojen tulkinta kaikkien tukemiemme alustojen koodissa. Jos esimerkiksi verkon modulaariset ruudukot eivät ole jotain uutta, iOS- ja Android-mobiilisovellusten kehittäjät työskentelivät kovasti ennen kuin he keksivät, kuinka niiden kanssa pitäisi elää.

iOS-sovellusnäyttöjen asettelussa käytämme kahta iviUIKitin tarjoamaa perusmekanismia: elementtien ilmaista asettelua ja elementtikokoelmien asettelua. Käytämme VIPERiä, ja kaikki vuorovaikutus iviUIKitin kanssa on keskittynyt Viewiin, ja suurin osa vuorovaikutuksesta Apple UIKitin kanssa on keskittynyt iviUIKitiin. Elementtien koot ja järjestelyt määritellään sarakkeiden ja syntaktisten rakenteiden mukaan, jotka toimivat iOS SDK:n alkuperäisten rajoitusten päällä, mikä tekee niistä käytännöllisempiä. Tämä yksinkertaisti erityisesti elämäämme UICollectionView:n kanssa työskennellessämme. Olemme kirjoittaneet useita mukautettuja kääreitä asetteluille, mukaan lukien melko monimutkaiset. Asiakaskoodia oli vähimmäismäärä ja siitä tuli deklaratiivinen.

Tyylien luomiseen Android-projektissa käytämme Gradlea, joka muuttaa suunnittelujärjestelmän tiedot tyyleiksi XML-muodossa. Samaan aikaan meillä on useita eri tasoisia generaattoreita:

• Perus. Korkeamman tason generaattoreiden primitiivien tiedot jäsennetään.
• Resurssi. Lataa kuvia, kuvakkeita ja muuta grafiikkaa.
• Komponentti. Ne on kirjoitettu jokaiselle komponentille, mikä kuvaa mitä ominaisuuksia ja miten ne muunnetaan tyyleiksi.

Sovellusjulkaisut

Kun suunnittelijat ovat piirtäneet uuden komponentin tai suunnitellut uudelleen olemassa olevan, nämä muutokset syötetään suunnittelujärjestelmään. Kunkin alustan kehittäjät hienosäätävät koodintuotantoaan tukeakseen muutoksia. Tämän jälkeen sitä voidaan käyttää uusien toimintojen toteuttamiseen siellä, missä tätä komponenttia tarvitaan. Vuorovaikutus suunnittelujärjestelmän kanssa ei siis tapahdu reaaliajassa, vaan vain uusien julkaisujen kokoamisen yhteydessä. Tämä lähestymistapa mahdollistaa myös tiedonsiirtoprosessin paremman hallinnan ja varmistaa koodin toimivuuden asiakaskehitysprojekteissa.

Tulokset

On kulunut vuosi siitä, kun suunnittelujärjestelmä tuli osaksi Ivy-verkkoelokuvan kehitystä tukevaa infrastruktuuria, ja voimme jo vetää johtopäätöksiä:

• Tämä on suuri ja monimutkainen projekti, joka vaatii jatkuvasti omistautuneita resursseja.
• Näin pystyimme luomaan oman ainutlaatuisen cross-platform visuaalisen kielemme, joka täyttää verkkovideopalvelun tavoitteet.
• Meillä ei ole enää visuaalisesti ja toiminnallisesti jäljessä olevia alustoja.

Esikatselu Ivy-suunnittelujärjestelmän komponenteista - design.ivi.ru

Lähde: will.com