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

Expérience de cinéma en ligne Ivy

Lorsque, début 2017, nous avons pensé pour la première fois à créer notre propre système de livraison de conception à code, beaucoup en parlaient déjà et certains le faisaient même. Cependant, à ce jour, on sait peu de choses sur l'expérience de création de systèmes de conception multiplateformes, et il n'existe pas de recettes claires et éprouvées décrivant les technologies et les méthodes permettant une telle transformation du processus de mise en œuvre de la conception en un produit déjà fonctionnel. Et par « composants du code », ils entendent souvent des choses très différentes.

Pendant ce temps, l'entreprise a doublé ses effectifs d'année en année - il était nécessaire de faire évoluer le département de conception et d'optimiser les processus de création et de transfert de mises en page pour le développement. Nous multiplions tout cela par le « zoo » de plateformes qui doivent être soutenues, et nous obtenons un semblant de chaos babylonien, qui n'est tout simplement pas capable de « faire les choses normalement » et de générer des revenus. Le développement des plates-formes s'est souvent déroulé en parallèle et la même fonctionnalité pouvait être publiée 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 commencions par des problèmes qu'un système de conception aiderait à résoudre et formulions des exigences pour sa conception. En plus de créer un langage visuel unifié, d'augmenter la vitesse de mise en page et de développement et d'améliorer la qualité globale du produit, il était essentiel d'unifier le design autant que possible. Ceci est nécessaire pour que le développement de fonctionnalités devienne possible 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 séparément. Et nous l'avons fait !

Conception → données

Lorsque les accords fondamentaux entre les départements produit et développement ont été conclus, nous nous sommes assis pour sélectionner une pile technologique et travailler sur les détails de l'ensemble du processus - de la conception à la version. Pour automatiser entièrement le processus de transfert de la conception vers le développement, nous avons exploré la possibilité d'analyser les paramètres des composants directement à partir des fichiers Sketch avec des mises en page. 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 complexe 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 à l'égard de la technologie et de la structure de code de quelqu'un d'autre de la mise en page originale de Sketch met en péril l'avenir de l'ensemble. projet. Nous avons décidé d'abandonner l'automatisation dans ce domaine. C'est ainsi qu'est apparue la première personne dans l'équipe du système de conception, dont l'entrée est constituée de schémas de conception et la sortie est constituée de données décrivant tous les paramètres des composants et classés hiérarchiquement selon la méthodologie de conception atomique.

Il ne restait plus qu'à savoir où et comment stocker les données, comment les transférer en développement et comment les interpréter en développement sur toutes les plateformes que nous prenons en charge. La soirée a cessé d'être languissante... Le résultat des réunions régulières du groupe de travail composé de concepteurs et de chefs d'équipe de chaque plateforme a été l'accord sur ce qui suit.

Nous analysons manuellement le visuel en éléments atomiques : polices, couleurs, transparence, retraits, arrondis, icônes, images et durées des animations. Et nous collectons à partir de là des boutons, des entrées, des cases à cocher, des widgets de cartes bancaires, etc. Nous attribuons des noms non sémantiques aux styles de n'importe lequel des niveaux, à l'exception des icônes, par exemple, des noms de villes, des noms de nymphes, de Pokémon, de voiture. marques... Il n'y a qu'une seule condition - la liste ne doit pas être épuisée avant , comment se terminent les styles - le spectacle doit avoir lieu ! Il ne faut pas se laisser emporter par la sémantique, pour ne pas avoir à ajouter un bouton du milieu entre « petit » et « moyen », par exemple.

Langage visuel

Les développeurs ont dû réfléchir à la manière de stocker et de transférer les données d'une manière adaptée à toutes les plates-formes, et la conception a dû concevoir des éléments d'interface qui pourraient être beaux et fonctionner efficacement sur l'ensemble du parc d'appareils pris en charge.

Auparavant, nous avions déjà réussi à « tester » 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 qu'elle nécessitait un rendu et un développement « à partir de zéro ». En le dessinant, nous avons pu préparer et tester la plupart des composants et comprendre lesquels d'entre eux étaient censés être inclus dans le futur système de conception d'Évoli. Sans un tel bac à sable, une telle expérience ne pourrait être obtenue qu'au travers d'un grand nombre d'itérations sur des plateformes déjà opérationnelles, et cela prendrait plus d'un an.

La réutilisation des mêmes composants sur différentes plates-formes réduit considérablement le nombre de mises en page et la gamme de données du système de conception, de sorte que la conception a dû résoudre un problème supplémentaire, non décrit auparavant dans les pratiques de conception et de développement de produits - comment, par exemple, Un bouton pour téléphone et tablette peut-il être réutilisé sur les téléviseurs ? Et que devons-nous faire des tailles de polices et d’éléments sur des plateformes aussi différentes ?

De toute évidence, il était nécessaire de concevoir une grille modulaire multiplateforme qui définirait les tailles de texte et d'éléments dont nous avions besoin pour chaque plateforme spécifique. Comme point de départ pour la grille, nous avons choisi 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 les colonnes de la grille, à condition que la largeur d'une colonne soit égale à la largeur de l'affiche.

Nous devons maintenant amener tous les grands écrans à la même taille de mise en page et les intégrer dans une grille commune. Apple TV et Roku sont conçus dans une taille de 1920x1080, Android TV - 960x540, les Smart TV, selon le fournisseur, sont les mêmes, mais parfois 1280x720. Lorsque l'application est rendue et affichée sur des écrans Full HD, 960 est multiplié par 2, 1280 1,33 est multiplié par 1920 et XNUMX XNUMX est affiché tel quel.

En ignorant les 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 tailles, sont couverts par une seule disposition de conception, et que tous les écrans de télévision sont un cas particulier de la grille multiplateforme générale, et se compose de cinq ou six colonnes, comme une tablette ou un ordinateur de bureau moyen. Qui est intéressé par les détails, allez dans les commentaires.

Interface utilisateur unique pour toutes les plateformes

Désormais, pour dessiner une nouvelle fonctionnalité, nous n’avons plus besoin de dessiner des mises en page pour chaque plate-forme, ni des options d’adaptabilité pour chacune d’elles. Il suffit de montrer une disposition et son adaptabilité à toutes les plates-formes et appareils de toute largeur : téléphones - 320-599, tout le reste - 600-1280.

Données → développement

Bien entendu, même si nous souhaitons parvenir à une conception complètement unifiée, chaque plate-forme possède ses propres caractéristiques uniques. Même si le Web et Smart TV utilisent la pile ReactJS + TypeScript, l'application Smart TV s'exécute sur les anciens clients WebKit et Presto et ne peut donc pas partager de styles avec le Web. Et les newsletters par courrier électronique sont complètement obligées de fonctionner avec une présentation tabulaire. 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, craignant 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, le schéma courant consistant à fournir des styles CSS ou des composants React prêts à l'emploi ne nous convient pas. Par conséquent, nous avons décidé de transmettre les données au format JSON, décrivant les valeurs sous une forme déclarative abstraite.

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

Le caractère déclaratif de la description implique également que si la plateforme ne peut techniquement pas utiliser une propriété ou sa valeur, elle peut l'ignorer. En termes de terminologie, nous avons créé une sorte de langage espéranto : certains sont tirés d'Android, d'autres de SVG, d'autres de CSS.

Si sur une plateforme particulière vous devez afficher les éléments différemment, nous avons implémenté la possibilité de transférer la génération de données correspondante sous la forme d'un fichier JSON séparé. Par exemple, l'état « in focus » pour Smart TV impose un changement dans la position du texte sous l'affiche, ce qui signifie que pour cette plateforme, ce composant dans la valeur de la propriété « indent » contiendra les 8 points d'indentation 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 la possibilité de gérer nous-mêmes la « dissemblance » visuelle des plates-formes, et de ne pas être l'otage de l'architecture que nous avons créée.

Pictogrammes

L'iconographie dans un produit numérique est toujours un sous-projet volumineux et non le plus simple, nécessitant souvent un concepteur distinct. Il y a toujours beaucoup de glyphes, chacun d'eux a plusieurs tailles et couleurs, et les plateformes en ont généralement besoin 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 vectoriel SVG et les valeurs de couleur sont automatiquement remplacées par des variables. Les applications clientes peuvent les recevoir prêtes à l'emploi, dans n'importe quel format et couleur.

avant-première

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

Le moyen le plus simple de comprendre le fonctionnement d’un composant particulier est d’interagir avec lui. Par conséquent, nous n'avons pas utilisé d'outils comme Storybook, mais avons créé un aperçu interactif - vous pouvez toucher, pointer, cliquer... Lors de l'ajout d'un nouveau composant au système de conception, il apparaît dans l'aperçu afin que les plateformes aient quelque chose sur quoi se concentrer lorsque la mettre en œuvre.

Documentation

Sur la base des données fournies aux plateformes sous forme de JSON, la documentation des composants est automatiquement générée. Une liste de propriétés et les types de valeurs possibles dans chacune d'elles sont décrits. Après la génération automatique, les informations peuvent être clarifiées manuellement et une description textuelle peut être ajoutée. L'aperçu et la documentation font l'objet de références croisées au niveau de chaque composant, et toutes les informations incluses dans la documentation sont disponibles pour les développeurs sous forme de fichiers JSON supplémentaires.

Dépréciateur

Une autre nécessité était la capacité de remplacer et de mettre à jour les composants existants au fil du temps. Le système de conception a appris à indiquer 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 restons pas immobiles.

Développement clients

L’étape la plus complexe a sans aucun doute été l’interprétation des données du système de conception dans le code de toutes les plateformes que nous prenons en charge. Si, par exemple, les grilles modulaires sur le Web ne sont pas quelque chose de nouveau, les développeurs d'applications mobiles natives pour iOS et Android ont travaillé dur avant de comprendre comment vivre avec.

Pour disposer les écrans des applications iOS, nous utilisons deux mécanismes de base fournis par iviUIKit : la disposition libre 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 plupart 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 structures syntaxiques qui fonctionnent au-dessus des contraintes natives du SDK iOS, ce qui les rend plus pratiques. Cela nous a particulièrement simplifié la vie lorsque nous travaillons avec UICollectionView. Nous avons écrit plusieurs wrappers personnalisés pour les mises en page, y compris des wrappers assez complexes. Il y avait un minimum de code client 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. Parallèlement, nous disposons de plusieurs générateurs de différents niveaux :

• De base. Les données des primitives des générateurs de niveau supérieur sont analysées.
• Ressource. Téléchargez des images, des icônes et d'autres graphiques.
• Composant. Ils sont écrits pour chaque composant, décrivant quelles propriétés et comment les traduire en styles.

Versions d'applications

Une fois que les concepteurs ont dessiné un nouveau composant ou redessiné un composant existant, ces modifications sont intégrées au système de conception. Les développeurs de chaque plateforme affinent leur génération de code pour prendre en charge les changements. 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 permet également un meilleur contrôle du processus de transfert de données et garantit la fonctionnalité du code dans les projets de développement des clients.

Les résultats de

Cela fait un an que le système de conception fait partie de l'infrastructure supportant le développement du cinéma en ligne Ivy, et nous pouvons déjà tirer quelques conclusions :

• Il s’agit d’un projet vaste et complexe qui nécessite des ressources dédié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 en retard visuellement et fonctionnellement.

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

Source: habr.com