Simplifiez le passage de l'esquisse au code Visual Studio avec Indigo.Design

(Ceci est un article sponsorisé.) Si vous y réfléchissez bien, les équipes logicielles ressemblent beaucoup aux équipes sportives. Bien que chaque membre de l'équipe travaille exactement vers le même objectif, le rôle qu'ils jouent et les actions qu'ils entreprennent sont très différents les uns des autres.

C'est pourquoi il est crucial d'avoir une manière transparente de déplacer le ballon d'un membre de l'équipe à l'autre.

Malheureusement, le transfert qui a lieu au sein des équipes logicielles n'est naturellement pas aussi fluide que ce que vous voyez sur le terrain de sport. Et l'une des principales raisons à cela est les différents systèmes et approches utilisés pour créer des produits.

Les concepteurs créent des interfaces utilisateur au pixel près dans Sketch, pour ensuite les traduire dans un langage que les développeurs peuvent utiliser lorsqu'ils créent des applications dans l'IDE Visual Studio Code. Sans un moyen transparent de déplacer les conceptions de produits dans le pipeline, ces inefficacités entraînent des retouches et des débogages coûteux après le transfert d'une application du concepteur au développeur.

Inutile de dire qu'une solution au problème de transfert Sketch-to-IDE a mis longtemps à venir. Ce n'est pas que les équipes logicielles ne savent pas comment collaborer ou bien communiquer entre elles. C'est juste que leurs systèmes et stratégies disparates rendent la transition d'une équipe à l'autre maladroite, chronophage et pleine d'erreurs.

Aujourd'hui, nous allons voir pourquoi cela se produit et comment votre agence peut résoudre le problème avec deux plugins et une plateforme cloud de prototypage d'Indigo.Design.

Où le transfert concepteur-développeur se trompe-t-il ?

Tout d'abord, ce que nous devrions vraiment demander, c'est :

Pourquoi le transfert concepteur-développeur est-il un tel problème ?

Nick Babich a récemment écrit sur la façon dont les concepteurs se donnent beaucoup de mal pour créer des solutions numériques parfaitement mesurées et conçues de manière cohérente. Mais les systèmes de conception ne se traduisent pas facilement en systèmes de développement.

Plus le concepteur en fait sur une interface, plus il doit réellement communiquer avec un développeur. Il ne suffit donc pas de remettre un fichier de conception Sketch et de laisser le développeur s'en occuper. Les concepteurs doivent fournir des spécifications de conception qui expliquent comment toutes les pièces mobiles doivent être disposées, espacées, stylisées, colorées, engagées, etc.

C'est le seul moyen de s'assurer qu'une application se termine au pixel près à la fin. Même dans ce cas, cela nécessite encore beaucoup d'implémentation de la part du développeur une fois qu'il est dans son IDE.

Comme vous pouvez l'imaginer, tout ce processus prend beaucoup de temps à un designer. Mais sans spécifications de conception, les développeurs finissent par devoir jouer à un jeu de devinettes risqué.

De plus, les développeurs n'ont généralement pas l'habitude de coder avec HTML et CSS, ce qui est un travail fastidieux et ne représente que l'interface utilisateur. Il y a beaucoup plus de code dans les coulisses qui fait fonctionner une application Web et tous les développeurs ne sont pas aptes ou intéressés à apprendre à écrire le balisage de l'interface utilisateur. Lorsqu'ils sont contraints à cette position, la courbe d'apprentissage abrupte ajoute plus de temps aux projets et les retouches et le débogage qui en résultent font exploser les coûts.

Donc, vraiment, le transfert concepteur-développeur est devenu une question de temps à qui pouvons-nous nous permettre de perdre ?

"

Est-ce le concepteur qui doit tout relire pour que le développeur sache comment transformer le design en réalité ?

Ou:

Est-ce le développeur qui doit regarder un design, mesurer manuellement tout ce qui est à l'écran et espérer obtenir toutes les spécifications juste en le regardant ?

Personne ne gagne dans les deux scénarios. Et vous allez ronger vos marges bénéficiaires dans le processus.

Certaines agences peuvent penser que forcer les concepteurs et les développeurs à travailler sur la même plate-forme est la meilleure solution. De cette façon, il n'est pas nécessaire de faire toute cette traduction ou interprétation pendant le transfert de Sketch à Visual Studio Code. Mais cela se traduit souvent par une créativité étouffée de la part du concepteur ou une capacité entravée à créer des solutions logicielles efficaces de la part du développeur.

Alors, quelle est la réponse ?

Améliorez le transfert concepteur-développeur avec Indigo.Design

Ce n'est pas comme si Indigo.Design était la première plate-forme à essayer de résoudre les problèmes de transfert pour les équipes logicielles. InVision et Zeplin ont tous deux proposé leurs propres solutions.

Chacune de ces plateformes a rendu les spécifications visuelles plus accessibles aux développeurs tout en améliorant par conséquent l'efficacité des équipes de concepteurs-développeurs. Spécifiquement:

• Les concepteurs n'ont plus besoin de baliser l'interface utilisateur car les plates-formes gèrent les lignes rouges.
• Les développeurs peuvent extraire manuellement les spécifications de conception sans l'aide des concepteurs.

Cela dit, avec des plates-formes comme InVision et Zeplin, les développeurs doivent toujours inspecter chaque élément et le coder manuellement en fonction des spécifications extraites. Ces plates-formes doivent également créer un pont transparent entre Sketch et Visual Studio Code.

Ainsi, si les designers et les développeurs veulent travailler le plus efficacement possible les uns avec les autres, Indigo.Design a développé une réponse à leur problème :

Étape 1 : Concevoir dans Sketch

Il n'y a vraiment qu'une seule chose dans cette phase qui doit changer pour le concepteur. L'application, les pages et le flux seront toujours conçus comme d'habitude dans Sketch, en utilisant des composants du kit d'interface utilisateur Indigo.Design.

Cependant, il n'est plus nécessaire de compiler des lignes rouges ou des spécifications pour l'application. Indigo.Design s'en charge pour vous.

Afin d'en tirer parti, votre concepteur doit abandonner le système de prototypage qu'il utilisait auparavant. Avec ce nouveau système simplifié et sans erreur, votre designer peut facilement transférer ses conceptions dans le cloud à l'aide du plugin Indigo.Design.

Celle-ci est accessible depuis le Plugins menu > Indigo.Design > Publish Prototype :

Le concepteur n'a pas besoin d'exporter des fichiers et de les télécharger dans un autre système pour que les clients les examinent ou les développeurs avec qui travailler. Ils peuvent rester là où ils sont pour publier le prototype.

Il ne faut qu'environ une minute pour terminer le processus, aussi. Le concepteur reçoit ensuite un lien vers le cloud qu'il peut partager avec des clients et d'autres personnes pour examiner et commenter le prototype.

Étape 2 : Travaillez dans le Cloud Indigo.Design

Faire entrer les autres dans le cloud est facile. Le lien fourni les conduira dans le cloud d'expérience où la conception peut être examinée :

Il est également facile de laisser des commentaires sur le design. Tout ce que les utilisateurs ont à faire est d'ouvrir le panneau Commentaires, de déposer une épingle et d'y joindre leur commentaire :

Il y a plus dans ce logiciel de collaboration que cela. Le prototype peut également être modifié à partir du cloud.

Pour y accéder, le concepteur, le développeur et toute autre personne disposant d'un accès de groupe localiseront le projet à partir de la bibliothèque de prototypes :

Cliquez sur "Modifier le prototype" pour entrer dans l'éditeur Indigo.Design :

Une fois qu'un écran est sélectionné, le concepteur peut ajouter un hotspot pour créer une nouvelle interaction dans l'application.

Vous pouvez également utiliser l'éditeur Indigo.Design pour inspecter les spécifications de l'interface utilisateur de l'application :

Le survol d'un élément révèle les spécifications d'espacement relatif. Cliquer sur un élément révèle beaucoup plus de détails :

Le développeur peut également modifier ou copier le CSS proprement écrit et généré à partir de ce panneau. (Bien qu'ils ne devraient pas avoir à le faire, comme je l'expliquerai à l'étape suivante.)

Vous voyez ce que je veux dire par le fait de faire gagner du temps aux concepteurs lors de la génération des spécifications ? En poussant simplement cette conception dans le cloud Indigo.Design, les spécifications sont automatiquement générées.

Étape 3 : Créer dans Visual Studio Code

Maintenant, disons que votre conception est suffisamment bonne pour être développée. Le déplacement d'un prototype Indigo.Design vers Visual Studio Code est aussi simple que le passage de Sketch.

Récupérez le lien cloud d'origine fourni par le plugin Indigo.Design dans Sketch. Si vous ne l'avez plus, ce n'est pas grave. Vous pouvez le récupérer depuis l'écran des bibliothèques dans Indigo.Design :

Il ne reste plus au développeur qu'à installer l'extension Indigo.Design Code Generator. C'est ce qui permet à Visual Studio Code de parler directement à Indigo.Design pour récupérer le prototype.

Une fois l'extension configurée, le développeur procédera comme suit :

Ouvrez le shell de l'application qui a déjà été développé. Ensuite, lancez le générateur de code Indigo.Design. C'est ici que vous entrerez le lien vers le cloud :

Cela révélera une fenêtre contextuelle avec les conceptions d'applications qui vivent dans le cloud ainsi que les composants individuels qui les composent.

Le développeur a la possibilité de générer du code pour tous les composants de l'application ou d'aller composant par composant, en ne vérifiant que ceux dont il a besoin. Ceci est particulièrement utile si une application est en cours et que le développeur n'a besoin que d'importer de nouveaux composants dans VSC.

En cliquant sur "Générer des ressources de code", les composants sélectionnés seront ajoutés à Angular sous forme de code HTML et CSS lisible et sémantique.

Le développeur a désormais moins à se soucier de la reconstruction des styles ou de la configuration d'autres spécifications. Au lieu de cela, ils peuvent passer leur temps à créer des fonctionnalités commerciales et à vraiment affiner le produit.

Une note à propos de ce processus

Il est important de souligner que ce flux de travail Sketch – cloud – Visual Studio Code ne fonctionne pas uniquement avec la première itération d'une conception. Les développeurs peuvent construire pendant que les concepteurs travaillent sur des commentaires avec les clients ou des études d'utilisabilité avec les utilisateurs - ce dont Indigo.Design a tenu compte.

Donc, disons que le concepteur a déplacé une interface utilisateur de formulaire de connexion via Indigo.Design et que le développeur a généré le code pour faire avancer les choses.

Tout en travaillant sur le formulaire, le développeur a implémenté un code d'authentification dans le fichier TypeScript.

Entre-temps, cependant, le concepteur a reçu un message du client, l'informant qu'une nouvelle connexion universelle avec Google devait être mise en œuvre. Ce qui signifie que l'UX doit changer.

Lorsque la mise à jour est prête et que le prototype est synchronisé avec Indigo.Design, le concepteur envoie un message au développeur pour l'informer des modifications. Ainsi, le développeur lance à nouveau le générateur de code Visual Studio. Cependant, lors de la régénération de l'écran de connexion, ils sélectionnent "Ne pas remplacer" sur le fichier TypeScript. De cette façon, ils peuvent conserver le code qu'ils ont écrit tout en important simultanément les nouveaux HTML et CSS.

Le développeur peut ensuite effectuer les ajustements nécessaires en fonction de la conception mise à jour.

Emballer

Indigo.Design a effectivement créé un transfert efficace et sans bogue pour les concepteurs travaillant dans Sketch et les développeurs travaillant dans Visual Studio Code.

Les concepteurs ne perdent pas de temps à concevoir sur une plate-forme et à prototyper sur une autre, à rédiger des spécifications de conception ou à gérer les exportations de fichiers. Les développeurs ne perdent pas de temps à essayer de recréer l'intention de conception à partir d'un fichier statique.

Comme l'a déclaré Jason Beres, vice-président principal du développement de produits pour Indigo.Design :

Avec la génération de code Indigo.Design, tous ces bugs sont évités à 100%. Non seulement l'esprit de la conception est conservé, mais un code HTML et CSS au pixel près est créé afin que le développeur ne soit pas dans la position malheureuse de devoir faire correspondre manuellement la conception.

Et en résolvant les problèmes techniques dans les flux de travail et le transfert concepteur-développeur, votre agence réduira considérablement le coût des retouches et du débogage. Vous augmenterez également les bénéfices en fournissant à votre équipe logicielle un moyen plus efficace et plus rapide d'obtenir des applications tout au long du processus et dans un état parfait au pixel près.