L'étape naturelle après avoir obtenu un PushSubscription et l'avoir enregistré sur notre serveur consiste à déclencher un message push, mais il y a une chose que je n'ai pas remarquée de manière flagrante. L'expérience utilisateur lorsque l'utilisateur demande l'autorisation de lui envoyer des messages push.
Malheureusement, très peu de sites accordent beaucoup d'importance à la façon dont ils demandent l'autorisation de l'utilisateur. Examinons donc à la fois les bonnes et les mauvaises expériences utilisateur.
Schémas courants
Quelques modèles courants ont vu le jour. Ils devraient vous guider et vous aider à déterminer ce qui convient le mieux à vos utilisateurs et à votre cas d'utilisation.
Proposition de valeur
Demandez aux utilisateurs de s'abonner pour les pousser au moment où l'avantage est évident.
Par exemple, un utilisateur vient d'acheter un article dans une boutique en ligne et de terminer le processus de paiement. Le site peut ensuite fournir des mises à jour sur l'état de la livraison.
Cette approche est efficace dans de nombreuses situations:
- Un article spécifique n'est plus disponible. Souhaitez-vous recevoir une notification lorsqu'il sera de nouveau disponible ?
- Ce reportage sera régulièrement mis à jour. Souhaitez-vous être informé de l'évolution de l'actualité ?
- Vous êtes le meilleur enchérisseur. Souhaitez-vous être averti en cas de surenchère ?
Il s'agit de tous les points où l'utilisateur a investi dans votre service. Il existe une proposition de valeur claire qui lui permettra d'activer les notifications push.
créé une simulation du site Web d’une compagnie aérienne hypothétique pour démontrer cette approche.
Une fois que l'utilisateur a réservé un vol, il lui demande s'il souhaite recevoir des notifications de retard.
Notez qu'il s'agit d'une interface utilisateur personnalisée issue du site Web.
Autre avantage de la démonstration d'Owen : si l'utilisateur clique pour activer les notifications, le site ajoute une superposition semi-transparente sur l'ensemble de la page lorsqu'il affiche l'invite d'autorisation. Cela attire l'attention des utilisateurs sur l'invite d'autorisation.
L'alternative à cet exemple, la mauvaise expérience utilisateur pour demander l'autorisation, consiste à demander l'autorisation dès qu'un utilisateur accède au site de la compagnie aérienne.
Cette approche ne fournit aucun contexte sur les raisons pour lesquelles les notifications sont nécessaires ou utiles pour l'utilisateur. L'utilisateur ne peut pas non plus atteindre sa tâche d'origine (par exemple, réserver un vol) par cette invite d'autorisation.
Double autorisation
Vous pensez peut-être que votre site présente un cas d'utilisation clair des messages push. Vous souhaitez donc peut-être demander l'autorisation de l'utilisateur dès que possible.
Par exemple, messagerie instantanée et clients de messagerie. Afficher un message pour un nouveau message ou e-mail constitue une expérience utilisateur établie sur plusieurs plates-formes.
Pour ces catégories d'applications, il est utile d'envisager le modèle d'autorisation double.
Affichez d'abord une fausse invite d'autorisation contrôlée par votre site Web, sous la forme de boutons permettant d'autoriser ou d'ignorer la demande d'autorisation. Si l'utilisateur clique sur "Autoriser", demandez l'autorisation, ce qui déclenche l'invite d'autorisation réelle du navigateur.
Cette approche vous permet d'afficher une invite d'autorisation personnalisée dans votre application Web, qui demande à l'utilisateur d'activer les notifications. Il pourra ainsi choisir d'activer ou de désactiver votre site sans risquer d'être bloqué définitivement. Si l'utilisateur sélectionne "Activer" dans l'interface utilisateur personnalisée, affichez l'invite d'autorisation réelle. Sinon, masquez votre pop-up personnalisée et demandez un autre moment.
En voici un bon exemple . Une fois que vous êtes connecté, un message s'affiche en haut de la page, vous demandant si vous souhaitez activer les notifications.
Panneau des paramètres
Vous pouvez déplacer les notifications dans un panneau de paramètres, ce qui permet aux utilisateurs d'activer et de désactiver facilement la messagerie push, sans avoir à encombrer l'interface utilisateur de votre application Web.
En voici un bon exemple . Lorsque vous chargez le site Google I/O pour la première fois, aucune action ne vous est demandée. L'utilisateur peut alors l'explorer.
Après quelques visites, cliquez sur l'élément de menu à droite pour afficher un panneau de paramètres permettant à l'utilisateur de configurer et de gérer les notifications.
Cliquez sur la case à cocher pour afficher l'invite d'autorisation. Aucune surprise cachée.
Une fois l'autorisation accordée, la case est cochée et l'utilisateur est prêt à l'utiliser. L'avantage de cette interface utilisateur, c'est que les utilisateurs peuvent activer et désactiver les notifications à partir d'un seul endroit du site Web.
Approche passive
L'un des moyens les plus simples de proposer la fonctionnalité Push à l'utilisateur consiste à disposer d'un bouton ou d'un interrupteur qui permet d'activer ou de désactiver les messages push à un emplacement homogène sur l'ensemble du site.
Cela n'encourage pas les utilisateurs à activer les notifications push, mais leur offre un moyen fiable et facile d'activer ou de désactiver l'interaction avec votre site Web. Il s'agit d'une option intéressante pour les sites tels que les blogs, qui peuvent attirer des visiteurs réguliers ainsi que des taux de rebond élevés, car elle cible les internautes réguliers sans déranger les visiteurs réguliers.
Sur mon site personnel, j'ai un bouton bascule pour les messages push dans le pied de page.
C'est un peu compliqué, mais pour les visiteurs réguliers, elle devrait attirer suffisamment l'attention des lecteurs souhaitant obtenir des informations. Les visiteurs ponctuels ne sont pas du tout affectés.
Si l'utilisateur s'abonne aux messages push, l'état du bouton bascule change et conserve l'état sur l'ensemble du site.
La mauvaise expérience utilisateur
Voici quelques-unes des pratiques courantes que j'ai constatées sur le Web. Malheureusement, il existe une mauvaise pratique très courante.
La pire chose que vous puissiez faire est d'afficher la boîte de dialogue d'autorisation dès qu'ils accèdent à votre site.
Ils n'ont aucun contexte sur les raisons pour lesquelles on leur demande une autorisation. Ils ne savent peut-être même pas à quoi sert votre site Web, à quoi il sert ni ce qu'il propose. Bloquer les autorisations à ce stade par frustration n'est pas rare, ce pop-up les empêche de faire ce qu'ils essaient de faire.
N'oubliez pas que si l'utilisateur bloque la demande d'autorisation, votre application Web ne pourra pas la redemander. Pour obtenir l'autorisation après avoir été bloqué, l'utilisateur doit modifier l'autorisation dans l'interface utilisateur du navigateur, ce qui n'est pas facile, évident ou amusant pour l'utilisateur.
Quoi qu'il en soit, ne demandez pas d'autorisation dès que l'utilisateur ouvre votre site. Envisagez une autre interface utilisateur ou approche qui incite l'utilisateur à donner son autorisation.
Proposez une sortie
En plus d'envisager l'expérience utilisateur pour abonner un utilisateur aux notifications push, veuillez réfléchir à la manière dont il doit se désabonner ou désactiver les messages push.
Le nombre de sites qui demandent une autorisation dès le chargement de la page et n'offrent pas d'interface utilisateur pour désactiver les notifications push est stupéfiant.
Votre site doit expliquer à vos utilisateurs comment désactiver le mode push. Si vous ne le faites pas, les utilisateurs risquent de choisir l'option nucléaire et de bloquer définitivement l'autorisation.
Étapes suivantes
- Présentation des notifications push Web
- Fonctionnement du mode Push
- S'abonner d'un utilisateur
- Autorisation UX
- Envoyer des messages avec les bibliothèques Web Push
- Protocole Web push
- Gérer les événements push
- Afficher une notification
- Comportement des notifications
- Schémas de notification courants
- Questions fréquentes sur les notifications push
- Problèmes courants et signalement de bugs