Comment nous avons créé l'onglet "Problèmes" des outils pour les développeurs Chrome

Jan Scheffler
Jan Scheffler
Sigurd Schneider
Sigurd Schneider

Au cours du dernier trimestre 2019, l'équipe des outils pour les développeurs Chrome a commencé à améliorer l'expérience des développeurs en ce qui concerne les cookies. Ce point était particulièrement important, car Google Chrome et d'autres navigateurs avaient commencé à modifier le comportement par défaut des cookies.

Lors de nos recherches sur les outils déjà fournis par les outils de développement, nous nous sommes souvent retrouvés dans une situation semblable à celle-ci:

Problèmes dans le panneau de la console

⬆ La console regorgeait d'avertissements et de messages d'erreur, qui contenaient assez d'explications techniques et parfois des liens vers chromestatus.com. Tous les messages semblaient à peu près tout aussi importants, ce qui empêchait de savoir quels éléments traiter en premier. Plus important encore, le texte ne renvoyait pas vers des informations supplémentaires dans les outils de développement, ce qui rendait difficile de comprendre ce qui s'était passé. Enfin, les messages laissaient souvent entièrement aux développeurs Web le soin de déterminer comment résoudre le problème, voire de se renseigner sur le contexte technique.

Si vous utilisez également la console pour les messages de votre propre application, vous aurez parfois du mal à les retrouver entre tous les messages du navigateur.

Il est également difficile pour les processus automatisés d'interagir avec les messages de la console, tout comme les êtres humains. Par exemple, les développeurs peuvent utiliser Chrome sans interface graphique et Puppeteer dans un scénario d'intégration continue/de déploiement continu. Les messages de la console étant de simples chaînes, les développeurs doivent écrire des expressions régulières ou un autre analyseur pour extraire des informations exploitables.

La solution: créer des rapports de problèmes structurés et exploitables

Pour trouver une meilleure solution aux problèmes que nous avons découverts, nous avons commencé à réfléchir aux exigences et les avons rassemblées dans un document de conception.

Notre objectif est de présenter les problèmes de manière à les expliquer clairement et à les résoudre. Lors de notre processus de conception, nous avons réalisé que chaque problème devait se composer des quatre parties suivantes:

  • Titre
  • Description
  • Liens vers les ressources concernées dans les outils de développement
  • Vous trouverez aussi un lien vers d'autres conseils

Nous souhaitons que le titre soit court et précis afin d'aider les développeurs à comprendre le problème principal et, souvent, de donner une idée du correctif. Par exemple, un problème de cookie se présente simplement comme suit:

Marquer les cookies intersites comme sécurisés pour pouvoir les définir dans des contextes intersites

La description de chaque problème contient des informations plus détaillées, ce qui explique ce qui s'est passé, donne des conseils pratiques pour le résoudre, ainsi que des liens vers d'autres panneaux dans les outils de développement pour comprendre le problème en contexte. Nous fournissons également des liens vers des articles détaillés sur web.dev pour permettre aux développeurs Web d'approfondir le sujet.

La section Ressources concernées représente une partie importante de chaque problème. Elle renvoie vers d'autres sections des outils de développement et facilite l'examen approfondi de la situation. Pour l'exemple de problème lié aux cookies, vous devriez voir une liste des requêtes réseau ayant déclenché le problème. Cliquez sur la demande pour accéder directement au panneau "Network" (Réseau). Nous espérons que cela vous facilitera la tâche, mais qu'elle vous aidera aussi à identifier les panneaux et les outils qui peuvent servir à déboguer un certain type de problème dans les outils de développement.

En observant à long terme l'interaction des développeurs avec l'onglet "Problèmes", nous imaginons l'évolution suivante en termes d'interaction:

  • Lorsqu'un développeur Web rencontre un problème particulier pour la première fois, il doit lire l'article pour en comprendre le problème en détail.
  • La deuxième fois que nous rencontrerons ce problème, nous espérons que sa description lui permettra de rappeler au développeur de quoi il s'agit, et lui permettra d'examiner le problème immédiatement et de prendre les mesures nécessaires pour le résoudre.
  • Après avoir rencontré un problème plusieurs fois, nous espérons que son titre permettra aux développeurs d'identifier le type de problème.

Un autre aspect important que nous souhaitions améliorer est l'agrégation. Par exemple, si le même cookie provoquait plusieurs fois le même problème, nous voulions le signaler une seule fois. En plus de réduire considérablement le nombre de messages, cela permet souvent d'identifier plus rapidement la cause d'un problème.

Problèmes agrégés

L'implémentation

Compte tenu de ces exigences, l'équipe a commencé à chercher comment implémenter la nouvelle fonctionnalité. Les projets des outils pour les développeurs Chrome couvrent généralement trois domaines différents:

L'implémentation comprenait ensuite trois tâches:

  • Dans Chromium, nous avons dû identifier les composants qui contiennent les informations que nous souhaitons afficher et rendre ces informations accessibles via le protocole DevTools sans compromettre la vitesse ni la sécurité.
  • Nous avons ensuite conçu le protocole des outils pour les développeurs Chrome (CDP, Chrome DevTools Protocol) afin de définir l'API qui expose les informations aux clients, comme l'interface des outils de développement.
  • Enfin, nous avons dû implémenter un composant dans l'interface DevTools qui demande les informations au navigateur via CDP et les affiche dans une interface utilisateur appropriée afin que les développeurs puissent facilement les interpréter et interagir avec elles.

Côté navigateur, nous avons tout d'abord examiné la façon dont les messages de la console étaient traités, car leur comportement est très semblable à celui que nous avions en tête pour les problèmes. CodeSearch constitue généralement un bon point de départ pour ce type d'exploration. Il vous permet de rechercher et d'explorer l'ensemble du code source du projet Chromium en ligne. Ainsi, nous avons appris l'implémentation des messages de la console et nous avons pu créer une méthode parallèle, mais plus structurée, autour des exigences collectées pour les problèmes.

Le travail ici est particulièrement difficile, en raison de toutes les implications en matière de sécurité que nous devons toujours garder à l'esprit. Le projet Chromium contribue grandement à séparer les choses en différents processus et à les faire communiquer uniquement par des canaux de communication contrôlés pour éviter les fuites d'informations. Les problèmes peuvent contenir des informations sensibles. Nous devons donc faire en sorte de ne pas envoyer ces informations à une personne du navigateur qui ne devrait pas les avoir au courant.

Dans l'interface des outils de développement

DevTools est lui-même une application Web écrite en JavaScript et CSS. Elle ressemble beaucoup à de nombreuses autres applications Web, sauf qu’elle existe depuis plus de 10 ans. Bien sûr, son backend constitue en fait un canal de communication directe vers le navigateur: le protocole des outils pour les développeurs Chrome.

Pour l'onglet "Problèmes", nous avons d'abord réfléchi aux histoires d'utilisateur et à ce que les développeurs devraient faire pour résoudre un problème. Nos idées ont surtout évolué : utiliser l'onglet "Problèmes" comme point de départ central pour mener des enquêtes permettant de relier les personnes aux panneaux affichant des informations plus détaillées. Nous avons décidé de placer l'onglet "Problèmes" avec les autres onglets en bas des outils de développement afin qu'il reste ouvert pendant qu'un développeur interagit avec un autre composant d'outils de développement, comme le panneau "Network" ou "Application".

Dans cette optique, notre concepteur UX a compris ce que nous voulions et a prototypé les propositions initiales suivantes:

Prototypes

Après de nombreuses discussions sur la meilleure solution, nous avons commencé à implémenter la conception et à répéter les décisions pour arriver progressivement à l'apparence de l'onglet "Problèmes" aujourd'hui.

La visibilité de l'onglet "Problèmes" est un autre facteur très important. Auparavant, de nombreuses fonctionnalités utiles des outils de développement n'étaient pas visibles sans que le développeur sache quoi rechercher spécifiquement. Pour l'onglet "Problèmes", nous avons décidé de mettre en évidence des problèmes dans plusieurs domaines afin que les développeurs ne passent pas à côté d'erreurs importantes.

Nous avons décidé d'ajouter une notification au panneau de la console, car certains messages de la console ont été supprimés en faveur de problèmes. Nous avons également ajouté une icône au compteur d'avertissements et d'erreurs en haut à droite de la fenêtre "Outils de développement".

Notification des problèmes

Enfin, l'onglet "Problèmes" renvoie non seulement à d'autres panneaux des outils de développement, mais aussi aux ressources liées à un problème.

Autres sujets

Dans le protocole

La communication entre l'interface et le backend s'effectue via un protocole appelé CDP (Chromium DevTools Protocol). La plate-forme de données client peut être considérée comme le backend de l'application Web, autrement dit les outils pour les développeurs Chrome. Le CDP est subdivisé en plusieurs domaines, et chacun d'entre eux contient un certain nombre de commandes et d'événements.

Pour l'onglet "Problèmes", nous avons décidé d'ajouter un nouvel événement au domaine "Audits" qui se déclenche chaque fois qu'un nouveau problème est rencontré. Pour nous permettre de signaler les problèmes survenant lorsque les outils de développement ne sont pas encore ouverts, le domaine "Audits" stocke les problèmes les plus récents et les distribue dès qu'ils se connectent. Les outils de développement collectent ensuite l'ensemble de ces problèmes et les regroupent.

Le CDP permet également à d'autres clients de protocole, tels que Puppeteer, de recevoir et de traiter des problèmes. Nous espérons que les informations structurées sur les problèmes envoyées via la plate-forme de données client permettront et simplifieront l'intégration dans l'infrastructure d'intégration continue existante. De cette façon, les problèmes peuvent être détectés et corrigés avant même le déploiement de la page.

Date future

Tout d'abord, de nombreux messages doivent être déplacés de la console vers l'onglet "Problèmes". Cette opération prendra un certain temps, notamment parce que nous souhaitons fournir une documentation claire et utile pour chaque nouveau problème que nous ajouterons. Nous espérons qu'à l'avenir, les développeurs examineront les problèmes dans l'onglet "Problèmes" plutôt que dans la console.

Par ailleurs, nous réfléchissons à la manière d'intégrer des problèmes provenant d'autres sources que le backend de Chromium dans l'onglet "Problèmes".

Nous cherchons des moyens de désencombrer l'onglet "Problèmes" et d'améliorer l'usabilité. La recherche, le filtrage et une meilleure agrégation sont sur notre liste pour cette année. Pour structurer le nombre croissant de problèmes signalés, nous introduisons actuellement des catégories de problèmes qui permettront, par exemple, de n'afficher que les problèmes concernant les abandons à venir. Nous envisageons également d'ajouter une fonctionnalité de mise en attente, que les développeurs peuvent utiliser pour masquer temporairement les problèmes.

Pour que les problèmes restent exploitables, nous souhaitons vous aider à identifier plus facilement la partie de la page à l'origine d'un problème. En particulier, nous réfléchissons à des moyens de distinguer et de filtrer les problèmes qui proviennent réellement de votre page (c'est-à-dire ceux qui concernent les données propriétaires) de ceux qui sont déclenchés par des ressources que vous intégrez, mais que vous ne contrôlez pas directement (un réseau publicitaire, par exemple). Dans un premier temps, vous pourrez masquer les problèmes liés aux cookies tiers dans Chrome 86.

Si vous avez des suggestions pour améliorer l'onglet "Problèmes", n'hésitez pas à nous signaler un bug.

Télécharger les canaux de prévisualisation

Nous vous conseillons d'utiliser Chrome Canary, Dev ou Beta comme navigateur de développement par défaut. Ces versions preview vous permettent d'accéder aux dernières fonctionnalités des outils de développement, de tester des API de pointe de plates-formes Web et de détecter les problèmes sur votre site avant qu'ils ne le fassent.

Contacter l'équipe des outils pour les développeurs Chrome

Utilisez les options suivantes pour discuter des nouvelles fonctionnalités et des modifications dans l'article, ou de toute autre question concernant les outils de développement.

  • Envoyez-nous une suggestion ou des commentaires via crbug.com.
  • Signalez un problème dans les outils de développement via Plus d'options   More > Aide > Signaler un problème dans les outils de développement dans les Outils de développement.
  • Envoyez un tweet à @ChromeDevTools.
  • Dites-nous en plus sur les nouveautés concernant les vidéos YouTube dans les outils de développement ou sur les vidéos YouTube de nos conseils relatifs aux outils de développement.