Dal kit UI al sistema di progettazione

Esperienza cinematografica online di Ivy

Quando all’inizio del 2017 abbiamo pensato per la prima volta di creare il nostro sistema di delivery design-to-code, molti ne parlavano già e alcuni addirittura lo stavano facendo. Tuttavia, fino ad oggi si sa poco sull'esperienza di creazione di sistemi di progettazione multipiattaforma e non esistono ricette chiare e comprovate che descrivano tecnologie e metodi per tale trasformazione del processo di implementazione del progetto in un prodotto già funzionante. E per “componenti del codice” spesso si intendono cose molto diverse.

Nel frattempo, anno dopo anno, l'azienda ha raddoppiato il personale: era necessario ampliare il reparto di progettazione e ottimizzare i processi di creazione e trasferimento dei layout per lo sviluppo. Moltiplichiamo tutto questo per lo “zoo” di piattaforme che devono essere supportate, e otteniamo una parvenza di pandemonio babilonese, che semplicemente non è in grado di “farlo normalmente” e generare reddito. Lo sviluppo delle piattaforme spesso procedeva in parallelo e la stessa funzionalità poteva essere rilasciata su piattaforme diverse con un ritardo di diversi mesi.


Set di layout separati per ciascuna piattaforma

Tradizionalmente, si iniziava con i problemi che un sistema di progettazione avrebbe aiutato a risolvere e si formulavano i requisiti per la sua progettazione. Oltre a creare un linguaggio visivo unificato, aumentare la velocità di layout e sviluppo e migliorare la qualità complessiva del prodotto, era fondamentale unificare il più possibile il design. Ciò è necessario affinché lo sviluppo delle funzionalità diventi possibile su tutte le nostre piattaforme contemporaneamente: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - senza lavorare su ciascuna di esse separatamente. E lo abbiamo fatto!

Progettazione → dati

Una volta raggiunti gli accordi fondamentali tra i reparti prodotto e sviluppo, ci siamo seduti per selezionare uno stack tecnologico ed elaborare i dettagli dell'intero processo, dal layout al rilascio. Per automatizzare completamente il processo di trasferimento della progettazione allo sviluppo, abbiamo esplorato la possibilità di analizzare i parametri dei componenti direttamente dai file di schizzo con layout. Si è scoperto che trovare i pezzi di codice di cui avevamo bisogno ed estrarre i parametri di cui avevamo bisogno era un'impresa complessa e pericolosa. In primo luogo, i progettisti dovranno prestare estrema attenzione nel nominare tutti gli strati del codice sorgente, in secondo luogo, questo funziona solo per i componenti più semplici e, in terzo luogo, la dipendenza dalla tecnologia di qualcun altro e dalla struttura del codice del layout originale di Sketch mette a repentaglio il futuro dell'intero progetto. Abbiamo deciso di abbandonare l'automazione in questo settore. È così che è apparsa la prima persona nel team del sistema di progettazione, il cui input sono i layout di progettazione e l'output sono i dati che descrivono tutti i parametri dei componenti e ordinati gerarchicamente secondo la metodologia di progettazione atomica.

L’unica cosa rimasta da fare era dove e come archiviare i dati, come trasferirli allo sviluppo e come interpretarli in fase di sviluppo su tutte le piattaforme che supportiamo. La serata ha smesso di essere languida... Il risultato delle riunioni periodiche del gruppo di lavoro composto da designer e responsabili di ciascuna piattaforma è stato l'accordo su quanto segue.

Analizziamo manualmente l'immagine in elementi atomici: caratteri, colori, trasparenza, rientri, arrotondamenti, icone, immagini e durate per le animazioni. E da questi raccogliamo pulsanti, input, caselle di controllo, widget di carte bancarie, ecc. Assegniamo nomi non semantici agli stili di qualsiasi livello, ad eccezione delle icone, ad esempio nomi di città, nomi di ninfe, Pokemon, auto marchi... C'è solo una condizione: l'elenco non deve essere esaurito prima, come finiscono gli stili: lo spettacolo deve finire! Non dovresti lasciarti trasportare dalla semantica, in modo da non dover aggiungere un pulsante centrale tra “piccolo” e “medio”, ad esempio.

Linguaggio visivo

Agli sviluppatori è stato lasciato il compito di pensare a come archiviare e trasferire i dati in modo adatto a tutte le piattaforme, mentre il design ha dovuto progettare elementi dell'interfaccia che potessero avere un bell'aspetto e funzionare in modo efficace sull'intero parco di dispositivi supportati.

In precedenza eravamo già riusciti a “testare” la maggior parte degli elementi di design in un’applicazione per Windows 10, che a quel tempo era per noi una nuova piattaforma, cioè richiedeva rendering e sviluppo “da zero”. Disegnandolo abbiamo potuto preparare e testare la maggior parte dei componenti e capire quali di essi avrebbero dovuto essere inclusi nel futuro sistema di progettazione di Eevee. Senza tale sandbox, tale esperienza potrebbe essere ottenuta solo attraverso un gran numero di iterazioni su piattaforme già funzionanti, e ciò richiederebbe più di un anno.

Il riutilizzo degli stessi componenti su piattaforme diverse riduce significativamente il numero di layout e la serie di dati del sistema di progettazione, quindi il progetto ha dovuto risolvere un ulteriore problema, precedentemente non descritto nelle pratiche di progettazione e sviluppo del prodotto: come, ad esempio, è possibile riutilizzare un pulsante per telefoni e tablet sui televisori? E cosa dovremmo fare con le dimensioni dei caratteri e degli elementi su piattaforme così diverse?

Ovviamente, era necessario progettare una griglia modulare multipiattaforma che impostasse le dimensioni del testo e degli elementi di cui avevamo bisogno per ciascuna piattaforma specifica. Come punto di partenza per la griglia, abbiamo scelto la dimensione e il numero di locandine dei film che vogliamo vedere su un particolare schermo e, in base a ciò, abbiamo formulato una regola per costruire le colonne della griglia, a condizione che la larghezza di una colonna sia uguale alla larghezza del poster.

Ora dobbiamo portare tutti gli schermi di grandi dimensioni alla stessa dimensione di layout e inserirli in una griglia comune. Apple TV e Roku sono progettati nella dimensione 1920x1080, Android TV - 960x540, le Smart TV, a seconda del fornitore, sono le stesse, ma a volte 1280x720. Quando l'app viene renderizzata e visualizzata su schermi Full HD, 960 viene moltiplicato per 2, 1280 viene moltiplicato per 1,33 e 1920 viene visualizzato così com'è.

Tralasciando i dettagli noiosi, siamo giunti alla conclusione che in generale tutti gli schermi, compresi gli schermi televisivi, in termini di elementi e loro dimensioni, sono coperti da un unico layout di progettazione, e tutti gli schermi televisivi sono un caso speciale della griglia generale multipiattaforma, e sono costituiti da cinque o sei colonne, come un tablet o un desktop medio. Chi è interessato ai dettagli, vada nei commenti.

Unica interfaccia utente per tutte le piattaforme

Ora, per disegnare una nuova funzionalità, non abbiamo bisogno di disegnare layout per ciascuna piattaforma, oltre a opzioni di adattabilità per ciascuna di esse. È sufficiente mostrare un layout e la sua adattabilità per tutte le piattaforme e dispositivi di qualsiasi larghezza: telefoni - 320-599, tutto il resto - 600-1280.

Dati → sviluppo

Naturalmente, per quanto vorremmo ottenere un design completamente unificato, ogni piattaforma ha le sue caratteristiche uniche. Anche se sia il Web che Smart TV utilizzano lo stack ReactJS + TypeScript, l'app Smart TV viene eseguita su client WebKit e Presto legacy e pertanto non può condividere stili con il Web. E le newsletter via email sono completamente costrette a funzionare con il layout tabellare. Allo stesso tempo, nessuna delle piattaforme non html utilizza o prevede di utilizzare React Native o uno qualsiasi dei suoi analoghi, temendo un degrado delle prestazioni, poiché abbiamo troppi layout personalizzati, raccolte con logica di aggiornamento complessa, immagini e video. Pertanto, lo schema comune di fornire stili CSS o componenti React già pronti non è adatto a noi. Pertanto, abbiamo deciso di trasmettere i dati in formato JSON, descrivendo i valori in forma dichiarativa astratta.

Quindi proprietà rounding: 8 L'app Windows 10 viene convertita in CornerRadius="8", ragnatela - border-radius: 8px, Androide- android:radius="8dp", iOS- self.layer.cornerRadius = 8.0.
Proprietà offsetTop: 12 lo stesso client web in casi diversi può interpretare come top, margin-top, padding-top o transform

La dichiaratività della descrizione implica anche che se la piattaforma tecnicamente non può utilizzare una proprietà o il suo valore, può ignorarla. Dal punto di vista terminologico, abbiamo creato una sorta di linguaggio esperanto: alcuni sono stati presi da Android, altri da SVG, altri da CSS.

Se su una particolare piattaforma è necessario visualizzare gli elementi in modo diverso, abbiamo implementato la possibilità di trasferire la generazione di dati corrispondente sotto forma di un file JSON separato. Ad esempio, lo stato "a fuoco" per Smart TV impone un cambiamento nella posizione del testo sotto il poster, il che significa che per questa piattaforma questo componente nel valore della proprietà "indent" conterrà gli 8 punti di rientro di cui ha bisogno. Sebbene ciò complichi l'infrastruttura del sistema di progettazione, offre un ulteriore grado di libertà, lasciandoci l'opportunità di gestire noi stessi la "dissomiglianza" visiva delle piattaforme e di non essere ostaggio dell'architettura che abbiamo creato.

Pittogrammi

L'iconografia in un prodotto digitale è sempre un sottoprogetto voluminoso e non il più semplice, che spesso richiede un designer separato. Ci sono sempre molti glifi, ognuno di essi ha diverse dimensioni e colori e le piattaforme di solito ne hanno bisogno in diversi formati. In generale, non c'era motivo di non inserire tutto questo nel sistema di progettazione.

I glifi vengono caricati nel formato vettoriale SVG e i valori dei colori vengono automaticamente sostituiti con variabili. Le applicazioni client possono riceverli pronti per l'uso, in qualsiasi formato e colore.

anteprima

Oltre ai dati JSON, abbiamo scritto uno strumento per l'anteprima dei componenti: un'applicazione JS che trasmette i dati JSON al volo attraverso i suoi generatori di markup e stili e visualizza varie variazioni di ciascun componente nel browser. Essenzialmente, l'anteprima è esattamente lo stesso client delle applicazioni della piattaforma e funziona con gli stessi dati.

Il modo più semplice per capire come funziona un particolare componente è interagire con esso. Pertanto, non abbiamo utilizzato strumenti come Storybook, ma abbiamo creato un'anteprima interattiva: puoi toccare, puntare, fare clic... Quando aggiungi un nuovo componente al sistema di progettazione, appare nell'anteprima in modo che le piattaforme abbiano qualcosa su cui concentrarsi quando implementandolo.

Documentazione

Sulla base dei dati forniti alle piattaforme sotto forma di JSON, viene generata automaticamente la documentazione per i componenti. Viene descritto un elenco di proprietà e possibili tipi di valori in ciascuna di esse. Dopo la generazione automatica, le informazioni possono essere chiarite manualmente e può essere aggiunta una descrizione testuale. L'anteprima e la documentazione presentano riferimenti incrociati tra loro a livello di ciascun componente e tutte le informazioni incluse nella documentazione sono disponibili per gli sviluppatori sotto forma di file JSON aggiuntivi.

Deprecatore

Un'altra necessità era la possibilità di sostituire e aggiornare nel tempo i componenti esistenti. Il sistema di progettazione ha imparato a dire agli sviluppatori quali proprietà o addirittura interi componenti non possono essere utilizzati e a rimuoverli non appena non vengono più utilizzati su tutte le piattaforme. C’è ancora molto lavoro “manuale” in questo processo, ma non restiamo fermi.

Sviluppo del cliente

Indubbiamente la fase più complessa è stata l’interpretazione dei dati del sistema di progettazione nel codice di tutte le piattaforme che supportiamo. Se, ad esempio, le griglie modulari sul web non sono qualcosa di nuovo, gli sviluppatori di applicazioni mobili native per iOS e Android hanno lavorato duro prima di capire come conviverci.

Per il layout delle schermate delle applicazioni iOS, utilizziamo due meccanismi di base forniti da iviUIKit: layout libero di elementi e layout di raccolte di elementi. Usiamo VIPER e tutta l'interazione con iviUIKit è concentrata in View e la maggior parte dell'interazione con Apple UIKit è concentrata in iviUIKit. Le dimensioni e la disposizione degli elementi sono specificate in termini di colonne e strutture sintattiche che funzionano in aggiunta ai vincoli nativi dell'SDK iOS, rendendoli più pratici. Ciò ci ha particolarmente semplificato la vita quando lavoriamo con UICollectionView. Abbiamo scritto diversi wrapper personalizzati per layout, inclusi quelli piuttosto complessi. C'era un minimo di codice cliente ed è diventato dichiarativo.

Per generare stili nel progetto Android, utilizziamo Gradle, trasformando i dati del sistema di progettazione in stili in formato XML. Allo stesso tempo, abbiamo diversi generatori di vari livelli:

• Di base. Vengono analizzati i dati delle primitive per i generatori di livello superiore.
• Risorsa. Scarica immagini, icone e altri elementi grafici.
• Componente. Sono scritti per ciascun componente, che descrivono quali proprietà e come tradurle in stili.

Rilasci dell'applicazione

Dopo che i progettisti hanno disegnato un nuovo componente o ne hanno riprogettato uno esistente, queste modifiche vengono inserite nel sistema di progettazione. Gli sviluppatori di ciascuna piattaforma stanno perfezionando la generazione del codice per supportare i cambiamenti. Successivamente, può essere utilizzato nell'implementazione di nuove funzionalità dove questo componente è necessario. Pertanto, l'interazione con il sistema di progettazione non avviene in tempo reale, ma solo al momento dell'assemblaggio di nuove versioni. Questo approccio consente inoltre un migliore controllo sul processo di trasferimento dei dati e garantisce la funzionalità del codice nei progetti di sviluppo del client.

Risultati di

È passato un anno da quando il design system è diventato parte dell'infrastruttura a supporto dello sviluppo del cinema online Ivy, e possiamo già trarre alcune conclusioni:

• Si tratta di un progetto ampio e complesso che richiede costanti risorse dedicate.
• Ciò ci ha permesso di creare il nostro linguaggio visivo multipiattaforma unico che soddisfa gli obiettivi del servizio video online.
• Non abbiamo più piattaforme in ritardo dal punto di vista visivo e funzionale.

Anteprima dei componenti del sistema Ivy design - design.ivi.ru

Fonte: habr.com