Images et photos · Éditeur d'images et de dessins du navigateur
Comment annoter une capture d'écran d'un rapport de bug afin que les développeurs puissent agir en conséquence
· Pourquoi c'est important
retouche d'images toile traitement du navigateur
Une capture d'écran avec une case transparente, une flèche et une courte légende enregistre une série de questions ; une simple capture d’écran les invite. Cet article présente une petite convention d'annotation et montre comment l'appliquer dans un éditeur de navigateur.
La capture d'écran qui a généré trois questions de clarification : pourquoi « voir ci-joint » n'est pas un rapport de bug
Une capture d'écran de bug utile répond à la première question avant que le lecteur n'ait à la poser. Une simple capture intitulée « voir ci-joint » laisse le développeur rechercher le défaut, le contrôle affecté et le résultat attendu. Le petit vocabulaire visuel de l'éditeur suffit à réduire cette ambiguïté : recadrez jusqu'à la zone pertinente, tracez un rectangle autour du problème, utilisez une ligne pour attirer l'attention et ajoutez une légende concise.
Traitez l'image comme une preuve plutôt que comme l'ensemble du rapport. Le texte devient immédiatement des pixels, alors écrivez la légende avant l'exportation et gardez-la suffisamment courte pour être numérisée. Les étapes de reproduction, les journaux et le comportement attendu appartiennent toujours à l'image car aucune marque ne peut décrire les interactions ou indiquer que l'image capturée ne s'affiche pas.
Un problème par image : recadrage vers la région pertinente afin que le défaut soit la première chose qu'un lecteur voit
Un problème par image donne au lecteur une cible visuelle claire. Recadrez les panneaux sans rapport, le chrome du navigateur et les contrôles voisins à moins qu'ils n'établissent le contexte nécessaire. Un recadrage serré fait du défaut la première chose visible, tandis qu'un cadre légèrement plus large peut préserver la relation entre le contrôle cassé et la disposition environnante.
Comparez le recadrage avec l'original avant de l'exporter afin que le rapport ne supprime pas accidentellement l'indice nécessaire pour reproduire le problème. Les marques à contraste élevé doivent se démarquer des régions claires et sombres de l'interface, et une capture d'écran doit compléter plutôt que remplacer les étapes, les journaux et le comportement attendu.
Formes ayant une signification : cadre, flèche, légende – une convention minimale sur ce que dit chaque marque et quand les utiliser.
Chaque marque doit porter un travail. Un rectangle isole le contrôle ou la région concernée, une ligne dirige l'œil vers un écart ou un désalignement et une légende explique la différence attendue par rapport à la réalité. Cet éditeur propose des marques de rectangle, de ligne et de texte ; il n'a pas de primitive de flèche, alors décrivez la direction dans la légende lorsqu'une ligne simple pourrait être lue de manière ambiguë.
Gardez la convention stable au sein d'une équipe afin qu'un lecteur n'ait pas à décoder les choix décoratifs. Le texte est pixellisé dans l'image lors du placement et ne peut pas être réédité en tant qu'objet distinct, ce qui rend le libellé et l'emplacement valent la peine d'être vérifiés avant l'exportation. L’image reste une preuve à l’appui et ne remplace pas les détails comportementaux du rapport.
Formes signifiantes : rectangle, ligne et légende ; cet éditeur n'a pas d'outil flèche
La couleur et le poids sont des choix de communication, pas de décoration. Un fin trait rouge peut disparaître sur une interface sombre ou devenir difficile à lire une fois l'image réduite. Choisissez une couleur avec un contraste clair, donnez au rectangle suffisamment de largeur pour survivre à l'exportation et évitez de placer une ligne directement sur le détail de l'interface utilisateur qu'il est censé identifier.
Vérifiez l'image finale à la taille qu'un développeur verra réellement dans le suivi des problèmes. Le contraste doit survivre aux régions claires et sombres, tandis que la légende doit rester lisible sans masquer le défaut. Le rapport de support nécessite encore des étapes de reproduction et des journaux ; l'accent visuel peut indiquer des preuves mais ne peut pas remplacer un comportement manquant.
Attendu par rapport au réel : ajout d'une courte légende indiquant ce qui aurait dû se passer, dans l'image elle-même
La formulation attendue par rapport à la réalité transforme un défaut mis en évidence en une petite réclamation. « Attendu : bouton aligné avec l'entrée ; réel : le bouton est 12 px bas » donne au lecteur plus de direction qu'une boîte colorée seule. Gardez cette légende factuelle et compacte, car l'image exportée doit clarifier l'inadéquation visible plutôt que de devenir un paragraphe de diagnostic spéculatif.
Placez le texte près de la région marquée sans couvrir le contrôle ou l'espace. L'éditeur rastérise le texte au moment du placement, donc révisez le libellé et la position avant l'exportation au lieu de vous attendre à modifier un objet texte plus tard. Les étapes de reproduction et les journaux doivent contenir les détails qui ne peuvent pas être établis à partir d’une seule image statique.
Exemple concret : un bouton mal aligné – recadrer, encadrer l'élément, flèche vers l'espace, légende avec la position attendue
Prenons un bouton mal aligné comme exemple concret. Recadrez suffisamment étroitement pour afficher le bouton et sa référence d'alignement voisine, dessinez un rectangle autour du contrôle et utilisez une ligne pour pointer vers l'espace visible. Étant donné que l'éditeur ne dispose pas d'outil de flèche, laissez la ligne identifier l'emplacement et laissez une courte légende indiquer l'endroit où le bouton doit se trouver.
Une légende telle que « Attendu : aligné avec le champ ; réel : décalé vers le bas » rend la comparaison visuelle explicite sans prétendre diagnostiquer la cause. Inspectez le contraste des traits et le placement du texte, puis exportez le raster marqué. Ajoutez le chemin de reproduction, les détails du navigateur et les journaux dans le ticket afin que la capture d'écran reste une preuve solide plutôt que l'intégralité du rapport.
Exemple concret : un bouton mal aligné marqué d'un cadre, d'une ligne de pointage et d'une légende
Une capture d'écran marquée ne peut pas montrer une séquence de clics, une course au chronométrage, une exception de console, une réponse réseau ou l'état qui apparaît uniquement après un rechargement. Il ne remplace pas un enregistrement d’écran lorsque le mouvement est important, et il ne peut pas remplacer les étapes de reproduction ou les journaux. L’image doit limiter l’enquête et non prétendre contenir l’ensemble de l’incident.
Gardez ces limites visibles sur le ticket. Incluez l’environnement, le résultat attendu, le résultat réel, les étapes et les diagnostics pertinents aux côtés de la culture. Le rectangle, la ligne et les marques de texte facilitent la détection du défaut visuel, tandis que le reste du rapport explique comment le faire se reproduire et ce que la capture d'écran ne peut pas établir.
À retenir : moins de repères, un rapport plus clair – comment les outils de recadrage, d'annotation et de dessin de l'éditeur d'images et de dessins du navigateur produisent une capture d'écran qui ne nécessite aucun suivi.
Moins de marques rendent généralement le rapport plus clair. Recadrez jusqu'au défaut, dessinez un rectangle, utilisez une ligne là où la direction compte et ajoutez une courte légende qui nomme la différence attendue par rapport à la réalité. L'éditeur d'images et de dessins du navigateur fournit ces fonctionnalités de recadrage, de ligne, de forme et de texte sous forme de modifications raster, sans revendiquer une primitive de flèche ou un système complet de rapport de bogues.
Exportez uniquement après avoir vérifié le contraste, l'emplacement et le libellé en fonction de la taille probable de l'internaute. Associez ensuite l’image aux étapes de reproduction, aux journaux et aux détails de l’environnement. Les outils mis en œuvre peuvent rendre évidents les pixels importants ; ils ne peuvent pas supprimer le besoin de preuves comportementales qui permettent aux développeurs de reproduire et de corriger le défaut.