Chip de demande d'autorisation

Jusqu'à présent, lorsqu'un utilisateur visitait un site qui demandait une autorisation, une bulle s'affichait pour l'inviter à prendre une décision. Par exemple, vous pouvez voir l'invite d'autorisation de géolocalisation telle qu'elle est implémentée dans Chrome jusqu'à la version 96. (Vous pouvez essayer cette autorisation et d'autres sur notre site de démonstration permission.site.)

Requête d'autorisation de géolocalisation dans Chrome

Les données de télémétrie de Chrome prouvent que de nombreuses requêtes d'autorisation sont ignorées. Vous pouvez explorer vous-même les données sur les autorisations de notification dans le rapport sur l'expérience utilisateur de Chrome. Pour l'instant, consultez le tableau ci-dessous qui montre comment les utilisateurs Windows ont réagi à l'invite de notification sur les sites de manière cumulée, tout en notant que les invites de géolocalisation ont enregistré un comportement d'ignorement ou de refus similaire.

Action Pourcentage d'invites de notification
Autoriser 6,69%
Bloquer 9,20 %
Ignorer 35,76%
Ignorer 47,19%

Compte tenu d'un taux d'ignorement et de refus d'environ 85%, et surtout compte tenu de la façon dont l'invite se démarque et insiste pour que les utilisateurs prennent une décision immédiatement, il existe un conflit entre le niveau d'urgence supposé par le navigateur et la préférence de l'utilisateur d'attendre de prendre une décision. Cela donne l'impression qu'il est "ennuyeux" pour un site de demander une autorisation, car elle sera perdue parmi les éléments supplémentaires auxquels les utilisateurs doivent réagir, comme les bannières de consentement aux cookies, les inscriptions à la newsletter, etc.

Nouvelle interface

À partir de Chrome 98, nous avons donc introduit une interface utilisateur de chip animée qui s'affiche à côté du cadenas chaque fois qu'une autorisation est demandée. Il se compose d'une icône et d'un libellé décrivant l'autorisation demandée. Notre objectif était d'améliorer l'expérience de navigation sur le Web tout en évitant les demandes d'autorisation généralement inutiles pour la grande majorité des utilisateurs et fréquemment ignorées ou refusées.

La bulle d'invite existante s'affiche lorsque vous cliquez sur le chip de requête (s'il n'est pas déjà affiché) et l'UI de la requête est automatiquement enrichie de la bulle de requête en fonction des heuristiques suivantes:

  • L'autorisation a été déclenchée par un geste de l'utilisateur lorsqu'il interagit avec le site lui-même, plutôt que par le site lui-même.
  • L'autorisation est considérée comme essentielle et généralement non-spammeuse. Cela inclut la caméra, le micro et la caméra associée au micro.

Schéma de flux allant du cadenas à l'invite de géolocalisation, qui, si elle est ignorée, affiche l'icône "Géolocalisation bloquée", qui, après un délai de quatre secondes, est finalement remplacée par le cadenas.

Forcer la nouvelle interface

Comme il s'agit d'un déploiement par étapes, vous pouvez forcer la nouvelle interface en activant les indicateurs suivants:

  • chrome://flags/#permission-chip
  • chrome://flags/#permission-chip-gesture
  • chrome://flags/#permission-chip-request-type

Flux de la nouvelle interface

Sans geste de l'utilisateur

Pour les autorisations non essentielles qui ne sont pas déclenchées par un geste, l'invite n'interfère plus avec le contenu du site et n'insiste pas sur une décision immédiate. L'utilisateur peut ignorer le chip de requête jusqu'à ce qu'il dispose de suffisamment d'informations pour prendre une décision.

Sans interaction

En l'absence d'interaction et après un court délai, le chip de demande se réduit automatiquement à une icône de blocage (pour indiquer que l'autorisation est temporairement bloquée), avant d'être complètement fermé. L'objectif est de ne pas gêner les utilisateurs qui choisissent de ne pas prendre de décision, en leur permettant de le faire sans interaction.

Schéma de flux allant du cadenas à la puce de géolocalisation discrète, qui, après un délai de 12 secondes, affiche l'icône "Géolocalisation bloquée", qui, après un délai de 4 secondes, est finalement remplacée par le cadenas.

Impact attendu à court terme

À court terme, et jusqu'à ce que les utilisateurs s'habituent à la nouvelle interface utilisateur, il est probable que les propriétaires de sites observent des taux d'autorisation plus faibles pour leurs sites, en particulier pour ceux qui demandent automatiquement des autorisations sans amorçage ni demande d'action de l'utilisateur (ce qui est considéré comme une mauvaise pratique de toute façon). Cet inconvénient reconnu est largement compensé par une expérience moins intrusive.

Bonnes pratiques

Il appartient au site de s'assurer qu'il fournit le contexte nécessaire et ne demande des autorisations qu'au moment opportun et attendu. Les autorisations qui ont été temporairement bloquées (par un utilisateur qui a ignoré la demande ou ignoré l'invite) peuvent être demandées à nouveau au cours de la même session. Ne le faites que si l'autorisation est essentielle au fonctionnement du site ou de la fonctionnalité. Sinon, vous risquez d'ennuyer les utilisateurs et d'être bloqué automatiquement. Dans ce cas, nous affichons les messages discrets introduits dans Chrome 80. Pour obtenir des conseils plus généraux, consultez la section UX des autorisations.

Perspectives et conclusions

D'autres améliorations de l'UI et de l'UX sont prévues. L'équipe Chrome travaille déjà dessus et étudie le blocage automatique des autorisations potentiellement plus agressif en fonction du comportement précédent. Vous en serez informé ici une fois que ces plans seront finalisés.

En conclusion, la nouvelle interface utilisateur réduit l'insistance perçue sur une décision et améliore l'expérience de navigation. Étant donné que la plupart des requêtes d'autorisation sont bloquées ou ignorées, l'objectif était d'améliorer l'expérience de navigation globale, sans interrompre les parcours utilisateur lors de l'affichage d'une requête d'autorisation, en particulier dans les cas où des autorisations sont requises pour effectuer un cas d'utilisation.

Remerciements

Ce document a été examiné par Joe Medley.