Ivy online mozi élmény
Amikor 2017 elején először gondolkodtunk azon, hogy létrehozzuk saját design-to-code kézbesítési rendszerünket, sokan már beszéltek róla, és néhányan meg is tették. Azonban a mai napig keveset tudunk a többplatformos tervezési rendszerek kiépítésének tapasztalatairól, és nem voltak egyértelmű és bevált receptek, amelyek leírnák azokat a technológiákat és módszereket, amelyek a tervezési megvalósítás folyamatát már működő termékké alakítanák át. És a „kód összetevői” alatt gyakran nagyon különböző dolgokat értenek.
Eközben a cég évről évre megduplázta a létszámát - szükség volt a tervezési részleg méretezésére, valamint az elrendezések létrehozásának és átvitelének folyamatainak optimalizálására a fejlesztéshez. Mindezt megsokszorozzuk a támogatandó platformok „állatkertjével”, és a babiloni pandemonium látszatát kapjuk, ami egyszerűen nem képes „normálisan csinálni” és bevételt termelni. A platformok fejlesztése gyakran párhuzamosan zajlott, és ugyanaz a funkcionalitás több hónapos késéssel kerülhetett a különböző platformokra.
Külön elrendezéskészlet minden platformhoz
Hagyományosan azokkal a problémákkal kezdtük, amelyek megoldásában egy tervezési rendszer segít, és követelményeket fogalmaztunk meg a tervezésére vonatkozóan. Az egységes vizuális nyelv kialakítása, az elrendezés és a fejlesztés sebességének növelése, valamint a termék általános minőségének javítása mellett létfontosságú volt a dizájn lehető legnagyobb egységesítése. Erre azért van szükség, hogy a funkcionalitás fejlesztése minden platformunkon egyszerre lehetséges legyen: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku – anélkül, hogy mindegyiken külön dolgoznánk. És megcsináltuk!
Tervezés → adatok
Amikor megszülettek az alapvető megállapodások a termék- és fejlesztési osztályok között, leültünk kiválasztani a technológiai halmazt, és kidolgozni a teljes folyamat részleteit - az elrendezéstől a kiadásig. A tervezésnek a fejlesztésbe való átvitelének teljes automatizálása érdekében megvizsgáltuk a komponensek paramétereinek közvetlenül a Sketch fájlokból történő elemzését az elrendezésekkel. Kiderült, hogy a szükséges kódrészletek megtalálása és a szükséges paraméterek kinyerése összetett és veszélyes vállalkozás volt. Először is, a tervezőknek rendkívül óvatosnak kell lenniük a forráskód összes rétegének elnevezésekor, másodszor, ez csak a legegyszerűbb komponenseknél működik, harmadszor pedig, ha valaki más technológiájától és az eredeti Sketch elrendezés kódszerkezetétől függ, az a teljes jövőt veszélyezteti. projekt. Úgy döntöttünk, hogy felhagyunk az automatizálással ezen a területen. Így jelent meg a tervezőrendszer csapatában az első ember, akinek a bemenete a tervezési elrendezések, a kimenet pedig a komponensek összes paraméterét leíró, atomi tervezési módszertan szerint hierarchikusan rendezett adatok.
Már csak az maradt hátra, hogy hol és hogyan tároljuk az adatokat, hogyan vigyük át a fejlesztésbe és hogyan értelmezzük a fejlesztés során az összes általunk támogatott platformon. Az este megszűnt bágyadtnak lenni... Az egyes platformok tervezőiből és csapatvezetőiből álló munkacsoport rendszeres üléseinek eredménye a következőkben született megállapodás.
Manuálisan elemezzük a látványt atomelemekre: betűtípusok, színek, átlátszóság, behúzások, kerekítések, ikonok, képek és animációk időtartama. És ebből gyűjtjük a gombokat, bemeneteket, jelölőnégyzeteket, bankkártya widgeteket stb. Bármelyik szint stílusához nem szemantikus neveket rendelünk, kivéve az ikonokat, például városok nevei, nimfák nevei, Pokemonok, autók márkák... Csak egy feltétel van - a lista előtt ne legyen kimerítve, hogyan végződnek a stílusok - show must go! Nem szabad elragadtatni magát a szemantikával, hogy ne kelljen például középső gombot hozzáadnia a „kicsi” és a „közepes” közé.
Vizuális nyelv
A fejlesztőknek meg kellett gondolniuk, hogyan tárolják és továbbítsák az adatokat úgy, hogy az minden platformnak megfeleljen, a tervezésnek pedig olyan interfészelemeket kellett megterveznie, amelyek jól néznek ki és hatékonyan működnek a támogatott eszközök teljes flottáján.
Korábban már sikerült a legtöbb tervezési elemet „tesztelni” egy Windows 10-es alkalmazásban, ami akkor még új platform volt számunkra, vagyis „a nulláról” kellett renderelni és fejleszteni. Megrajzolásával elő tudtuk készíteni és tesztelni a legtöbb komponenst, és megértettük, hogy ezek közül melyeket kellett volna beépíteni az Eevee jövőbeli tervezési rendszerébe. Ilyen homokozó nélkül ilyen tapasztalatokat csak nagyszámú iterációval lehetne megszerezni a már működő platformokon, és ez több mint egy évig tartana.
Ugyanazon komponensek különböző platformokon történő újrafelhasználása jelentősen csökkenti a tervezőrendszer elrendezéseinek számát és adattömbjét, így a tervezésnél még egy, a terméktervezés és -fejlesztés gyakorlatában korábban nem leírt problémát kellett megoldani - hogyan pl. A telefonok és táblagépek gombja újrafelhasználható a tévében? És mit tegyünk a betűtípusok és elemek méretével az ilyen különböző platformokon?
Nyilvánvalóan szükség volt egy többplatformos moduláris rács tervezésére, amely beállítja az egyes platformokhoz szükséges szöveg- és elemméreteket. A rács kiindulópontjaként kiválasztottuk, hogy egy adott képernyőn mekkora és hány filmplakátot szeretnénk látni, és ez alapján megfogalmaztunk egy szabályt a rácsoszlopok felépítésére, feltéve, hogy az egyik oszlop szélessége egyenlő. a plakát szélességéig.
Most az összes nagy képernyőt ugyanarra az elrendezési méretre kell hoznunk, és egy közös rácsba kell illesztenünk őket. Az Apple TV és a Roku mérete 1920x1080, az Android TV - 960x540, az intelligens TV-k a gyártótól függően ugyanazok, de néha 1280x720. Amikor az alkalmazást rendereli és megjeleníti Full HD képernyőkön, a 960-at megszorozzák 2-vel, az 1280-at szorozzák 1,33-mal, és az 1920-at úgy adják ki, ahogy van.
Az unalmas részleteket kihagyva arra a következtetésre jutottunk, hogy általában minden képernyőt, beleértve a televízió képernyőket is, az elemeket és azok méretét tekintve egy tervezési elrendezés fedi le, és minden televízió képernyő egy speciális esete az általános cross-platform rácsnak, és öt vagy hat oszlopból áll, mint egy átlagos táblagép vagy asztali számítógép. Akit érdekelnek a részletek, írjon kommentbe.
Egyetlen felhasználói felület minden platformhoz
Most, hogy egy új funkciót megrajzoljunk, nem kell minden platformhoz elrendezést rajzolnunk, és mindegyikhez nem kell alkalmazkodni. Elegendő egy elrendezést és annak alkalmazkodóképességét minden szélességű platformhoz és eszközhöz bemutatni: telefonok - 320-599, minden más - 600-1280.
Adatok → fejlesztés
Természetesen bármennyire is szeretnénk egy teljesen egységes dizájnt elérni, minden platformnak megvannak a maga egyedi jellemzői. Annak ellenére, hogy a web és a Smart TV is használja a ReactJS + TypeScript veremet, a Smart TV alkalmazás régebbi WebKit és Presto klienseken fut, ezért nem tud stílusokat megosztani az internettel. Az e-mailes hírlevelek pedig teljesen kénytelenek táblázatos elrendezéssel dolgozni. Ugyanakkor a nem html platformok egyike sem használja és nem tervezi használni a React Native-t vagy bármely analógját, tartva a teljesítmény romlásától, mivel túl sok egyedi elrendezésünk, összetett frissítési logikával rendelkező gyűjteményünk, képünk és videónk van. Ezért a kész CSS-stílusok vagy React komponensek szállításának általános sémája nem megfelelő számunkra. Ezért úgy döntöttünk, hogy az adatokat JSON formátumban továbbítjuk, absztrakt deklaratív formában leírva az értékeket.
Tehát tulajdon
rounding: 8A Windows 10 alkalmazás konvertálódik a következőreCornerRadius="8", web -border-radius: 8px, Android -android:radius="8dp", iOS -self.layer.cornerRadius = 8.0.
IngatlanoffsetTop: 12ugyanaz a webes kliens különböző esetekben értelmezheti minttop,margin-top,padding-topvagytransform
A leírás deklaratív jellege azt is jelenti, hogy ha a platform technikailag nem tud egy tulajdonságot vagy annak értékét használni, figyelmen kívül hagyhatja azt. Ami a terminológiát illeti, egyfajta eszperantó nyelvet csináltunk: hol Androidról, hol SVG-ről, hol CSS-ről vettük át.
Ha egy adott platformon másként kell megjeleníteni az elemeket, akkor megvalósítottuk azt a lehetőséget, hogy a megfelelő adatgenerálást külön JSON-fájl formájában továbbítsuk. Például a Smart TV „fókuszban” állapota megváltoztatja a poszter alatti szöveg helyzetét, ami azt jelenti, hogy ennél a platformnál az „indent” tulajdonság értékében ez az összetevő tartalmazza a szükséges 8 behúzási pontot. Ez ugyan bonyolítja a tervezési rendszer infrastruktúráját, de további szabadságot ad, lehetőséget adva arra, hogy magunk kezeljük a platformok vizuális „különbözetét”, és ne legyünk túszai az általunk megalkotott architektúrának.
Piktogramok
Az ikonográfia egy digitális termékben mindig terjedelmes és nem a legegyszerűbb alprojekt, amely gyakran külön tervezőt igényel. Mindig sok karakterjel van, mindegyiknek többféle mérete és színe van, és a platformoknak általában különböző formátumokban van szükségük rájuk. Általában nem volt ok arra, hogy mindezt ne helyezzük bele a tervezési rendszerbe.
A karakterjelek SVG vektorformátumban töltődnek be, és a színértékek automatikusan lecserélődnek változókra. Az ügyfélalkalmazások felhasználásra készen tudják fogadni őket – bármilyen formátumban és színben.
Előnézet
A JSON-adatokon felül írtunk egy eszközt az összetevők előnézetéhez – egy JS-alkalmazást, amely menet közben továbbítja a JSON-adatokat a jelölő- és stílusgenerátorokon, és megjeleníti az egyes összetevők különböző változatait a böngészőben. Lényegében az előnézet pontosan ugyanaz az ügyfél, mint a platformalkalmazások, és ugyanazokkal az adatokkal működik.
A legegyszerűbb módja annak, hogy megértse egy adott összetevő működését, ha interakcióba lép vele. Ezért nem olyan eszközöket használtunk, mint a Storybook, hanem interaktív előnézetet készítettünk - lehet érinteni, mutatni, kattintani... Amikor új komponenst adunk a tervezési rendszerhez, az megjelenik az előnézetben, hogy a platformoknak legyen mire összpontosítani, amikor annak megvalósítása.
dokumentáció
A platformoknak JSON-formátumban szolgáltatott adatok alapján automatikusan létrejön az összetevők dokumentációja. Leírják a tulajdonságok listáját és az egyes értékek lehetséges típusait. Az automatikus generálás után az információk manuálisan pontosíthatók, és szöveges leírás is hozzáadható. Az előnézet és a dokumentáció az egyes összetevők szintjén kereszthivatkozásokat tartalmaz, és a dokumentációban szereplő összes információ további JSON-fájlok formájában elérhető a fejlesztők számára.
Deprecator
Egy másik szükségesség a meglévő komponensek idővel történő cseréje és frissítése volt. A tervezőrendszer megtanulta, hogy megmondja a fejlesztőknek, hogy mely tulajdonságok vagy akár teljes komponensek nem használhatók, és eltávolítja azokat, amint már nem használják minden platformon. Ebben a folyamatban még sok a „kézi” munka, de nem állunk egy helyben.
Ügyfélfejlesztés
A legbonyolultabb szakasz kétségtelenül a tervezési rendszeradatok értelmezése volt az összes általunk támogatott platform kódjában. Ha például a web moduláris gridjei nem újdonságnak számítanak, akkor a natív iOS és Android mobilalkalmazások fejlesztői keményen dolgoztak, mielőtt rájöttek, hogyan éljenek velük.
Az iOS-alkalmazások képernyőinek elrendezéséhez az iviUIKit által biztosított két alapvető mechanizmust használjuk: az elemek ingyenes elrendezését és az elemgyűjtemények elrendezését. VIPER-t használunk, és az iviUIKittel való minden interakció a View-ban összpontosul, és az Apple UIKittel folytatott interakciók többsége az iviUIKitben összpontosul. Az elemek méretét és elrendezését az oszlopok és a szintaktikai struktúrák határozzák meg, amelyek a natív iOS SDK megkötéseken felül működnek, így praktikusabbak. Ez különösen leegyszerűsítette az életünket, amikor az UICollectionView-val dolgozunk. Számos egyedi burkolóanyagot írtunk az elrendezésekhez, beleértve a meglehetősen összetetteket is. Minimális ügyfélkód volt, és deklaratív lett.
Stílusok létrehozásához az Android projektben a Gradle-t használjuk, amely a tervezési rendszeradatokat XML formátumú stílusokká alakítja. Ugyanakkor számos különböző szintű generátorunk van:
- Alapvető. A magasabb szintű generátorokhoz tartozó primitívek adatait elemzi.
- Forrás. Töltsön le képeket, ikonokat és egyéb grafikákat.
- Összetevő. Mindegyik komponenshez meg vannak írva, ami leírja, hogy milyen tulajdonságokat és hogyan kell stílusokká lefordítani.
Alkalmazások kiadásai
Miután a tervezők megrajzoltak egy új alkatrészt vagy átterveztek egy meglévőt, ezek a változtatások bekerülnek a tervezési rendszerbe. Az egyes platformok fejlesztői finomhangolják a kódgenerálást, hogy támogassák a változtatásokat. Ezt követően használható új funkciók megvalósításában, ahol erre a komponensre szükség van. Így a tervezési rendszerrel való interakció nem valós időben történik, hanem csak az új kiadások összeállításakor. Ez a megközelítés lehetővé teszi az adatátviteli folyamat jobb ellenőrzését is, és biztosítja a kód funkcionalitását az ügyfélfejlesztési projektekben.
Eredményei
Egy év telt el azóta, hogy a tervezőrendszer az Ivy online mozi fejlesztését támogató infrastruktúra része lett, és máris levonhatjuk a következtetéseket:
- Ez egy nagy és összetett projekt, amely állandó erőforrásokat igényel.
- Ez lehetővé tette számunkra, hogy létrehozzuk saját, több platformon átívelő vizuális nyelvünket, amely megfelel az online videószolgáltatás célkitűzéseinek.
- Már nincsenek vizuálisan és funkcionálisan lemaradó platformjaink.
Az Ivy tervezési rendszer összetevőinek előnézete -
Forrás: will.com