Del kit d'IU al sistema de disseny

Experiència de cinema en línia Ivy

Quan a principis del 2017 vam pensar per primera vegada a crear el nostre propi sistema de lliurament de disseny a codi, molts ja en parlaven i alguns fins i tot ho feien. No obstant això, avui dia se sap poc sobre l'experiència de la construcció de sistemes de disseny multiplataforma, i no hi ha receptes clares i provades que descriguin tecnologies i mètodes per a aquesta transformació del procés d'implementació del disseny en un producte que ja funciona. I per "components del codi" sovint volen dir coses molt diferents.

Mentrestant, l'empresa va duplicar la seva plantilla any rere any: va ser necessari escalar el departament de disseny i optimitzar els processos de creació i transferència de dissenys per al desenvolupament. Multipliquem tot això pel "zoològic" de plataformes que cal donar suport, i obtenim una aparença de pandemoni babilònic, que simplement no és capaç de "fer-ho amb normalitat" i generar ingressos. El desenvolupament de les plataformes sovint va procedir en paral·lel, i la mateixa funcionalitat es podia llançar en diferents plataformes amb un retard de diversos mesos.


Conjunts de disseny separats per a cada plataforma

Tradicionalment, vam començar amb problemes que un sistema de disseny ajudaria a resoldre i vam formular els requisits per al seu disseny. A més de crear un llenguatge visual unificat, augmentar la velocitat de disseny i desenvolupament i millorar la qualitat del producte en general, era vital unificar el disseny tant com fos possible. Això és necessari perquè el desenvolupament de la funcionalitat sigui possible a totes les nostres plataformes simultàniament: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku, sense treballar en cadascuna d'elles per separat. I ho vam fer!

Disseny → dades

Quan es van arribar als acords fonamentals entre els departaments de producte i desenvolupament, ens vam asseure per seleccionar una pila de tecnologia i elaborar els detalls de tot el procés, des del disseny fins al llançament. Per automatitzar completament el procés de transferència del disseny al desenvolupament, vam explorar l'opció d'analitzar els paràmetres dels components directament des dels fitxers Sketch amb dissenys. Va resultar que trobar les peces de codi que necessitàvem i extreure els paràmetres que necessitàvem era una tasca complexa i perillosa. En primer lloc, els dissenyadors hauran de ser extremadament curosos a l'hora d'anomenar totes les capes del codi font, en segon lloc, això només funciona per als components més senzills i, en tercer lloc, la dependència de la tecnologia i l'estructura del codi d'una altra persona del disseny original de Sketch posa en perill el futur de tot el conjunt. projecte. Vam decidir abandonar l'automatització en aquesta àrea. Així és com va aparèixer la primera persona a l'equip del sistema de disseny, l'entrada del qual són les maquetes de disseny, i la sortida són dades que descriuen tots els paràmetres dels components i ordenats jeràrquicament segons la metodologia de disseny atòmic.

L'únic que quedava per fer era on i com emmagatzemar les dades, com transferir-les al desenvolupament i com interpretar-les en desenvolupament a totes les plataformes que donem suport. La vetllada va deixar de ser lànguida... El resultat de les reunions periòdiques del grup de treball format per dissenyadors i caps d'equip de cada plataforma va ser l'acord sobre el següent.

Analitzem manualment el visual en elements atòmics: tipus de lletra, colors, transparència, sagnats, arrodoniments, icones, imatges i durades per a les animacions. I recollim d'això botons, entrades, caselles de selecció, ginys de targetes bancàries, etc. Assignem noms no semàntics als estils de qualsevol dels nivells, excepte icones, per exemple, noms de ciutats, noms de nimfes, Pokémon, cotxes. marques... Només hi ha una condició: la llista no s'ha d'esgotar abans, com acaben els estils, l'espectacle ha d'anar! No us hauríeu de deixar portar per la semàntica, de manera que no haureu d'afegir un botó central entre "petit" i "mitjà", per exemple.

Llenguatge visual

Els desenvolupadors havien de pensar com emmagatzemar i transferir dades d'una manera que s'adapti a totes les plataformes, i el disseny havia de dissenyar elements d'interfície que poguessin tenir un bon aspecte i funcionar de manera eficaç a tota la flota de dispositius compatibles.

Anteriorment, ja havíem aconseguit “provar” la majoria dels elements de disseny en una aplicació per a Windows 10, que en aquell moment era una plataforma nova per a nosaltres, és a dir, requeria renderització i desenvolupament “des de zero”. En dibuixar-lo, vam poder preparar i provar la majoria dels components i entendre quins d'ells s'havien d'incloure en el futur sistema de disseny d'Eevee. Sense aquest sandbox, aquesta experiència només es podria obtenir mitjançant un gran nombre d'iteracions en plataformes que ja funcionen, i això trigaria més d'un any.

La reutilització dels mateixos components en diferents plataformes redueix significativament el nombre de dissenys i la matriu de dades del sistema de disseny, de manera que el disseny havia de resoldre un problema més, no descrit anteriorment a les pràctiques de disseny i desenvolupament de productes: com, per exemple, es pot reutilitzar un botó per a telèfons i tauletes als televisors? I què hem de fer amb les mides de tipus de lletra i elements en plataformes tan diferents?

Òbviament, era necessari dissenyar una graella modular multiplataforma que establissin les mides de text i d'elements que necessitàvem per a cada plataforma específica. Com a punt de partida de la graella, vam triar la mida i el nombre de pòsters de pel·lícules que volem veure en una pantalla concreta i, a partir d'això, vam formular una regla per construir columnes de graella, sempre que l'amplada d'una columna sigui igual. a l'amplada del cartell.

Ara hem de portar totes les pantalles grans a la mateixa mida de disseny i encaixar-les en una graella comuna. Apple TV i Roku estan dissenyats amb una mida de 1920 x 1080, Android TV - 960 x 540, els televisors intel·ligents, segons el venedor, són els mateixos, però de vegades 1280 x 720. Quan l'aplicació es representa i es mostra a pantalles Full HD, 960 es multiplica per 2, 1280 es multiplica per 1,33 i 1920 es multiplica tal qual.

Saltant detalls avorrits, vam arribar a la conclusió que, en general, totes les pantalles, incloses les pantalles de televisió, quant als elements i les seves mides, estan cobertes per un disseny de disseny i totes les pantalles de televisió són un cas especial de la graella general multiplataforma, i consta de cinc o sis columnes, com una tauleta o escriptori mitjana. Qui estigui interessat en els detalls, aneu als comentaris.

UI única per a totes les plataformes

Ara, per dibuixar una funció nova, no cal dibuixar dissenys per a cada plataforma, a més d'opcions d'adaptabilitat per a cadascuna d'elles. N'hi ha prou amb mostrar un disseny i la seva adaptabilitat per a totes les plataformes i dispositius de qualsevol amplada: telèfons - 320-599, tota la resta - 600-1280.

Dades → desenvolupament

Per descomptat, per molt que ens agradaria aconseguir un disseny completament unificat, cada plataforma té les seves pròpies característiques úniques. Tot i que tant el web com el Smart TV utilitzen la pila ReactJS + TypeScript, l'aplicació Smart TV s'executa amb clients WebKit i Presto heretats i, per tant, no pot compartir estils amb el web. I els butlletins de correu electrònic estan completament obligats a treballar amb un disseny tabular. Al mateix temps, cap de les plataformes no html utilitza ni preveu utilitzar React Native ni cap dels seus anàlegs, tement la degradació del rendiment, ja que tenim massa dissenys personalitzats, col·leccions amb lògica d'actualització complexa, imatges i vídeos. Per tant, l'esquema comú de lliurar estils CSS ja fets o components React no és adequat per a nosaltres. Per tant, vam decidir transmetre dades en format JSON, descrivint els valors en forma declarativa abstracta.

Així, propietat rounding: 8 L'aplicació Windows 10 es converteix en CornerRadius="8", web - border-radius: 8px, Android - android:radius="8dp", iOS - self.layer.cornerRadius = 8.0.
Propietat offsetTop: 12 el mateix client web en diferents casos pot interpretar com top, margin-top, padding-top o transform

La declaració de la descripció també implica que si la plataforma tècnicament no pot utilitzar una propietat o el seu valor, pot ignorar-la. Pel que fa a la terminologia, vam fer una mena de llenguatge esperanto: alguns van ser extrets d'Android, alguns d'SVG, alguns de CSS.

Si en una plataforma concreta necessiteu mostrar elements de manera diferent, hem implementat la possibilitat de transferir la generació de dades corresponent en forma d'un fitxer JSON independent. Per exemple, l'estat "en focus" per a Smart TV dicta un canvi en la posició del text sota el pòster, el que significa que per a aquesta plataforma aquest component del valor de la propietat "sagnia" contindrà els 8 punts de sagnat que necessita. Tot i que això complica la infraestructura del sistema de disseny, atorga un grau addicional de llibertat, deixant-nos l'oportunitat de gestionar nosaltres mateixos la "dissimilitat" visual de les plataformes i no ser ostatge de l'arquitectura que vam crear.

Pictogrames

La iconografia en un producte digital és sempre un subprojecte voluminós i no el més simple, sovint requereix un dissenyador independent. Sempre hi ha molts glifos, cadascun d'ells té diverses mides i colors, i les plataformes solen necessitar-los en diferents formats. En general, no hi havia cap raó per no posar tot això en el sistema de disseny.

Els glifos es carreguen en format vectorial SVG i els valors de color es substitueixen automàticament per variables. Les aplicacions de client les poden rebre llestes per al seu ús, en qualsevol format i color.

Vista prèvia

A més de les dades JSON, vam escriure una eina per a la vista prèvia dels components: una aplicació JS que passa dades JSON sobre la marxa a través dels seus generadors d'estil i marcatge i mostra diverses variacions de cada component al navegador. Bàsicament, la vista prèvia és exactament el mateix client que les aplicacions de la plataforma i funciona amb les mateixes dades.

La manera més senzilla d'entendre com funciona un component concret és interactuant-hi. Per tant, no hem utilitzat eines com Storybook, sinó que hem fet una vista prèvia interactiva: pots tocar, apuntar, fer clic... Quan afegeixes un nou component al sistema de disseny, apareix a la vista prèvia perquè les plataformes tinguin alguna cosa en què centrar-se quan implementant-lo.

Registres

A partir de les dades subministrades a les plataformes en forma de JSON, es genera automàticament la documentació dels components. Es descriu una llista de propietats i possibles tipus de valors en cadascuna d'elles. Després de la generació automàtica, la informació es pot aclarir manualment i es pot afegir una descripció de text. La previsualització i la documentació tenen referències creuades entre si a nivell de cada component, i tota la informació inclosa a la documentació està disponible per als desenvolupadors en forma de fitxers JSON addicionals.

Deprecator

Una altra necessitat era la possibilitat de substituir i actualitzar els components existents al llarg del temps. El sistema de disseny ha après a dir als desenvolupadors quines propietats o fins i tot components sencers no es poden utilitzar i eliminar-los tan bon punt deixin d'utilitzar-se a totes les plataformes. Encara hi ha molta feina "manual" en aquest procés, però no ens quedem quiets.

Desenvolupament del client

Sens dubte, l'etapa més complexa va ser la interpretació de les dades del sistema de disseny en el codi de totes les plataformes que donem suport. Si, per exemple, les quadrícules modulars al web no són una cosa nova, els desenvolupadors d'aplicacions mòbils natives per a iOS i Android van treballar molt abans d'esbrinar com viure-hi.

Per dissenyar les pantalles d'aplicacions iOS, utilitzem dos mecanismes bàsics proporcionats per iviUIKit: disseny lliure d'elements i disseny de col·leccions d'elements. Utilitzem VIPER i tota la interacció amb iviUIKit es concentra a View, i la majoria de la interacció amb Apple UIKit es concentra a iviUIKit. Les mides i la disposició dels elements s'especifiquen en termes de columnes i estructures sintàctiques que funcionen per sobre de les restriccions natives de l'SDK d'iOS, fent-les més pràctiques. Això ens va simplificar la vida especialment quan treballem amb UICollectionView. Hem escrit diversos embolcalls personalitzats per a dissenys, inclosos els força complexos. Hi havia un mínim de codi de client i es va convertir en declaratiu.

Per generar estils al projecte Android, utilitzem Gradle, convertint les dades del sistema de disseny en estils en format XML. Al mateix temps, disposem de diversos generadors de diferents nivells:

• Bàsic. S'analitza les dades de primitives per a generadors de nivell superior.
• Recurs. Baixeu imatges, icones i altres gràfics.
• Component. S'escriuen per a cada component, que descriu quines propietats i com traduir-les en estils.

Alliberaments d'aplicacions

Després que els dissenyadors hagin dibuixat un component nou o redissenyat un d'existent, aquests canvis s'introdueixen al sistema de disseny. Els desenvolupadors de cada plataforma estan ajustant la seva generació de codi per donar suport als canvis. Després d'això, es pot utilitzar en la implementació de noves funcionalitats on es necessiti aquest component. Així, la interacció amb el sistema de disseny no es produeix en temps real, sinó només en el moment de muntar les noves versions. Aquest enfocament també permet un millor control sobre el procés de transferència de dades i garanteix la funcionalitat del codi en els projectes de desenvolupament de clients.

Resultats de

Ja fa un any que el sistema de disseny va passar a formar part de la infraestructura de suport al desenvolupament del cinema online Ivy, i ja podem treure algunes conclusions:

• Es tracta d'un projecte gran i complex que requereix recursos constants dedicats.
• Això ens va permetre crear el nostre propi llenguatge visual multiplataforma únic que compleix els objectius del servei de vídeo en línia.
• Ja no tenim plataformes endarrerides visualment i funcionalment.

Vista prèvia dels components del sistema de disseny Ivy - design.ivi.ru

Font: www.habr.com