Il passaggio naturale dopo aver ottenuto un PushSubscription e averlo salvato sul nostro server è attivare un messaggio push, ma c'è una cosa che ho palesemente tralasciato. L'esperienza utente quando viene richiesta l'autorizzazione per l'invio di messaggi push.
Purtroppo, pochissimi siti prestano molta attenzione al modo in cui chiedono l'autorizzazione all'utente, quindi facciamo una breve digressione per esaminare sia la UX buona che quella cattiva.
Pattern comuni
Sono emersi alcuni pattern comuni che dovrebbero guidarti e aiutarti a decidere cosa è meglio per i tuoi utenti e il tuo caso d'uso.
Proposta di valore
Chiedi agli utenti di iscriversi alle notifiche push quando il vantaggio è evidente.
Ad esempio, un utente ha appena acquistato un articolo in un negozio online e ha completato il flusso di checkout. Il sito può quindi offrire aggiornamenti sullo stato della consegna.
Questo approccio funziona in diverse situazioni:
- Un articolo specifico non è disponibile. Vuoi ricevere una notifica quando sarà di nuovo disponibile?
- Questa notizia dell'ultima ora verrà aggiornata regolarmente. Vuoi ricevere una notifica man mano che la storia si sviluppa?
- La tua offerta è la più alta. Vuoi ricevere una notifica se viene superata?
Questi sono tutti punti in cui l'utente ha investito nel tuo servizio e c'è una chiara proposta di valore per l'attivazione delle notifiche push.
Owen ha creato un modello di un sito web di una compagnia aerea ipotetica per dimostrare questo approccio.
Dopo che l'utente ha prenotato un volo, chiede se vuole ricevere notifiche sui ritardi dei voli.
Tieni presente che si tratta di una UI personalizzata del sito web.
Un altro tocco interessante della demo di Owen è che se l'utente fa clic per attivare le notifiche, il sito aggiunge un overlay semitrasparente sull'intera pagina quando mostra la richiesta di autorizzazione. In questo modo, l'attenzione degli utenti viene attirata sulla richiesta di autorizzazione.
L'alternativa a questo esempio, la UX non ottimale per la richiesta di autorizzazione, è richiedere l'autorizzazione non appena un utente arriva sul sito della compagnia aerea.
Questo approccio non fornisce alcun contesto sul motivo per cui le notifiche sono necessarie o utili per l'utente. Inoltre, questa richiesta di autorizzazione impedisce all'utente di completare l'attività originale (ad es. prenotare un volo).
Doppia autorizzazione
Potresti ritenere che il tuo sito abbia un caso d'uso chiaro per la messaggistica push e, di conseguenza, voler chiedere l'autorizzazione all'utente il prima possibile.
Ad esempio, client di messaggistica immediata e client di posta. La visualizzazione di un messaggio per un nuovo messaggio o un'email è un'esperienza utente consolidata su una serie di piattaforme.
Per questa categoria di app, vale la pena prendere in considerazione il pattern di doppia autorizzazione.
Innanzitutto, mostra una finestra di dialogo controllata dal tuo sito web, che spiega il valore del caso d'uso del tuo sito. La finestra di dialogo può quindi offrire pulsanti per attivare o ignorare la richiesta di autorizzazione necessaria. Se l'utente fornisce un segnale positivo, richiedi l'autorizzazione, attivando la richiesta di autorizzazione del browser reale.
Con questo approccio, mostri un prompt personalizzato nella tua app web che fornisce prima il contesto. In questo modo, l'utente può scegliere di attivare o disattivare la funzionalità senza che il tuo sito web corra il rischio di essere bloccato definitivamente perché l'utente è stato infastidito da una richiesta di autorizzazione imprevista. Se l'utente seleziona Attiva nella UI personalizzata, visualizza la richiesta di autorizzazione effettiva, altrimenti nascondi la finestra di dialogo personalizzata e rispetta la scelta dell'utente.
Puoi scoprire di più sulle best practice per le autorizzazioni e su come Google Meet ha migliorato il proprio flusso di autorizzazioni.
Riquadro delle impostazioni
Puoi spostare le notifiche in un riquadro delle impostazioni, offrendo agli utenti un modo semplice per attivare e disattivare la messaggistica push, senza dover ingombrare l'interfaccia utente della tua app web.
Un buon esempio è il sito di Google I/O. Quando carichi per la prima volta il sito di Google I/O, non ti viene chiesto di fare nulla, l'utente può esplorare il sito.
Dopo alcune visite, facendo clic sulla voce di menu a destra viene visualizzato un riquadro delle impostazioni che consente all'utente di configurare e gestire le notifiche.
Se fai clic sulla casella di controllo, viene visualizzata la richiesta di autorizzazione. Nessuna sorpresa nascosta.
Dopo che l'autorizzazione è stata concessa, la casella di controllo viene selezionata e l'utente può procedere. Il vantaggio di questa UI è che gli utenti possono attivare e disattivare le notifiche da un'unica posizione sul sito web.
Approccio passivo
Uno dei modi più semplici per offrire le notifiche push a un utente è avere un pulsante o un interruttore che attiva/disattiva i messaggi push in una posizione della pagina coerente in tutto il sito.
Questo non spinge gli utenti ad attivare le notifiche push, ma offre un modo affidabile e semplice per attivare e disattivare l'interazione con il tuo sito web. Per i siti come i blog, che potrebbero avere alcuni spettatori abituali, ma anche frequenze di rimbalzo elevate, questa è un'opzione valida perché ha come target gli spettatori abituali senza infastidire i visitatori occasionali.
Sul mio sito personale, ho un pulsante di attivazione/disattivazione per la messaggistica push nel piè di pagina.
È un po' nascosto, ma per i visitatori abituali dovrebbe attirare l'attenzione dei lettori che vogliono ricevere aggiornamenti. I visitatori occasionali non sono interessati.
Se l'utente si iscrive alla messaggistica push, lo stato dell'opzione di attivazione/disattivazione cambia e viene mantenuto in tutto il sito.
La UX scadente
Queste sono alcune delle pratiche comuni che ho notato sul web. Purtroppo, esiste una cattiva pratica molto comune.
La cosa peggiore che puoi fare è mostrare la finestra di dialogo per l'autorizzazione agli utenti non appena arrivano sul tuo sito.
Non hanno alcun contesto sul motivo per cui viene richiesta un'autorizzazione, potrebbero non sapere nemmeno a cosa serve il tuo sito web, cosa fa o cosa offre. Non è raro che gli utenti blocchino le autorizzazioni in questo momento per frustrazione, poiché questo popup ostacola ciò che stanno cercando di fare.
Ricorda che se l'utente blocca la richiesta di autorizzazione, la tua app web non può richiederla di nuovo. Per ottenere l'autorizzazione dopo essere stato bloccato, l'utente deve modificare l'autorizzazione nella UI del browser e questa operazione non è facile, ovvia o divertente per l'utente.
In ogni caso, non chiedere l'autorizzazione non appena l'utente apre il tuo sito, ma prendi in considerazione un'altra UI o un altro approccio che incentivi l'utente a concedere l'autorizzazione.
Offri una via d'uscita
Oltre a considerare la UX per l'iscrizione di un utente alle notifiche push, valuta anche come un utente dovrebbe annullare l'iscrizione o disattivare la messaggistica push.
Il numero di siti che chiedono l'autorizzazione non appena la pagina viene caricata e poi non offrono un'interfaccia utente per disattivare le notifiche push è sbalorditivo.
Il tuo sito deve spiegare agli utenti come disattivare le notifiche push. In caso contrario, è probabile che gli utenti scelgano l'opzione più drastica e blocchino l'autorizzazione in modo permanente.
Passaggi successivi
- Best practice per le autorizzazioni web
- Meno attriti, più controllo: come Google Meet ha migliorato le autorizzazioni audio e video
- Panoramica delle notifiche push web
- Come funziona Push
- Iscrizione di un utente
- Invio di messaggi con le librerie di push sul web
- Protocollo Web Push
- Gestione degli eventi push
- Visualizzazione di una notifica
- Comportamento delle notifiche
- Pattern di notifica comuni
- Domande frequenti sulle notifiche push
- Problemi comuni e segnalazione di bug