web-dev-qa-db-fra.com

Comparaison et fusion des révisions d'interface utilisateur de plusieurs personnes

Comment comparer, fusionner et éviter les conflits entre les modifications d'interface utilisateur apportées par différents membres d'une équipe de développement d'interface utilisateur multi-personnes?

Contexte de cette question:

Les outils de diff et de fusion visuels comme Meld sont utiles pour comparer les versions de code logiciel textuel. Ils aident les personnes responsables du code à comprendre ce qui a changé et à déterminer s'il est sûr d'accepter les modifications dans le produit final.

J'ai récemment utilisé Meld pour fusionner les changements d'interface utilisateur de deux développeurs frontaux et j'ai trouvé cela très difficile. Les modifications étaient réparties sur plusieurs fichiers (feuilles de style, modèles, JavaScript dynamique) et il était difficile de visualiser comment ces modifications interagiraient pour présenter une interface utilisateur dans un navigateur Web.

La tâche a été encore compliquée par le fait que les changements d'implémentation ne signifient pas nécessairement que l'expérience utilisateur changera, car l'interface utilisateur peut sembler inchangée du point de vue de l'utilisateur final. Par exemple, on peut utiliser une balise en gras, une balise forte, un style CSS en ligne, une syntaxe comme Markdown, ou même JavaScript pour du texte en gras sur un site Web et n'importe laquelle de ces solutions peut entraîner un UX équivalent. Pourtant, pour les outils de diff & fusion textuels, il semblerait qu'une modification ait été apportée.

gui-designguidelinesworkflowversion-control
3
Michael Hogan

La façon la plus simple de le faire à laquelle je peux penser serait de tirer (et de compiler, éventuellement) les deux validations différentes dans deux environnements de développement différents, puis de comparer les parties de l'interface effectuées par les validations.

Vous pouvez aller plus loin et automatiser le processus, en interagissant avec un historique de validation et en déclenchant à l'aide de fichiers de commandes ou similaire un ensemble d'opérations qui a extrait deux validations données différentes et les a configurées pour examen. Ce serait souhaitable si vous le faisiez souvent et cela signifierait également que le processus pourrait être confié à une personne moins technique.

En prenant le Web comme exemple, comme vous le faites dans votre question (bien que les principes pourraient bien être appliqués à d'autres situations de développement) avec des CSS et des vues bien écrits et modulaires, vous pouvez configurer les choses pour compiler et afficher uniquement les parties de l'interface effectuées par le commit.

Une autre chose que vous pourriez faire serait d'utiliser javascript pour prendre des hachages de validation et les ajouter en tant que classes aux extraits/vues html où les choses ont changé afin de les marquer comme modifiées. c'est-à-dire regarder chaque vue qui a changé entre deux validations et ajouter une classe à chaque élément de ces vues. Vous pouvez croiser le CSS ou le javascript pour voir quels éléments sont ciblés par les changements dans ces fichiers et les réinjecter pour enrichir le retour visuel, c'est-à-dire "cet élément avait un événement lié" ou "cet élément avait une classe ajoutée" . Cela vous aiderait à vous concentrer sur les changements qui ont eu un effet.

La fusion se ferait de la manière habituelle, dans le contrôle de version, une fois qu'une interface préférée a été sélectionnée.

Vous bénéficieriez énormément si vos développeurs effectuaient de très bonnes commits, c'est-à-dire atomiques, contenaient des éléments de développement plutôt qu'un travail de jour, 10,6 tâches et un message comme `` changements, désolé, je suis mauvais ''. Les messages de validation devraient être très bien écrits afin que vous puissiez voir quelle partie du système cibler avec la méthode que vous avez utilisée et les tâches devraient être soigneusement réparties entre les développeurs afin qu'ils puissent travailler efficacement sur une chose, puis valider et pousser.

Vous devez également utiliser la ramification pour que les ensembles de validations puissent être plus facilement divisés en tâches qu'ils représentent dans leur ensemble. Comparez ensuite entre les têtes de branche ou les têtes de branche séquentiellement avec la tête principale.

Il va y avoir une programmation assez sophistiquée pour bien faire fonctionner, ce n'est pas un mince exploit, bonne chance!

1
Toni Leigh

C'est quelque chose que j'ai essayé de faire avec les développeurs, mais je trouve que la meilleure façon de comprendre les changements de l'interface utilisateur est d'avoir un bon système pour le développement d'applications, ce qui signifie suivre un document de normes comme le Guide de développement Atlassian ou Guide de conception des matériaux Google.

Ce que je trouve, c'est que si les développeurs ne construisent pas d'applications basées sur un ensemble de normes, alors toute comparaison est plutôt dénuée de sens dans le sens où s'ils construisent selon des règles et des structures différentes et se retrouvent avec le même aspect, alors vous ne pas bien gérer le code car la variation est trop importante.

D'un autre côté, si vous pouvez faire comprendre et suivre un guide aux développeurs, les différences seront minimes et vous pourrez faire des comparaisons significatives.

En ce qui concerne la représentation des changements, je pense qu'une représentation visuelle est la meilleure, même si certaines des différences ne sont que sur une interaction et non pas au niveau visuel. Je place les numéros de version à côté de chaque itération de l'interface utilisateur, ce qui est également un moyen courant d'illustrer comment certaines décisions entraînent trop de modifications d'interfaces très similaires.

1
Michael Lai

Je pense que les ressources suivantes pourraient être utiles pour résoudre le problème:

Bien que les ressources susmentionnées ne représentent certainement pas la solution, je pense qu'elles pourraient servir de fondation , qui pourrait être la solution au problème. construit sur.

0
Aleksandr Blekh

Par exemple, on peut utiliser une balise en gras, une balise forte, un style CSS en ligne, une syntaxe comme Markdown ou même JavaScript pour mettre du texte en gras sur un site Web et n'importe laquelle de ces solutions peut entraîner une UX équivalente.

Ce n'est pas vrai du tout. Il peut en résulter un visuel équivalent, mais ce n'est certainement pas la même chose. Et cela peut causer beaucoup de problèmes ... que ce soit avec JS à la recherche d'un balisage particulier, de normes d'accessibilité, d'optimisation SEO, etc.

Idéalement, vous ne devriez pas trop faire cela du côté de l'enregistrement du code. Cela devrait se produire du côté du précodage. Le développement de l'interface utilisateur doit suivre certaines normes définies. Des choses telles que:

  • en utilisant un cadre
  • extraction à partir d'une bibliothèque de composants/bibliothèque de modèles
  • obéir aux normes de balisage du projet

Combiné avec, idéalement, beaucoup de communication inter-équipes.

Et, peut-être le plus grand de tous:

  • maintenance régulière

Les équipes d'interface utilisateur multi-membres qui couvrent de nombreuses versions se retrouveront inévitablement avec des inefficacités dans leur code frontal. C'est naturel et, idéalement, du temps est consacré à différentes périodes pour revenir en arrière et nettoyer les choses en groupe. Dans un environnement agile, par exemple, il serait idéal de commettre quelques sprints par an juste pour nettoyer le code.

0
DA01