Il passaggio naturale dopo aver ricevuto un PushSubscription e averlo salvato sul nostro server è attivare un messaggio push, ma c'è una cosa che ho omesso. L'esperienza utente quando viene chiesta all'utente l'autorizzazione per inviare messaggi push.
Purtroppo, pochissimi siti prestano molta attenzione al modo in cui chiedono all'utente di dare il consenso, quindi facciamo una breve digressione per esaminare le esperienze utente positive e negative.
Pattern comuni
Sono emersi alcuni schemi comuni che dovrebbero guidarti e aiutarti a decidere cosa è meglio per i tuoi utenti e per 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 pagamento. Il sito può quindi offrire aggiornamenti sullo stato di consegna.
Questo approccio funziona in una serie di situazioni:
- Un determinato articolo non è disponibile. Vuoi ricevere una notifica quando sarà di nuovo disponibile?
- Questa notizia verrà aggiornata regolarmente. Vuoi ricevere una notifica man mano che la notizia si evolve?
- Sei il miglior offerente. Vuoi ricevere una notifica se qualcuno fa un'offerta più alta della tua?
Questi sono tutti punti in cui l'utente ha investito nel tuo servizio e c'è una proposta di valore chiara per attivare le notifiche push.
Abbiamo creato un mock di un sito web di una compagnia aerea ipotetica per dimostrare questo approccio.
Dopo che l'utente ha prenotato un volo, gli viene chiesto se vuole ricevere notifiche relative ai ritardi del volo.
Tieni presente che si tratta di un'interfaccia utente personalizzata del sito web.
Un altro tocco di classe nella demo di Owen è che, se l'utente fa clic per attivare le notifiche, il sito aggiunge un overlay semitrasparente all'intera pagina quando viene visualizzata la richiesta di autorizzazione. In questo modo, l'utente viene attirato dalla richiesta di autorizzazione.
L'alternativa a questo esempio, ovvero una esperienza utente negativa 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 la sua attività originale (ad es. prenotare un volo).
Autorizzazione doppia
Potresti ritenere che il tuo sito abbia un caso d'uso chiaro per i messaggi push e quindi voler chiedere all'utente l'autorizzazione il prima possibile.
Ad esempio, client di posta elettronica e messaggistica istantanea. 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, viene mostrata una richiesta di autorizzazione falsa controllata dal tuo sito web, composta da pulsanti per consentire o ignorare la richiesta di autorizzazione. Se l'utente fa clic su Consenti, richiedi l'autorizzazione, attivando la richiesta di autorizzazione del browser reale.
Con questo approccio, nella tua app web viene visualizzato un messaggio di richiesta di autorizzazione personalizzato che chiede all'utente di attivare le notifiche. In questo modo, l'utente può scegliere di attivare o disattivare la funzionalità senza che il tuo sito web rischi di essere bloccato definitivamente. Se l'utente seleziona Attiva nell'interfaccia utente personalizzata, mostra la richiesta di autorizzazione effettiva, altrimenti nascondi il popup personalizzato e chiedi di nuovo in un secondo momento.
Un buon esempio è Una volta eseguito l'accesso, nella parte superiore della pagina viene visualizzato un messaggio che ti chiede se vuoi attivare le notifiche.
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 è Quando carichi per la prima volta il sito Google I/O, non ti viene chiesto di fare nulla, l'utente è libero di esplorare il sito.
Dopo alcune visite, facendo clic sul menu a destra viene visualizzato un riquadro di 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.
Una volta concessa l'autorizzazione, la casella di controllo viene selezionata e l'utente può procedere. La grande funzionalità di questa UI è che gli utenti possono attivare e disattivare le notifiche da una posizione sul sito web.
Approccio passivo
Uno dei modi più semplici per offrire la funzionalità push a un utente è avere un pulsante o un pulsante di attivazione/disattivazione che attivi/disattivi i messaggi push in una posizione della pagina coerente in tutto il sito.
In questo modo, non induci gli utenti ad attivare le notifiche push, ma offri loro un modo affidabile e semplice per attivare e disattivare il coinvolgimento con il tuo sito web. Per siti come i blog che potrebbero avere alcuni spettatori abituali e un tasso di rimbalzo elevato, questa è un'opzione solida in quanto ha come target gli spettatori abituali senza infastidire i visitatori di passaggio.
Sul mio sito personale, ho un pulsante di attivazione/disattivazione per i messaggi push nel piè di pagina.
È abbastanza fuori mano, ma per i visitatori abituali dovrebbe attirare sufficiente attenzione da parte dei lettori che vogliono ricevere aggiornamenti. I visitatori una tantum 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.
L'esperienza utente negativa
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 di autorizzazione agli utenti non appena accedono al tuo sito.
Non hanno alcun contesto sul motivo per cui gli viene chiesta un'autorizzazione e potrebbero persino non sapere a cosa serve il tuo sito web, cosa fa o cosa offre. A questo punto, non è insolito che gli utenti blocchino le autorizzazioni per frustrazione, perché 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ò più chiederla. Per ottenere l'autorizzazione dopo il blocco, l'utente deve modificare l'autorizzazione nell'interfaccia utente 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 valuta un'altra UI o un altro approccio che incentivi l'utente a concedere l'autorizzazione.
Offri una via d'uscita
Oltre a considerare l'esperienza utente per l'iscrizione di un utente ai messaggi push, tieni conto di come un utente deve annullare l'iscrizione o disattivare i messaggi 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 è sorprendente.
Il tuo sito deve spiegare agli utenti come disattivare le notifiche push. In caso contrario, gli utenti probabilmente opteranno per l'opzione nucleare e bloccheranno l'autorizzazione definitivamente.
Passaggi successivi
- Panoramica delle notifiche push web
- Come funzionano le notifiche push
- Registrazione di un utente
- UX per le autorizzazioni
- Invio di messaggi con le librerie Web Push
- 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 bug dei report