Comment Maria et son équipe ont révolutionné Gmail pour plus de 425 millions d'utilisateurs

Comment faire pour créer un produit utile pour chaque utilisateur à travers le monde ? En respectant la manière dont un produit a été utilisé jusque-là, tout en anticipant les nouveaux comportements ?

En travaillant au sein de l'équipe d'ingénierie frontale de Gmail, vous êtes amené non seulement à exploiter des données statistiques puissantes, mais aussi à observer le comportement d'utilisateurs réels pour vraiment comprendre comment vos idées fonctionnent concrètement. Vous apportez des modifications de code majeures, avec un minimum de changement visuel. Et vous découvrez que la mise en œuvre de nouveautés tout en gardant l'existant conduit à une solution unique plus fiable pour les utilisateurs. Qu'implique le développement de la meilleure expérience de messagerie Web ?

Depuis la sortie de la version bêta en avril 2004, Gmail est passé d'un simple service de messagerie Web à l'une des plates-formes de communication les plus utilisées, avec plus de 425 millions d'utilisateurs actifs dans le monde. À l'origine de l'étape majeure franchie par Gmail en 2012 se trouvent Maria et son équipe, qui étaient chargées de continuer à accroître la productivité pour Gmail. "Nous travaillions depuis des années à rendre Gmail disponible hors connexion. Il semblait difficile de trouver une nouvelle idée avec un impact similaire." Lorsque son responsable technique lui a soumis l'idée de simplifier l'interface de rédaction, l'équipe (cinq ingénieurs, un concepteur UX et des experts en tests utilisateurs) a sauté sur l'occasion. Après avoir étudié la manière dont les utilisateurs se servaient réellement de la fonction de rédaction existante, l'équipe a découvert que la plupart d'entre eux envoyaient des e-mails relativement courts, et moins de dix pour cent des utilisateurs utilisaient le formatage de texte enrichi dans leurs messages. Comme l'explique Maria : "Au cours de cette dernière décennie, la manière dont les internautes interagissent entre eux a fortement évolué, avec par exemple l'envoi de messages courts au lieu de longs e-mails. Nous souhaitions nous assurer que Gmail était à la fois simple à utiliser pour rédiger des messages courts, et performant pour rédiger des messages plus longs. Nous voulions créer une expérience de rédaction simple et efficace."

Comment créer le couteau suisse de la rédaction d'e-mails ?

Une expérience fluide et réactive quel que soit le navigateur

À partir des données tirées de diverses études sur le comportement des utilisateurs, Maria et ses collègues ont identifié les modifications à apporter pour accélérer et faciliter la rédaction d'e-mails. La première modification a été la création d'une nouvelle fenêtre de rédaction, que l'on a appelée "blaireau." Pourquoi "blaireau" ? "Dans Gmail, nous avons ces petites fenêtres de chat que l'on appelle entre nous des "taupes",\ raconte Maria. "Nous avons donc décidé d'appeler les nouvelles fenêtres de rédaction "blaireaux". Nous avons juste choisi un animal plus gros, rien de plus."

Contrairement à l'interface de rédaction classique de l'époque, la nouvelle fenêtre est une fenêtre contextuelle qui s'affiche en bas à droite de l'écran Gmail. Cela permet aux utilisateurs d'écrire plusieurs messages simultanément et de lire leurs e-mails en arrière-plan pendant ce temps. L'équipe avait par ailleurs décidé que la taille de la fenêtre de rédaction varierait à mesure que l'utilisateur saisit ou supprime du texte. Qu'un champ modifiable s'adapte à la taille du contenu n'est pas particulièrement difficile à réaliser en soi, mais l'équipe Gmail a été confrontée à plusieurs comportements inattendus des navigateurs lors du redimensionnement d'une zone de contenu modifiable selon le principe fluide qu'elle avait envisagé.

Il nous a fallu une grande quantité de nouveau code pour gérer ces interactions afin que les fenêtres ne se décalent pas, ne coupent pas des morceaux de ligne ni ne reformatent le texte à mesure que l'utilisateur saisit son message.

Comme l'explique Maria : "Notre but était que la zone de texte s'accroisse graduellement, mais qu'une fois la barre d'outils en haut atteinte, la fenêtre passe en mode de défilement. Ce comportement s'est avéré difficile à mettre en œuvre sur les trois navigateurs compatibles : Chrome, Firefox et Internet Explorer. Il nous a fallu une grande quantité de nouveau code pour gérer ces interactions afin que les fenêtres ne se décalent pas, ne coupent pas des morceaux de ligne ni ne reformatent le texte à mesure que l'utilisateur saisit son message."

Une fois que l'équipe a commencé à expérimenter avec cette zone de texte adaptative, elle s'est rendu compte que, bien que cette modification fonctionnait bien avec du texte enrichi, elle ne gérait pas très bien le texte simple. La solution la plus simple aurait consisté à ne plus accepter du tout le texte simple, mais les études sur les utilisateurs montraient que de nombreuses listes de diffusion n'acceptaient que le texte simple. L'objectif global étant de faciliter tous les types de conversations, ignorer ce cas d'utilisation était tout bonnement impossible.

Alors que le texte simple est généralement traité par l'élément HTML "textarea", le texte enrichi est quant à lui géré par un l'élément "contenteditable div". Pour conserver la fonctionnalité de texte simple, "nous avons fini par réécrire la manière dont nous gérions le texte simple, en utilisant un élément "contenteditable div" également pour ce type de texte," explique Maria. "Nous avons dû désactiver toutes les fonctionnalités de formatage et, à la fin de la rédaction, toutes les balises sont supprimées et le texte reformaté en texte simple. S'assurer que le formatage d'un e-mail en texte simple est conservé lors de la conversion du format HTML au format texte simple est une opération assez délicate. On ne peut pas simplement supprimer les balises HTML et obtenir un résultat correct. Il faut comprendre quels types de formatage ces balises HTML créent dans le document. Ensuite, il faut convertir tout cela afin que le formatage reflète ce qu'il aurait été si le message avait été directement écrit en texte simple. C'était un défi passionnant. Alors que l'ancien Gmail reposait sur deux méthodes complètement différentes pour traiter le formatage de texte, à présent Gmail ne repose plus que sur une seule méthode unifiée."

Pendant la phase de développement de ces idées, les chercheurs UX de l'équipe ont mené des études pour aider l'équipe à hiérarchiser et regrouper les fonctionnalités du produit. Les testeurs essayaient une grande variété de tâches au moyen de la nouvelle fenêtre de rédaction, puis remplissaient des questionnaires sur leur expérience. Pour que le développement des fonctionnalités reste en phase avec les commentaires des utilisateurs, l'équipe appliquait un processus de développement agile modifié. "Nous étions tous assis ensemble, les quatre ingénieurs, le chef de projets et les concepteurs UX ; on pouvait donc vraiment réagir rapidement," raconte Maria. L'obtention rapide et fréquente de données utilisateurs a permis à l'équipe de mettre en place des cycles d'itération de deux semaines. Les nouvelles idées étaient ainsi rapidement intégrées au plan global de développement, et les nouveaux obstacles renvoyés pour modification et test.

S'assurer que le passage d'un champ de texte non modifiable à un champ de texte modifiable ne décalait pas le texte

Un problème étonnamment difficile à surmonter et pour lequel Maria et son équipe ont travaillé de cette manière était la création d'une nouvelle méthode de gestion des destinataires. Lorsqu'un utilisateur consulte la liste des destinataires dans la nouvelle fenêtre de rédaction, chaque nom s'affiche dans un champ non modifiable. Mais lorsqu'il clique sur ces champs, ils deviennent modifiables. "Nous avons dû trouver un moyen d'aligner ceci afin que ce passage de champ non modifiable à champ modifiable ne décale pas le texte vers le haut ni vers le bas. "C'était d'autant plus compliqué que les différents navigateurs gèrent les choses de manière différente (merci Captain Obvious), et la hauteur des champs de saisie varie d'un navigateur à l'autre. "Nous avons dû créer des feuilles de style capables d'aligner tous les éléments correctement dans tous les navigateurs. Et bien sûr, avec toutes les fonctionnalités de la nouvelle fenêtre de rédaction de Gmail, à chaque fois que l'on modifiait légèrement l'interface utilisateur, un élément se décalait dans peut-être deux navigateurs sur trois, ce qu'il nous fallait corriger. Nous avons fini par écrire un test automatique capable de mesurer la hauteur de la liste des destinataires, puis de cliquer dessus et de mesurer à nouveau la hauteur, et de vérifier que la hauteur n'avait pas changé. Des outils tels que Webdriver se sont avérés utiles pour s'assurer que nos nouvelles fonctionnalités continuent de marcher dans les différents navigateurs, en particulier en ce qui concerne les modifications de la liste des destinataires."

Une fois ce problème résolu, un nouveau bug étrange est apparu. Une barre de défilement aléatoire inutile apparaissait à droite de la fenêtre de rédaction lorsque les utilisateurs zoomaient dans Chrome. Apparemment, cela était dû au fait que le contenu devenait soudain un peu plus gros que le cadre autour. Ce qui était surprenant, puisque la zone de texte était censée s'adapter à la hauteur du contenu. "Lorsque nous avons examiné les hauteurs, nous nous sommes rendu compte qu'elles différaient d'une fraction de pixel. Par exemple, le contenu était de 9 pixels, mais le champ de 8,98 pixels. Visiblement, zoomer dans Chrome active le mode de rendu au niveau du sous-pixel. Et dans ce mode, un calcul de la hauteur peut présenter une erreur d'arrondi. Nous avons donc signalé un bug, qui a été corrigé dans le moteur de rendu de Chrome, mais nous avons également dû contourner ce problème en arrondissant prudemment les valeurs calculées des hauteurs tout en nous assurant que ce problème ne se produise pas."

Création de la parité des fonctionnalités et intégration

Puis ce fut au tour de la parité des fonctionnalités. "Pour la plupart des utilisateurs, la fenêtre de rédaction de Gmail est une simple zone de texte dans laquelle ils saisissent leur message avant d'appuyer sur "Envoi", et c'est tout. En réalité, la fenêtre de rédaction comporte de nombreuses fonctionnalités, dont on ne réalise pas forcément le nombre si l'on n'examine pas le code. Par exemple, dans Gmail, vous pouvez étiqueter des brouillons dans une fenêtre de rédaction, vous pouvez insérer des emoji, vous pouvez appliquer divers types de formatage, vous pouvez imprimer des brouillons, vous pouvez insérer des photos et des documents, etc. De nombreuses fonctionnalités expérimentales sont intégrées, comme les réponses standardisées. Non seulement nous avons dû répliquer toutes ces fonctionnalités dans la nouvelle fenêtre de rédaction, mais nous avons dû également trouver le moyen de les intégrer dans la nouvelle interface, ce qui s'est traduit par de nouveaux défis au niveau de la conception. C'était vraiment extraordinaire de voir toutes les opérations internes de ces fonctionnalités uniques, puis de chercher les moyens de les reproduire dans la nouvelle fenêtre."

... Nous sommes perfectionnistes, et nous souhaitions vraiment proposer une expérience à la fois fluide et élégante, sans bidouillage.

Pour un projet frontal tel que celui de Maria, il est essentiel que chaque élément soit parfait : "La recherche de différentes manières de créer des alignements précis pour toutes les fonctionnalités de la nouvelle fenêtre de rédaction était passionnante. L'alignement des éléments peut paraître trivial, mais nous sommes perfectionnistes, et nous souhaitions vraiment proposer une expérience à la fois fluide et élégante, sans bidouillage. Il nous a fallu quelques essais pour y parvenir, mais nous avons des normes de qualité élevées à respecter. Au vu du résultat, on peut dire que ça en valait la peine."

"Mon commentaire préféré est celui d'un utilisateur, qui a déclaré : "c'est comme gratter une démangeaison que je ne m'étais même pas rendu compte avoir." Je suis vraiment heureuse d'avoir pu travailler sur ce projet. Pendant toute la durée du projet, j'en ai vraiment ressenti tout le potentiel : il avait vraiment la capacité d'améliorer la productivité des utilisateurs lorsqu'ils utilisent leur messagerie. C'est une véritablement modification qui a un impact majeur réel."

Maria est à présent ingénieur au sein de l'équipe Chrome et membre du comité de la bourse Anita Borg.

Comment Maria et son équipe ont révolutionné Gmail pour plus de 425 millions d'utilisateurs

Comment faire pour créer un produit utile pour chaque utilisateur à travers le monde ? En respectant la manière dont un produit a été utilisé jusque-là, tout en anticipant les nouveaux comportements ?

En travaillant au sein de l'équipe d'ingénierie frontale de Gmail, vous êtes amené non seulement à exploiter des données statistiques puissantes, mais aussi à observer le comportement d'utilisateurs réels pour vraiment comprendre comment vos idées fonctionnent concrètement. Vous apportez des modifications de code majeures, avec un minimum de changement visuel. Et vous découvrez que la mise en œuvre de nouveautés tout en gardant l'existant conduit à une solution unique plus fiable pour les utilisateurs. Qu'implique le développement de la meilleure expérience de messagerie Web ?

Depuis la sortie de la version bêta en avril 2004, Gmail est passé d'un simple service de messagerie Web à l'une des plates-formes de communication les plus utilisées, avec plus de 425 millions d'utilisateurs actifs dans le monde. À l'origine de l'étape majeure franchie par Gmail en 2012 se trouvent Maria et son équipe, qui étaient chargées de continuer à accroître la productivité pour Gmail. "Nous travaillions depuis des années à rendre Gmail disponible hors connexion. Il semblait difficile de trouver une nouvelle idée avec un impact similaire." Lorsque son responsable technique lui a soumis l'idée de simplifier l'interface de rédaction, l'équipe (cinq ingénieurs, un concepteur UX et des experts en tests utilisateurs) a sauté sur l'occasion. Après avoir étudié la manière dont les utilisateurs se servaient réellement de la fonction de rédaction existante, l'équipe a découvert que la plupart d'entre eux envoyaient des e-mails relativement courts, et moins de dix pour cent des utilisateurs utilisaient le formatage de texte enrichi dans leurs messages. Comme l'explique Maria : "Au cours de cette dernière décennie, la manière dont les internautes interagissent entre eux a fortement évolué, avec par exemple l'envoi de messages courts au lieu de longs e-mails. Nous souhaitions nous assurer que Gmail était à la fois simple à utiliser pour rédiger des messages courts, et performant pour rédiger des messages plus longs. Nous voulions créer une expérience de rédaction simple et efficace."

Comment créer le couteau suisse de la rédaction d'e-mails ?

Une expérience fluide et réactive quel que soit le navigateur

À partir des données tirées de diverses études sur le comportement des utilisateurs, Maria et ses collègues ont identifié les modifications à apporter pour accélérer et faciliter la rédaction d'e-mails. La première modification a été la création d'une nouvelle fenêtre de rédaction, que l'on a appelée "blaireau." Pourquoi "blaireau" ? "Dans Gmail, nous avons ces petites fenêtres de chat que l'on appelle entre nous des "taupes",\ raconte Maria. "Nous avons donc décidé d'appeler les nouvelles fenêtres de rédaction "blaireaux". Nous avons juste choisi un animal plus gros, rien de plus."

Contrairement à l'interface de rédaction classique de l'époque, la nouvelle fenêtre est une fenêtre contextuelle qui s'affiche en bas à droite de l'écran Gmail. Cela permet aux utilisateurs d'écrire plusieurs messages simultanément et de lire leurs e-mails en arrière-plan pendant ce temps. L'équipe avait par ailleurs décidé que la taille de la fenêtre de rédaction varierait à mesure que l'utilisateur saisit ou supprime du texte. Qu'un champ modifiable s'adapte à la taille du contenu n'est pas particulièrement difficile à réaliser en soi, mais l'équipe Gmail a été confrontée à plusieurs comportements inattendus des navigateurs lors du redimensionnement d'une zone de contenu modifiable selon le principe fluide qu'elle avait envisagé.

Il nous a fallu une grande quantité de nouveau code pour gérer ces interactions afin que les fenêtres ne se décalent pas, ne coupent pas des morceaux de ligne ni ne reformatent le texte à mesure que l'utilisateur saisit son message.

Comme l'explique Maria : "Notre but était que la zone de texte s'accroisse graduellement, mais qu'une fois la barre d'outils en haut atteinte, la fenêtre passe en mode de défilement. Ce comportement s'est avéré difficile à mettre en œuvre sur les trois navigateurs compatibles : Chrome, Firefox et Internet Explorer. Il nous a fallu une grande quantité de nouveau code pour gérer ces interactions afin que les fenêtres ne se décalent pas, ne coupent pas des morceaux de ligne ni ne reformatent le texte à mesure que l'utilisateur saisit son message."

Une fois que l'équipe a commencé à expérimenter avec cette zone de texte adaptative, elle s'est rendu compte que, bien que cette modification fonctionnait bien avec du texte enrichi, elle ne gérait pas très bien le texte simple. La solution la plus simple aurait consisté à ne plus accepter du tout le texte simple, mais les études sur les utilisateurs montraient que de nombreuses listes de diffusion n'acceptaient que le texte simple. L'objectif global étant de faciliter tous les types de conversations, ignorer ce cas d'utilisation était tout bonnement impossible.

Alors que le texte simple est généralement traité par l'élément HTML "textarea", le texte enrichi est quant à lui géré par un l'élément "contenteditable div". Pour conserver la fonctionnalité de texte simple, "nous avons fini par réécrire la manière dont nous gérions le texte simple, en utilisant un élément "contenteditable div" également pour ce type de texte," explique Maria. "Nous avons dû désactiver toutes les fonctionnalités de formatage et, à la fin de la rédaction, toutes les balises sont supprimées et le texte reformaté en texte simple. S'assurer que le formatage d'un e-mail en texte simple est conservé lors de la conversion du format HTML au format texte simple est une opération assez délicate. On ne peut pas simplement supprimer les balises HTML et obtenir un résultat correct. Il faut comprendre quels types de formatage ces balises HTML créent dans le document. Ensuite, il faut convertir tout cela afin que le formatage reflète ce qu'il aurait été si le message avait été directement écrit en texte simple. C'était un défi passionnant. Alors que l'ancien Gmail reposait sur deux méthodes complètement différentes pour traiter le formatage de texte, à présent Gmail ne repose plus que sur une seule méthode unifiée."

Pendant la phase de développement de ces idées, les chercheurs UX de l'équipe ont mené des études pour aider l'équipe à hiérarchiser et regrouper les fonctionnalités du produit. Les testeurs essayaient une grande variété de tâches au moyen de la nouvelle fenêtre de rédaction, puis remplissaient des questionnaires sur leur expérience. Pour que le développement des fonctionnalités reste en phase avec les commentaires des utilisateurs, l'équipe appliquait un processus de développement agile modifié. "Nous étions tous assis ensemble, les quatre ingénieurs, le chef de projets et les concepteurs UX ; on pouvait donc vraiment réagir rapidement," raconte Maria. L'obtention rapide et fréquente de données utilisateurs a permis à l'équipe de mettre en place des cycles d'itération de deux semaines. Les nouvelles idées étaient ainsi rapidement intégrées au plan global de développement, et les nouveaux obstacles renvoyés pour modification et test.

S'assurer que le passage d'un champ de texte non modifiable à un champ de texte modifiable ne décalait pas le texte

Un problème étonnamment difficile à surmonter et pour lequel Maria et son équipe ont travaillé de cette manière était la création d'une nouvelle méthode de gestion des destinataires. Lorsqu'un utilisateur consulte la liste des destinataires dans la nouvelle fenêtre de rédaction, chaque nom s'affiche dans un champ non modifiable. Mais lorsqu'il clique sur ces champs, ils deviennent modifiables. "Nous avons dû trouver un moyen d'aligner ceci afin que ce passage de champ non modifiable à champ modifiable ne décale pas le texte vers le haut ni vers le bas. "C'était d'autant plus compliqué que les différents navigateurs gèrent les choses de manière différente (merci Captain Obvious), et la hauteur des champs de saisie varie d'un navigateur à l'autre. "Nous avons dû créer des feuilles de style capables d'aligner tous les éléments correctement dans tous les navigateurs. Et bien sûr, avec toutes les fonctionnalités de la nouvelle fenêtre de rédaction de Gmail, à chaque fois que l'on modifiait légèrement l'interface utilisateur, un élément se décalait dans peut-être deux navigateurs sur trois, ce qu'il nous fallait corriger. Nous avons fini par écrire un test automatique capable de mesurer la hauteur de la liste des destinataires, puis de cliquer dessus et de mesurer à nouveau la hauteur, et de vérifier que la hauteur n'avait pas changé. Des outils tels que Webdriver se sont avérés utiles pour s'assurer que nos nouvelles fonctionnalités continuent de marcher dans les différents navigateurs, en particulier en ce qui concerne les modifications de la liste des destinataires."

Une fois ce problème résolu, un nouveau bug étrange est apparu. Une barre de défilement aléatoire inutile apparaissait à droite de la fenêtre de rédaction lorsque les utilisateurs zoomaient dans Chrome. Apparemment, cela était dû au fait que le contenu devenait soudain un peu plus gros que le cadre autour. Ce qui était surprenant, puisque la zone de texte était censée s'adapter à la hauteur du contenu. "Lorsque nous avons examiné les hauteurs, nous nous sommes rendu compte qu'elles différaient d'une fraction de pixel. Par exemple, le contenu était de 9 pixels, mais le champ de 8,98 pixels. Visiblement, zoomer dans Chrome active le mode de rendu au niveau du sous-pixel. Et dans ce mode, un calcul de la hauteur peut présenter une erreur d'arrondi. Nous avons donc signalé un bug, qui a été corrigé dans le moteur de rendu de Chrome, mais nous avons également dû contourner ce problème en arrondissant prudemment les valeurs calculées des hauteurs tout en nous assurant que ce problème ne se produise pas."

Création de la parité des fonctionnalités et intégration

Puis ce fut au tour de la parité des fonctionnalités. "Pour la plupart des utilisateurs, la fenêtre de rédaction de Gmail est une simple zone de texte dans laquelle ils saisissent leur message avant d'appuyer sur "Envoi", et c'est tout. En réalité, la fenêtre de rédaction comporte de nombreuses fonctionnalités, dont on ne réalise pas forcément le nombre si l'on n'examine pas le code. Par exemple, dans Gmail, vous pouvez étiqueter des brouillons dans une fenêtre de rédaction, vous pouvez insérer des emoji, vous pouvez appliquer divers types de formatage, vous pouvez imprimer des brouillons, vous pouvez insérer des photos et des documents, etc. De nombreuses fonctionnalités expérimentales sont intégrées, comme les réponses standardisées. Non seulement nous avons dû répliquer toutes ces fonctionnalités dans la nouvelle fenêtre de rédaction, mais nous avons dû également trouver le moyen de les intégrer dans la nouvelle interface, ce qui s'est traduit par de nouveaux défis au niveau de la conception. C'était vraiment extraordinaire de voir toutes les opérations internes de ces fonctionnalités uniques, puis de chercher les moyens de les reproduire dans la nouvelle fenêtre."

... Nous sommes perfectionnistes, et nous souhaitions vraiment proposer une expérience à la fois fluide et élégante, sans bidouillage.

Pour un projet frontal tel que celui de Maria, il est essentiel que chaque élément soit parfait : "La recherche de différentes manières de créer des alignements précis pour toutes les fonctionnalités de la nouvelle fenêtre de rédaction était passionnante. L'alignement des éléments peut paraître trivial, mais nous sommes perfectionnistes, et nous souhaitions vraiment proposer une expérience à la fois fluide et élégante, sans bidouillage. Il nous a fallu quelques essais pour y parvenir, mais nous avons des normes de qualité élevées à respecter. Au vu du résultat, on peut dire que ça en valait la peine."

"Mon commentaire préféré est celui d'un utilisateur, qui a déclaré : "c'est comme gratter une démangeaison que je ne m'étais même pas rendu compte avoir." Je suis vraiment heureuse d'avoir pu travailler sur ce projet. Pendant toute la durée du projet, j'en ai vraiment ressenti tout le potentiel : il avait vraiment la capacité d'améliorer la productivité des utilisateurs lorsqu'ils utilisent leur messagerie. C'est une véritablement modification qui a un impact majeur réel."

Maria est à présent ingénieur au sein de l'équipe Chrome et membre du comité de la bourse Anita Borg.