Van UI-kit tot ontwerpsysteem

Ivy online bioscoopervaring

Toen we begin 2017 voor het eerst nadachten over het creëren van ons eigen design-to-code leveringssysteem, hadden velen het er al over en sommigen deden het zelfs. Tot op de dag van vandaag is er echter weinig bekend over de ervaring met het bouwen van platformonafhankelijke ontwerpsystemen, en er zijn geen duidelijke en bewezen recepten die technologieën en methoden beschrijven voor een dergelijke transformatie van het proces van ontwerpimplementatie naar een reeds werkend product. En met ‘componenten in de code’ bedoelen ze vaak heel verschillende dingen.

Ondertussen verdubbelde het bedrijf zijn personeelsbestand jaar na jaar - het was noodzakelijk om de ontwerpafdeling op te schalen en de processen voor het maken en overdragen van lay-outs voor ontwikkeling te optimaliseren. We vermenigvuldigen dit alles met de ‘dierentuin’ van platforms die moeten worden ondersteund, en we krijgen een schijn van een Babylonisch pandemonium, dat simpelweg niet in staat is om ‘het normaal te doen’ en inkomsten te genereren. De ontwikkeling van platforms verliep vaak parallel en dezelfde functionaliteit kon met een vertraging van enkele maanden op verschillende platforms worden uitgebracht.


Afzonderlijke lay-outsets voor elk platform

Traditioneel zijn we begonnen met problemen die een ontwerpsysteem zou helpen oplossen en formuleerden we eisen voor het ontwerp ervan. Naast het creëren van een uniforme beeldtaal, het verhogen van de snelheid van lay-out en ontwikkeling en het verbeteren van de kwaliteit van het product in het algemeen, was het van cruciaal belang om het ontwerp zoveel mogelijk te verenigen. Dit is nodig zodat de ontwikkeling van functionaliteit tegelijkertijd mogelijk wordt op al onze platforms: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - zonder aan elk van hen afzonderlijk te werken. En het is ons gelukt!

Ontwerp → gegevens

Toen de fundamentele overeenkomsten tussen de product- en ontwikkelingsafdelingen waren bereikt, gingen we om de tafel zitten om een ​​technologiestapel te selecteren en de details van het hele proces uit te werken - van lay-out tot release. Om het proces van het overbrengen van het ontwerp naar de ontwikkeling volledig te automatiseren, hebben we de mogelijkheid onderzocht om componentparameters rechtstreeks uit Sketch-bestanden met lay-outs te parseren. Het bleek dat het vinden van de stukjes code die we nodig hadden en het extraheren van de parameters die we nodig hadden een complexe en gevaarlijke onderneming was. Ten eerste zullen ontwerpers uiterst voorzichtig moeten zijn bij het benoemen van alle lagen van de broncode, ten tweede werkt dit alleen voor de eenvoudigste componenten, en ten derde brengt de afhankelijkheid van andermans technologie en codestructuur van de originele Sketch-lay-out de toekomst van de hele Sketch in gevaar. project. We hebben besloten de automatisering op dit gebied achterwege te laten. Dit is hoe de eerste persoon verscheen in het ontwerpsysteemteam, wiens input ontwerplay-outs is, en de output bestaat uit gegevens die alle parameters van de componenten beschrijven en hiërarchisch geordend volgens de atomaire ontwerpmethodologie.

Het enige wat we nog moesten doen was waar en hoe we de gegevens moesten opslaan, hoe we ze naar de ontwikkeling moesten overbrengen en hoe we ze tijdens de ontwikkeling moesten interpreteren op alle platforms die we ondersteunen. De avond was niet langer loom... Het resultaat van regelmatige bijeenkomsten van de werkgroep bestaande uit ontwerpers en teamleiders van elk platform was de overeenstemming over het volgende.

We ontleden het beeld handmatig in atomaire elementen: lettertypen, kleuren, transparantie, inspringingen, rondingen, pictogrammen, afbeeldingen en duur van animaties. En we verzamelen hieruit knoppen, invoer, selectievakjes, bankkaartwidgets, enz. We wijzen niet-semantische namen toe aan de stijlen van elk van de niveaus, behalve iconen, bijvoorbeeld namen van steden, namen van nimfen, Pokemon, auto merken... Er is maar één voorwaarde: de lijst mag niet eerder zijn uitgeput, hoe de stijlen eindigen - de show moet gaan! Je moet je niet laten meeslepen door semantiek, zodat je bijvoorbeeld geen middelste knop tussen ‘klein’ en ‘medium’ hoeft toe te voegen.

Beeldtaal

Ontwikkelaars moesten nadenken over hoe ze gegevens konden opslaan en overbrengen op een manier die geschikt was voor alle platforms, en het ontwerp moest interface-elementen ontwerpen die er goed uit konden zien en effectief konden werken op de hele vloot van ondersteunde apparaten.

Eerder waren we er al in geslaagd om de meeste ontwerpelementen te 'testen' in een applicatie voor Windows 10, wat op dat moment een nieuw platform voor ons was, dat wil zeggen dat het 'vanaf nul' moest worden gerenderd en ontwikkeld. Door het te tekenen, konden we de meeste componenten voorbereiden en testen en begrijpen welke ervan in het toekomstige Eevee-ontwerpsysteem zouden worden opgenomen. Zonder zo'n sandbox zou dergelijke ervaring alleen kunnen worden verkregen via een groot aantal iteraties op reeds werkende platforms, en dit zou meer dan een jaar duren.

Het hergebruiken van dezelfde componenten op verschillende platforms vermindert het aantal lay-outs en de reeks gegevens van het ontwerpsysteem aanzienlijk, dus het ontwerp moest nog een probleem oplossen dat voorheen niet werd beschreven in de praktijken van productontwerp en -ontwikkeling - hoe bijvoorbeeld Kan een knop voor telefoons en tablets worden hergebruikt op tv's? En wat moeten we doen met de grootte van lettertypen en elementen op zulke verschillende platforms?

Het was duidelijk dat het nodig was om een ​​platformonafhankelijk modulair raster te ontwerpen dat de tekst- en elementgroottes zou bepalen die we nodig hadden voor elk specifiek platform. Als uitgangspunt voor het raster hebben we het formaat en het aantal filmposters gekozen dat we op een bepaald scherm willen zien en op basis hiervan hebben we een regel geformuleerd voor het construeren van rasterkolommen, op voorwaarde dat de breedte van één kolom gelijk is tot de breedte van de poster.

Nu moeten we alle grote schermen naar dezelfde lay-outgrootte brengen en ze in een gemeenschappelijk raster plaatsen. Apple TV en Roku zijn ontworpen in een formaat van 1920x1080, Android TV - 960x540, Smart TV's zijn, afhankelijk van de leverancier, hetzelfde, maar soms 1280x720. Wanneer de app wordt weergegeven en weergegeven op Full HD-schermen, wordt 960 vermenigvuldigd met 2, 1280 wordt vermenigvuldigd met 1,33 en 1920 wordt uitgevoerd zoals het is.

Door saaie details over te slaan, kwamen we tot de conclusie dat in het algemeen alle schermen, inclusief televisieschermen, qua elementen en hun afmetingen onder één ontwerplay-out vallen, en dat alle televisieschermen een speciaal geval zijn van het algemene platformonafhankelijke raster. en bestaan ​​uit vijf of zes kolommen, zoals een gemiddelde tablet of desktop. Wie geïnteresseerd is in details, ga naar de reacties.

Eén gebruikersinterface voor alle platforms

Om een ​​nieuwe functie te tekenen, hoeven we geen lay-outs voor elk platform te tekenen, plus aanpassingsopties voor elk platform. Het is voldoende om één lay-out en de aanpasbaarheid ervan voor alle platforms en apparaten van elke breedte te laten zien: telefoons - 320-599, al het andere - 600-1280.

Gegevens → ontwikkeling

Hoe graag we ook een volledig uniform ontwerp willen bereiken, elk platform heeft natuurlijk zijn eigen unieke kenmerken. Hoewel zowel het web als Smart TV de ReactJS + TypeScript-stack gebruiken, draait de Smart TV-app op oudere WebKit- en Presto-clients en kan daarom geen stijlen delen met internet. En e-mailnieuwsbrieven worden volledig gedwongen om met een tabellarische lay-out te werken. Tegelijkertijd gebruikt geen van de niet-html-platforms React Native of een van zijn analogen, of is dit van plan te gebruiken, uit angst voor prestatieverlies, omdat we te veel aangepaste lay-outs, collecties met complexe updatelogica, afbeeldingen en video's hebben. Daarom is het gebruikelijke schema voor het leveren van kant-en-klare CSS-stijlen of React-componenten niet geschikt voor ons. Daarom hebben we besloten om gegevens in JSON-formaat te verzenden, waarbij de waarden in een abstracte declaratieve vorm worden beschreven.

Eigendom dus rounding: 8 Windows 10-app converteert naar CornerRadius="8", web- border-radius: 8px, Android- android:radius="8dp", iOS- self.layer.cornerRadius = 8.0.
Eigendom offsetTop: 12 dezelfde webclient in verschillende gevallen kan interpreteren als top, margin-top, padding-top of transform

Declarativiteit van de beschrijving impliceert ook dat als het platform technisch gezien een eigenschap of de waarde ervan niet kan gebruiken, het deze kan negeren. Qua terminologie hebben we een soort Esperanto-taal gemaakt: sommige zijn afkomstig van Android, sommige van SVG, sommige van CSS.

Als u op een bepaald platform elementen anders wilt weergeven, hebben wij de mogelijkheid geïmplementeerd om de bijbehorende gegevensgeneratie in de vorm van een afzonderlijk JSON-bestand over te dragen. De status 'in focus' voor Smart TV dicteert bijvoorbeeld een verandering in de positie van de tekst onder de poster, wat voor dit platform betekent dat dit onderdeel in de waarde van de eigenschap 'inspringen' de 8 inspringingspunten zal bevatten die het nodig heeft. Hoewel dit de infrastructuur van het ontwerpsysteem ingewikkelder maakt, geeft het een extra mate van vrijheid, waardoor we de mogelijkheid hebben om de visuele ‘ongelijkheid’ van de platforms zelf te beheren en niet gegijzeld te worden door de architectuur die we hebben gemaakt.

Pictogrammen

Iconografie in een digitaal product is altijd een omvangrijk en niet het eenvoudigste deelproject, waarvoor vaak een aparte ontwerper nodig is. Er zijn altijd veel glyphs, elk heeft verschillende maten en kleuren, en platforms hebben ze meestal in verschillende formaten nodig. Over het algemeen was er geen reden om dit allemaal niet in het ontwerpsysteem te verwerken.

Glyphs worden geladen in SVG-vectorformaat en kleurwaarden worden automatisch vervangen door variabelen. Klantapplicaties kunnen ze gebruiksklaar ontvangen - in elk formaat en kleur.

voorbeeld

Bovenop de JSON-gegevens hebben we een tool geschreven voor het bekijken van componenten: een JS-applicatie die JSON-gegevens on-the-fly doorgeeft aan de markup- en stijlgeneratoren, en verschillende varianten van elke component in de browser weergeeft. In wezen is preview precies dezelfde client als platformapplicaties en werkt het met dezelfde gegevens.

De eenvoudigste manier om te begrijpen hoe een bepaald onderdeel werkt, is door ermee te communiceren. Daarom hebben we geen tools zoals Storybook gebruikt, maar een interactieve preview gemaakt - je kunt aanraken, aanwijzen, klikken... Wanneer je een nieuwe component aan het ontwerpsysteem toevoegt, verschijnt deze in de preview, zodat platforms iets hebben om op te focussen wanneer het implementeren ervan.

Документация

Op basis van de data die in de vorm van JSON aan de platforms worden aangeleverd, wordt automatisch documentatie voor de componenten gegenereerd. Een lijst met eigenschappen en mogelijke typen waarden in elk ervan wordt beschreven. Na het automatisch genereren kan de informatie handmatig worden verduidelijkt en kan een tekstbeschrijving worden toegevoegd. Er wordt op het niveau van elke component naar elkaar verwezen tussen de preview en de documentatie, en alle informatie in de documentatie is beschikbaar voor ontwikkelaars in de vorm van aanvullende JSON-bestanden.

Afkeurer

Een andere noodzaak was de mogelijkheid om bestaande componenten in de loop van de tijd te vervangen en bij te werken. Het ontwerpsysteem heeft geleerd ontwikkelaars te vertellen welke eigenschappen of zelfs hele componenten niet kunnen worden gebruikt en deze te verwijderen zodra ze niet meer op alle platforms worden gebruikt. Er zit nog steeds veel ‘handwerk’ in dit proces, maar we staan ​​niet stil.

Ontwikkeling van de klant

De meest complexe fase was ongetwijfeld de interpretatie van ontwerpsysteemgegevens in de code van alle platforms die we ondersteunen. Als modulaire rasters op internet bijvoorbeeld niet iets nieuws zijn, dan hebben ontwikkelaars van native mobiele applicaties voor iOS en Android hard gewerkt voordat ze erachter kwamen hoe ze ermee moesten leven.

Om iOS-applicatieschermen op te maken, gebruiken we twee basismechanismen van iviUIKit: vrije lay-out van elementen en lay-out van verzamelingen elementen. We gebruiken VIPER en alle interactie met iviUIKit is geconcentreerd in View, en de meeste interactie met Apple UIKit is geconcentreerd in iviUIKit. De afmetingen en rangschikking van elementen worden gespecificeerd in termen van kolommen en syntactische structuren die bovenop de native iOS SDK-beperkingen werken, waardoor ze praktischer worden. Dit heeft ons leven vooral vereenvoudigd bij het werken met UICollectionView. We hebben verschillende aangepaste wrappers voor lay-outs geschreven, waaronder behoorlijk complexe. Er was een minimum aan clientcode en het werd declaratief.

Om stijlen in het Android-project te genereren, gebruiken we Gradle, waarbij de ontwerpsysteemgegevens worden omgezet in stijlen in XML-indeling. Tegelijkertijd hebben we verschillende generatoren van verschillende niveaus:

• Basic. De gegevens van primitieven voor generatoren van een hoger niveau worden geparseerd.
• Bron. Download afbeeldingen, pictogrammen en andere afbeeldingen.
• Onderdeel. Voor elk onderdeel zijn ze geschreven, waarin wordt beschreven welke eigenschappen en hoe deze in stijlen kunnen worden vertaald.

Applicatie-releases

Nadat ontwerpers een nieuw onderdeel hebben getekend of een bestaand onderdeel opnieuw hebben ontworpen, worden deze wijzigingen in het ontwerpsysteem ingevoerd. De ontwikkelaars van elk platform zijn bezig met het verfijnen van hun codegeneratie om de veranderingen te ondersteunen. Hierna kan het gebruikt worden bij de implementatie van nieuwe functionaliteit waar dit onderdeel nodig is. Interactie met het ontwerpsysteem vindt dus niet in realtime plaats, maar alleen op het moment dat nieuwe releases worden samengesteld. Deze aanpak zorgt ook voor een betere controle over het gegevensoverdrachtproces en zorgt voor codefunctionaliteit in klantontwikkelingsprojecten.

Resultaten van

Het is een jaar geleden dat het ontwerpsysteem onderdeel werd van de infrastructuur die de ontwikkeling van de Ivy online cinema ondersteunde, en we kunnen al enkele conclusies trekken:

• Dit is een groot en complex project dat voortdurend toegewijde middelen vereist.
• Hierdoor konden we onze eigen unieke cross-platform beeldtaal creëren die voldoet aan de doelstellingen van de online videodienst.
• We hebben niet langer visueel en functioneel achterblijvende platforms.

Preview van Ivy-ontwerpsysteemcomponenten - design.ivi.ru

Bron: www.habr.com