Du kit d'interface utilisateur au système de conception

Expérience de cinéma en ligne Ivy

Quand au début de 2017, nous avons d'abord pensé à créer notre propre système de conception de code, beaucoup en ont parlé et quelqu'un l'a même fait. Cependant, on sait peu de choses sur l'expérience de la construction de systèmes de conception multiplateforme à ce jour, et il n'y a pas de recettes claires et éprouvées qui décrivent les technologies et les méthodes pour une telle transformation du processus de mise en œuvre de la conception en un produit déjà fonctionnel. Et «composants dans le code» signifie souvent des choses très différentes.


Parallèlement, l'entreprise a doublé ses effectifs d'année en année - il a fallu faire évoluer le département de conception et optimiser les processus de création et de transfert des dispositions vers le développement. Nous multiplions tout cela par un «zoo» de plates-formes qui doivent être soutenues, et nous obtenons un semblant de foule Babel, qui n'est tout simplement pas en mesure de «faire normalement» et de générer des revenus. Le développement des plates-formes se déroulait souvent en parallèle et les mêmes fonctionnalités pouvaient sortir sur différentes plates-formes avec un décalage de plusieurs mois.


Ensembles de mise en page séparés pour chaque plate-forme

Traditionnellement, nous avons commencé avec des problèmes que le système de conception aiderait à résoudre et formulé des exigences pour sa conception. En plus de créer un langage visuel unique, d'augmenter la vitesse de prototypage et de développement, d'améliorer la qualité du produit dans son ensemble, il était vital d'unifier le design autant que possible. Cela est nécessaire pour que le développement de fonctionnalités devienne possible immédiatement sur toutes nos plateformes simultanément: Web, iOS, Android, Smart TV, tvOS, Android TV, Windows 10, xBox One, PS4, Roku - sans travailler sur chacune d'elles individuellement . Et nous l'avons fait!

Conception → Données

Lorsque les principaux accords des départements produit et développement ont été conclus, nous nous sommes assis pour sélectionner la pile technologique et étudier les détails de l'ensemble du processus - de la mise en page à la sortie. Pour automatiser entièrement le processus de transfert de la conception au développement, nous avons étudié l'option avec un analyseur de paramètres de composants directement à partir de fichiers Sketch avec des dispositions. Il s'est avéré que trouver les morceaux de code dont nous avions besoin et extraire les paramètres dont nous avions besoin était une entreprise compliquée et dangereuse. Premièrement, les concepteurs devront être extrêmement prudents en nommant toutes les couches du code source, deuxièmement, cela ne fonctionne que pour les composants les plus simples, et troisièmement, la dépendance à la technologie d'autres personnes et à la structure du code de la disposition Sketch originale met en péril l'avenir de l'ensemble du projet. Nous avons décidé d'abandonner l'automatisation dans ce domaine. Ainsi, la première personne est apparue dans l'équipe du système de conception, à l'entrée de laquelle les dispositions de conception sont alimentées et à la sortie - des données décrivant tous les paramètres des composants et hiérarchiquement ordonnées selon la méthodologie de conception atomique.

Le problème est resté limité: où et comment stocker les données, comment les transférer vers le développement et comment les interpréter en développement sur toutes les plateformes prises en charge par nous. La soirée a cessé d'être languissante ... Le résultat des réunions régulières du groupe de travail, composé de designers et de chefs d'équipe de chaque plateforme, a été l'accord sur les points suivants.

Nous analysons manuellement le visuel en éléments atomiques: polices, couleurs, transparence, retraits, congés, icônes, images et durées des animations. Et nous collectons à partir de ce bouton, des entrées, des cases à cocher, des widgets de cartes bancaires, etc. Nous attribuons des noms non sémantiques à des styles de n'importe quel niveau, à l'exception des icônes, par exemple, les noms de villes, les noms de nymphes, Pokémon, les marques de voitures ... Il n'y a qu'une seule condition - la liste ne doit pas être épuisée plus tôt , avec quels styles se terminera-t-il? Vous ne devriez pas vous laisser emporter par la sémantique afin de ne pas avoir à ajouter un bouton du milieu entre "petit" et "moyen", par exemple.

Langage visuel

Les développeurs sont partis pour réfléchir à la façon de stocker et de transférer des données afin qu'elles s'adaptent à toutes les plates-formes, et la conception a dû concevoir des éléments d'interface qui pourraient être aussi bons et fonctionner efficacement sur l'ensemble du parc d'appareils pris en charge.

Plus tôt, nous avons réussi à «parcourir» la plupart des éléments de conception d'une application pour Windows 10, qui à l'époque était une nouvelle plate-forme pour nous, c'est-à-dire que le rendu et le développement à partir de zéro étaient nécessaires. En le dessinant, nous avons pu préparer et tester la plupart des composants et comprendre lesquels devaient être inclus dans le futur système de conception Ivy. Sans un tel bac à sable, une telle expérience ne pourrait être acquise que par un grand nombre d'itérations sur des plates-formes déjà opérationnelles, et cela aurait pris plus d'un an.

La réutilisation des mêmes composants sur différentes plates-formes réduit parfois le nombre de dispositions et la matrice de données du système de conception, de sorte que la conception devait résoudre un autre problème qui n'était pas décrit précédemment dans la pratique de la conception et du développement de produits - comment, par exemple, réutiliser le bouton pour les téléphones et les tablettes sur les téléviseurs? Et qu'en principe devrait-il y avoir avec les tailles des polices et des éléments sur ces plates-formes différentes?

De toute évidence, il était nécessaire de concevoir une grille modulaire multiplateforme qui définirait la taille du texte et des éléments dont nous avions besoin pour chaque plate-forme particulière. Pour le point de référence de la grille, nous avons sélectionné la taille et le nombre d'affiches de films que nous voulons voir sur un écran particulier et, sur cette base, nous avons formulé une règle pour construire des colonnes de grille, à condition que la largeur d'une colonne soit égale à la largeur de l'affiche.


Vous devez maintenant amener tous les grands écrans à la même taille de la mise en page et les adapter à la grille générale. Apple TV et Roku sont en cours de développement dans la taille de 1920x1080, Android TV - 960x540, Smart TV, selon le fournisseur, ils sont les mêmes, et il y a 1280x720. Lorsque l'application est rendue et affichée sur des écrans Full HD, 960 est multiplié par 2, 1280 par 1,33 et 1920 s'affiche tel quel.

En omettant des détails ennuyeux, nous sommes arrivés à la conclusion qu'en général, tous les écrans, y compris les écrans de télévision en termes d'éléments et de leurs tailles, sont couverts par une conception unique, et tous les écrans de télévision sont un cas particulier d'une grille multiplateforme commune et se composent de cinq ou six colonnes, comme une tablette moyenne ou bureau. Peu importe les détails, allez aux commentaires.


Interface utilisateur unifiée pour toutes les plateformes

Maintenant, pour dessiner une nouvelle fonctionnalité, nous n'avons pas besoin de dessiner des dispositions pour chaque plate-forme, ainsi que des options d'adaptabilité pour chacune d'entre elles. Il suffit de montrer une disposition et son adaptabilité pour toutes les plates-formes et appareils de toute largeur: téléphones - 320–599, tout le reste - 600–1280.

Données → Développement

Bien sûr, peu importe la façon dont nous aimerions parvenir à une conception complètement unifiée, chaque plate-forme a ses propres caractéristiques uniques. Malgré le fait que le Web et Smart TV utilisent la pile ReactJS + TypeScript, l'application Smart TV s'exécute sur les clients WebKit et Presto hérités, et ne peut donc pas utiliser de styles communs avec le Web. Et les newsletters par e-mail sont complètement obligées de travailler avec la disposition des tableaux. Dans le même temps, aucune des plates-formes non html n'utilise ou ne prévoit d'utiliser React Native ou l'un de ses analogues, par crainte d'une dégradation des performances, car nous avons trop de mises en page personnalisées, de collections avec une logique de mise à jour complexe, d'images et de vidéos. Par conséquent, un schéma commun ne nous convient pas - pour fournir des styles CSS prêts à l'emploi ou des composants React. Par conséquent, nous avons décidé de transférer les données au format JSON, décrivant les valeurs sous une forme déclarative abstraite.

Ainsi, la propriété d' rounding: 8 , l'application Windows 10 se convertit en CornerRadius="8" , le Web - border-radius: 8px , Android - android:radius="8dp" , iOS - self.layer.cornerRadius = 8.0 .
offsetTop: 12 OffsetTop offsetTop: 12 le même client Web peut être interprété dans différents cas comme top , margin-top , padding-top ou transform

La nature déclarative de la description suggère également que si la plate-forme est techniquement incapable d'utiliser une propriété ou sa valeur, elle peut l'ignorer. En termes de terminologie, nous avons fait une sorte de langage espéranto: nous avons pris quelque chose d'Android, certains de SVG, certains de CSS.

S'il est nécessaire d'afficher des éléments d'une manière différente sur une plate-forme particulière, nous avons implémenté la possibilité de transférer la génération de données correspondante dans un fichier JSON distinct. Par exemple, l'état est «au point» pour Smart TV, il dicte un changement de position du texte sous l'affiche, donc pour cette plate-forme, ce composant dans la valeur de la propriété «indent» contiendra les 8 points de retrait dont il a besoin. Bien que cela complique l'infrastructure du système de conception, cela donne un degré de liberté supplémentaire, nous laissant l'opportunité de gérer nous-mêmes la «dissemblance» visuelle des plates-formes, et de ne pas être les otages de l'architecture que nous avons créée.

Pictogrammes

L'iconographie dans un produit numérique est toujours un sous-projet volumineux et pas le plus facile, ayant souvent un concepteur distinct. Il y a toujours de nombreux glyphes, chacun d'eux a plusieurs tailles et couleurs, de plus, les plates-formes en ont besoin, en règle générale dans différents formats. En général, il n'y avait aucune raison de ne pas intégrer tout cela dans le système de conception.


Les glyphes sont chargés au format SVG vectoriel et les valeurs de couleur sont automatiquement remplacées par des variables. Les applications clientes peuvent les préparer à l'emploi - dans n'importe quel format et couleur.

Aperçu

En plus de JSON avec les données, nous avons écrit un outil pour prévisualiser les composants - une application JS qui transmet les données JSON via ses générateurs de balisage et de style à la volée et affiche diverses variations de chaque composant dans le navigateur. En fait, l'aperçu est exactement le même client que les applications de la plate-forme et fonctionne avec les mêmes données.

Il est plus facile de comprendre le fonctionnement d'un composant particulier en interagissant avec lui. Par conséquent, nous n'avons pas utilisé d'outils comme le Storybook, mais avons fait un aperçu interactif - vous pouvez toucher, survoler, cliquer ... Lorsque vous ajoutez un nouveau composant au système de conception, il apparaît dans l'aperçu afin que les plateformes aient quelque chose à se concentrer lors de son introduction.

La documentation

Sur la base des données fournies sous forme de JSON aux plates-formes, la documentation des composants est générée automatiquement. La liste des propriétés et les types de valeurs possibles dans chacun d'eux sont décrits. Après la génération automatique, les informations peuvent être clarifiées manuellement, ajoutez une description textuelle. L'aperçu et la documentation sont fournis avec des références croisées au niveau de chaque composant, et toutes les informations contenues dans la documentation sont disponibles pour les développeurs sous la forme de fichiers JSON supplémentaires.

Deprecator

Un autre besoin était la possibilité de remplacer et de mettre à niveau les composants existants au fil du temps. Le système de conception a appris à dire aux développeurs quelles propriétés ou même des composants entiers ne peuvent pas être utilisés et à les supprimer dès qu'ils ne sont plus utilisés sur toutes les plateformes. Il y a encore beaucoup de travail «manuel» dans ce processus, mais nous ne nous arrêtons pas.

Développement client

Sans aucun doute, l'interprétation des données du système de conception dans le code de toutes les plates-formes prises en charge par nous est devenue l'étape de complexité la plus étendue. Si, par exemple, les grilles modulaires sur le Web ne sont pas nouvelles, les développeurs d'applications mobiles natives pour iOS et Android ont transpiré assez fort avant de comprendre comment vivre avec.

Pour la disposition des écrans d'application iOS, nous utilisons deux mécanismes de base fournis par iviUIKit: la disposition gratuite des éléments et la disposition des collections d'éléments. Nous utilisons VIPER, et toutes les interactions avec iviUIKit sont concentrées dans View, et la majorité des interactions avec Apple UIKit sont concentrées dans iviUIKit. Les tailles et la disposition des éléments sont spécifiées en termes de colonnes et de constructions syntaxiques fonctionnant au-dessus des constantes natives du SDK iOS, les rendant plus appliquées. Cela nous a particulièrement simplifié la vie lorsque nous travaillons avec UICollectionView. Nous avons écrit quelques mises en page personnalisables pour les mises en page, y compris celles assez complexes. Le code client s'est avéré minimum et il est devenu déclaratif.

Pour générer des styles dans le projet Android, nous utilisons Gradle, transformant les données du système de conception en styles au format XML. Dans le même temps, nous avons plusieurs générateurs de différents niveaux:

• Basique . Analyse des données des primitives pour les générateurs de niveau supérieur.
• Ressource . Téléchargez des photos, des icônes et d'autres graphiques.
• Composant Ils sont écrits pour chaque composant, qui décrit quelles propriétés et comment les traduire en styles.

Versions d'application

Une fois que les concepteurs ont dessiné un nouveau composant ou retravaillé un composant existant, ces modifications entrent dans le système de conception. Les développeurs de chaque plate-forme finalisent la génération de leur code, prenant en charge les modifications. Après cela, il peut être utilisé dans la mise en œuvre de nouvelles fonctionnalités, lorsque ce composant est nécessaire. Ainsi, l'interaction avec le système de conception ne se produit pas en temps réel, mais uniquement au moment de l'assemblage des nouvelles versions. Cette approche vous permet également de mieux contrôler le processus de transfert de données et garantit la performance du code dans les projets de développement client.

Résumé

Bientôt, en tant que système de conception, une année est devenue une partie de l'infrastructure servant au développement du cinéma en ligne Ivy, et certaines conclusions peuvent déjà être tirées:

• Il s'agit d'un projet vaste et difficile à mettre en œuvre, nécessitant des ressources allouées constantes.
• Cela nous a permis de créer notre propre langage visuel multiplateforme unique qui répond aux objectifs du service vidéo en ligne.
• Nous n'avons plus de plates-formes visuellement et fonctionnellement en retard.

Aperçu des composants du système de conception Ivy - design.ivi.ru