Van UI-stel tot ontwerpstelsel

Ivy aanlyn bioskoop ervaring

Toe ons aan die begin van 2017 die eerste keer daaraan gedink het om ons eie ontwerp-na-kode afleweringstelsel te skep, het baie reeds daaroor gepraat en sommige het dit selfs gedoen. Tot vandag toe is daar egter min bekend oor die ervaring van die bou van kruisplatform-ontwerpstelsels, en daar was geen duidelike en bewese resepte wat tegnologieë en metodes beskryf vir sulke transformasie van die proses van ontwerpimplementering in 'n reeds werkende produk nie. En met "komponente in die kode" bedoel hulle dikwels baie verskillende dinge.

Intussen het die maatskappy sy personeel jaar na jaar verdubbel – dit was nodig om die ontwerpafdeling te skaal en die prosesse van die skep en oordrag van uitlegte vir ontwikkeling te optimaliseer. Ons vermenigvuldig dit alles met die "dieretuin" van platforms wat ondersteun moet word, en ons kry 'n skyn van Babiloniese pandemonium, wat eenvoudig nie in staat is om dit "normaal te doen" en inkomste te genereer nie. Die ontwikkeling van platforms het dikwels parallel voortgegaan, en dieselfde funksionaliteit kon met 'n vertraging van 'n paar maande op verskillende platforms vrygestel word.


Afsonderlike uitlegstelle vir elke platform

Tradisioneel het ons begin met probleme wat 'n ontwerpstelsel sou help oplos en vereistes vir sy ontwerp geformuleer. Benewens die skep van 'n verenigde visuele taal, die verhoging van die spoed van uitleg en ontwikkeling, en die verbetering van die kwaliteit van die produk in die algemeen, was dit noodsaaklik om die ontwerp so veel as moontlik te verenig. Dit is nodig sodat die ontwikkeling van funksionaliteit op al ons platforms gelyktydig moontlik word: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - sonder om aan elkeen afsonderlik te werk. En ons het dit gedoen!

Ontwerp → data

Toe die fundamentele ooreenkomste tussen die produk- en ontwikkelingsafdelings bereik is, het ons gaan sit om 'n tegnologiestapel te kies en die besonderhede van die hele proses uit te werk - van uitleg tot vrystelling. Om die proses van die oordrag van die ontwerp na ontwikkeling ten volle te outomatiseer, het ons die opsie ondersoek om komponentparameters direk vanaf Sketch-lêers met uitlegte te ontleed. Dit het geblyk dat dit 'n komplekse en gevaarlike onderneming was om die stukkies kode te vind wat ons benodig en die parameters wat ons nodig gehad het te onttrek. Eerstens sal ontwerpers uiters versigtig moet wees om alle lae van die bronkode te benoem, tweedens werk dit net vir die eenvoudigste komponente, en derdens stel afhanklikheid van iemand anders se tegnologie en kodestruktuur van die oorspronklike Sketch-uitleg die toekoms van die hele projek. Ons het besluit om outomatisering in hierdie gebied te laat vaar. Dit is hoe die eerste persoon in die ontwerpstelselspan verskyn het, wie se insette ontwerpuitlegte is, en die uitset is data wat al die parameters van die komponente beskryf en hiërargies georden volgens die atoomontwerpmetodologie.

Die enigste ding wat oorgebly het om te doen was waar en hoe om die data te stoor, hoe om dit na ontwikkeling oor te dra en hoe om dit in ontwikkeling te interpreteer op al die platforms wat ons ondersteun. Die aand het opgehou om traag te wees... Die resultaat van gereelde vergaderings van die werkgroep bestaande uit ontwerpers en spanleiers van elke platform was die ooreenkoms oor die volgende.

Ons ontleed die visuele handmatig in atoomelemente: lettertipes, kleure, deursigtigheid, inkepings, afrondings, ikone, prente en duur vir animasies. En ons versamel uit hierdie knoppies, invoere, merkblokkies, bankkaartlegstukke, ens. Ons ken nie-semantiese name toe aan die style van enige van die vlakke, behalwe vir ikone, byvoorbeeld name van stede, name van nimfe, Pokémon, motor handelsmerke... Daar is net een voorwaarde - die lys moet nie voor uitgeput word nie, hoe die style eindig - show moet gaan! Jy moet nie meegevoer raak met semantiek nie, sodat jy nie byvoorbeeld 'n middelknoppie tussen "klein" en "medium" hoef by te voeg nie.

Visuele taal

Ontwikkelaars is oorgelaat om te dink oor hoe om data te berg en oor te dra op 'n manier wat by alle platforms pas, en ontwerp moes koppelvlakelemente ontwerp wat goed kan lyk en effektief oor die hele vloot ondersteunde toestelle kan werk.

Voorheen het ons reeds daarin geslaag om die meeste van die ontwerpelemente in 'n toepassing vir Windows 10 te "toets", wat op daardie stadium 'n nuwe platform vir ons was, dit wil sê, dit het lewering en ontwikkeling "van nuuts af" vereis. Deur dit te teken, kon ons die meeste van die komponente voorberei en toets en verstaan ​​watter van hulle veronderstel was om in die toekomstige Eevee-ontwerpstelsel ingesluit te word. Sonder so 'n sandbox sou sulke ondervinding slegs deur 'n groot aantal iterasies op reeds werkende platforms verkry kon word, en dit sou meer as 'n jaar neem.

Die hergebruik van dieselfde komponente op verskillende platforms verminder die aantal uitlegte en die reeks data van die ontwerpstelsel aansienlik, so die ontwerp moes nog een probleem oplos, wat voorheen nie beskryf is in die praktyke van produkontwerp en -ontwikkeling nie - hoe, bv. kan 'n knoppie vir fone en tablette op TV's hergebruik word? En wat moet ons doen met die groottes van lettertipes en elemente op sulke verskillende platforms?

Dit was duidelik dat dit nodig was om 'n kruisplatform-modulêre rooster te ontwerp wat die teks- en elementgroottes wat ons benodig vir elke spesifieke platform sou stel. As 'n beginpunt vir die rooster het ons die grootte en aantal fliekplakkate gekies wat ons op 'n spesifieke skerm wil sien en, op grond hiervan, het ons 'n reël geformuleer vir die bou van roosterkolomme, mits die breedte van een kolom gelyk is na die breedte van die plakkaat.

Nou moet ons alle groot skerms na dieselfde uitleggrootte bring en hulle in 'n gemeenskaplike rooster pas. Apple TV en Roku is ontwerp in 'n grootte van 1920x1080, Android TV - 960x540, slim-TV's, afhangend van die verkoper, is dieselfde, maar soms 1280x720. Wanneer die toepassing weergegee en op Full HD-skerms vertoon word, word 960 vermenigvuldig met 2, 1280 word vermenigvuldig met 1,33, en 1920 word soos dit is uitgevoer.

Deur vervelige besonderhede oor te slaan, het ons tot die gevolgtrekking gekom dat in die algemeen alle skerms, insluitend televisieskerms, in terme van elemente en hul groottes, deur een ontwerpuitleg gedek word, en alle televisieskerms is 'n spesiale geval van die algemene kruisplatform-rooster, en bestaan ​​uit vyf of ses kolomme, soos 'n gemiddelde tablet of rekenaar. Wie belangstel in besonderhede, gaan in die kommentaar.

Enkele UI vir alle platforms

Nou, om 'n nuwe kenmerk te teken, hoef ons nie uitlegte vir elke platform te teken nie, plus aanpasbaarheidsopsies vir elk van hulle. Dit is genoeg om een ​​uitleg en die aanpasbaarheid daarvan vir alle platforms en toestelle van enige breedte te wys: fone - 320-599, alles anders - 600-1280.

Data → ontwikkeling

Natuurlik, so graag as wat ons 'n heeltemal verenigde ontwerp wil bereik, het elke platform sy eie unieke kenmerke. Alhoewel beide die web en Smart TV die ReactJS + TypeScript-stapel gebruik, loop die Smart TV-toepassing op verouderde WebKit- en Presto-kliënte en kan dus nie style met die web deel nie. En e-pos nuusbriewe word heeltemal gedwing om met tabeluitleg te werk. Terselfdertyd gebruik of beplan nie een van die nie-html-platforms om React Native of enige van sy analoë te gebruik nie, uit vrees vir prestasie-agteruitgang, aangesien ons te veel pasgemaakte uitlegte, versamelings met komplekse opdateringslogika, beelde en video's het. Daarom is die algemene skema om klaargemaakte CSS-style of React-komponente te lewer nie geskik vir ons nie. Daarom het ons besluit om data in JSON-formaat oor te dra en die waardes in 'n abstrakte verklarende vorm te beskryf.

Eiendom dus rounding: 8 Windows 10-toepassing word omgeskakel na CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Eiendom offsetTop: 12 dieselfde webkliënt in verskillende gevalle kan interpreteer as top, margin-top, padding-top of transform

Verklarendheid van die beskrywing impliseer ook dat indien die platform tegnies nie 'n eiendom of die waarde daarvan kan gebruik nie, dit dit kan ignoreer. Wat terminologie betref, het ons 'n soort Esperanto-taal gemaak: sommige is van Android geneem, sommige van SVG, sommige van CSS.

As u op 'n spesifieke platform elemente anders moet vertoon, het ons die vermoë geïmplementeer om die ooreenstemmende datagenerering in die vorm van 'n aparte JSON-lêer oor te dra. Byvoorbeeld, die "in fokus"-toestand vir Smart TV dikteer 'n verandering in die posisie van die teks onder die plakkaat, wat beteken vir hierdie platform sal hierdie komponent in die waarde van die "inkeep"-eienskap die 8 inkepingspunte bevat wat dit benodig. Alhoewel dit die infrastruktuur van die ontwerpstelsel bemoeilik, gee dit 'n bykomende mate van vryheid, wat ons die geleentheid laat om die visuele "ongelykheid" van die platforms self te bestuur, en nie gyselaar te wees vir die argitektuur wat ons geskep het nie.

Piktogramme

Ikonografie in 'n digitale produk is altyd 'n lywige en nie die eenvoudigste subprojek nie, wat dikwels 'n aparte ontwerper vereis. Daar is altyd baie glife, elkeen van hulle het verskeie groottes en kleure, en platforms benodig hulle gewoonlik in verskillende formate. Oor die algemeen was daar geen rede om dit alles nie in die ontwerpstelsel te plaas nie.

Gliewe word in SVG-vektorformaat gelaai, en kleurwaardes word outomaties met veranderlikes vervang. Kliënttoepassings kan dit gereed ontvang om te gebruik - in enige formaat en kleur.

Voorskou

Bo en behalwe die JSON-data, het ons 'n hulpmiddel geskryf om komponente voor te bekyk - 'n JS-toepassing wat JSON-data op die vlug deur sy opmaak- en stylgenerators deurgee, en verskeie variasies van elke komponent in die blaaier vertoon. In wese is voorskou presies dieselfde kliënt as platformtoepassings en werk dit met dieselfde data.

Die maklikste manier om te verstaan ​​hoe 'n spesifieke komponent werk, is om daarmee te kommunikeer. Daarom het ons nie gereedskap soos Storybook gebruik nie, maar 'n interaktiewe voorskou gemaak - jy kan aanraak, wys, klik... Wanneer 'n nuwe komponent by die ontwerpstelsel gevoeg word, verskyn dit in die voorskou sodat platforms iets het om op te fokus wanneer dit te implementeer.

Dokumentasie

Gebaseer op die data wat aan die platforms verskaf word in die vorm van JSON, word dokumentasie vir die komponente outomaties gegenereer. 'N Lys van eiendomme en moontlike tipes waardes in elk van hulle word beskryf. Na outo-generering kan die inligting met die hand opgeklaar word en 'n teksbeskrywing kan bygevoeg word. Die voorskou en dokumentasie word op die vlak van elke komponent na mekaar verwys, en alle inligting wat in die dokumentasie ingesluit is, is beskikbaar vir ontwikkelaars in die vorm van bykomende JSON-lêers.

Deprecator

Nog 'n noodsaaklikheid was die vermoë om bestaande komponente met verloop van tyd te vervang en op te dateer. Die ontwerpstelsel het geleer om ontwikkelaars te vertel watter eiendomme of selfs hele komponente nie gebruik kan word nie en dit te verwyder sodra dit nie meer op alle platforms gebruik word nie. Daar is nog baie "hande" arbeid in hierdie proses, maar ons staan ​​nie stil nie.

Kliëntontwikkeling

Ongetwyfeld was die mees komplekse stadium die interpretasie van ontwerpstelseldata in die kode van alle platforms wat ons ondersteun. As byvoorbeeld modulêre roosters op die web nie iets nuuts is nie, dan het ontwikkelaars van inheemse mobiele toepassings vir iOS en Android hard gewerk voordat hulle uitgevind het hoe om daarmee saam te leef.

Om iOS-toepassingskerms uit te lê, gebruik ons ​​twee basiese meganismes wat deur iviUIKit verskaf word: gratis uitleg van elemente en uitleg van versamelings elemente. Ons gebruik VIPER, en alle interaksie met iviUIKit is gekonsentreer in View, en die meeste interaksie met Apple UIKit is gekonsentreer in iviUIKit. Die groottes en rangskikking van elemente word gespesifiseer in terme van kolomme en sintaktiese strukture wat bo-op die inheemse iOS SDK-beperkings werk, wat hulle meer prakties maak. Dit het veral ons lewe vereenvoudig wanneer ons met UICollectionView werk. Ons het verskeie pasgemaakte omhulsels vir uitlegte geskryf, insluitend redelik komplekse. Daar was 'n minimum kliëntkode en dit het verklarend geword.

Om style in die Android-projek te genereer, gebruik ons ​​Gradle, wat die ontwerpstelseldata in style in XML-formaat verander. Terselfdertyd het ons verskeie kragopwekkers van verskillende vlakke:

• Basies. Die data van primitiewe vir hoërvlak-opwekkers word ontleed.
• Hulpbron. Laai prente, ikone en ander grafika af.
• Komponent. Dit word vir elke komponent geskryf, wat beskryf watter eienskappe en hoe om dit in style te vertaal.

Toepassingsvrystellings

Nadat ontwerpers 'n nuwe komponent geteken het of 'n bestaande een herontwerp het, word hierdie veranderinge in die ontwerpstelsel ingevoer. Die ontwikkelaars van elke platform verfyn hul kodegenerering om die veranderinge te ondersteun. Hierna kan dit gebruik word in die implementering van nuwe funksionaliteit waar hierdie komponent benodig word. Interaksie met die ontwerpstelsel vind dus nie in reële tyd plaas nie, maar slegs ten tyde van die samestelling van nuwe vrystellings. Hierdie benadering maak ook voorsiening vir beter beheer oor die data-oordragproses en verseker kodefunksionaliteit in kliëntontwikkelingsprojekte.

Resultate van

Dit is 'n jaar sedert die ontwerpstelsel deel geword het van die infrastruktuur wat die ontwikkeling van die Ivy aanlyn bioskoop ondersteun, en ons kan reeds 'n paar gevolgtrekkings maak:

• Dit is 'n groot en komplekse projek wat konstante toegewyde hulpbronne vereis.
• Dit het ons in staat gestel om ons eie unieke kruis-platform visuele taal te skep wat aan die doelwitte van die aanlyn videodiens voldoen.
• Ons het nie meer platforms wat visueel en funksioneel agterbly nie.

Voorskou van Ivy-ontwerpstelselkomponente - design.ivi.ru

Bron: will.com