The natural step after getting a
PushSubscription and saving it our server is to trigger a push message, but there is one thing I flagrantly glossed over. The user experience when asking for permission from the user to send them push messages.
Sadly, very few sites give much consideration as to how they ask their user for permission, so lets take a brief aside to look at both good and bad UX.
There have been a few common patterns emerging that should guide / help you when deciding what is best for your users and use case.
Encouraging a user to subscribe to push messaging at a time where the benefit is obvious given the current context is a fantastic way to get users to grant permission.
For example, a user has just bought an item on an online store and finished the checkout flow, the site can then offer updates on the delivery status.
There are a range of situations where this pattern / approach works:
- A particular item is out of stock, would you like to notified when it’s next available?
- This breaking news story will be regularly updated, would you like to be notified as the story develops?
- You’re the highest bidder, would you like to be notified if you are outbid?
These are all points where the user has invested in your service and there is a clear value proposition for them to enable push notifications.
Owen Campbell-Moore created a mock site for an airline that demonstrates this approach.
After the user has booked a flight asks if the user would like notifications in case of flight delays.
Note that this isn’t the browser UI as well, this is a custom UI in the web site asking the user, allowing the site full control over the messaging to the user.
Another nice touch to Owen’s demo is that if the user does click to enable notification, the site adds a semi-transparent overlay over the entire page when it shows the permission prompt. This helps draw the users attention to the permission prompt.
The alternative to this example, the bad UX for asking permission, is to request permission as soon as a user lands on the airline’s site.
No context as to what the notifications are for, if the user wanted to get a task done (i.e. check a flight or book a flight), this permission prompt gets in the way of that and secondly it’s not a good look having a pop-up over the site.
You may feel that your site has a clear need for push messaging and as a result want to ask the user for permission as soon as possible. An example of this sites that fit into this category are messaging sites or email clients. You receiving a message or email, show a notification.
In these cases, it’s worth considering the double permission UX.
With this approach you display a custom permission prompt in your web app which asks the user to enable notifications. By doing this the user can say enable or disable without risk of being permanently blocked. If the user selects enable on the custom UI, display the actual permission prompt, otherwise hide your custom pop-up and ask some other time.
A good example of this is Slack. They show a prompt at the top of their page once you’ve signed in asking if you’d like to enable notifications.
If the user clicks accept, the actual permission prompt is shown:
I was also a big fan of Slacks first notification when you allow the permission.
You can move notifications into a settings panel, giving users an easy way to enable and disable push messaging, without the need of cluttering your web app’s UI.
A good example of this is Google I/O’s 2016 site. When you first load up the Google I/O site, you aren’t asked to do anything, the user is left to explore the site.
After a few visits of clicking the menu item on the right, a settings panel is reveal to the user, allowing them to set up and manage notifications.
Clicking on the checkbox displays the permission prompt, no hidden surprises.
After the permission has been granted the checkbox is checked and the user is good to go. The great thing about this UX is that the location to sign up for push is the same location to disable push.
Slack also does a good job at giving users control over their notifications. They offer a host of options allowing users to customise the notifications they receive.
One of the easiest ways to offer push to a user is to have a button or toggle switch that enables / disables push messages in a location on the page that is consistent throughout a site.
This doesn’t drive users to enable push notifications, but consistency and allowing users to opt in and out easily without constant nudging gives users a way to engage with a site / service / brand if and when they want to. For sites like blogs that might have some regular viewers as well as high bounce rates, this is a solid option as it targets regular viewers without annoying drive-by visitors.
On my personal site I have a toggle switch for push messaging in the footer.
It’s fairly out of the way, but for regular visitors it should get enough attention from readers wanting to get updates. People landing on my site to get some information and leave are completely unaffected, I doubt they even notice the the toggle switch.
If you grant permission the state of the toggle switch changes and remains in the same location through the pages.
The Bad UX
Those are some of the common practices I’ve noticed on the web. Sadly there is one very common bad practice.
The worst thing you can do is instantly show the permission dialog to a user as soon as they land on your site.
They have zero context on why they are being asked for a permission, they may not even know what your website is for, what it does or what it offers. Blocking permissions at this point out of frustration is not uncommon, this pop-up is getting in the way of what they are trying to do.
Remember, if the user blocks the permission request, your web app can’t ask for permission again. To get permission after being blocked the user has to change the permission in the browsers UI and it is not easy, obvious or fun for the user.
No matter what, don’t ask for permission as soon as the user opens your site, consider some other UI or approach that has an incentive for the user to grant permission.
Offer a Way Out
Aside from considering the UX to subscribe a user to push, please consider how a user should unsubscribe / opt out of push messaging.
The number of sites that ask for permission as soon as the page load and then offer no UI for disabling push notifications is astounding.
Vice News is an example of this practice. (p.s. sorry Vice for using you as an example, you were first site I recalled doing this, although I believe it’s fixed now.)
When you land on Vice News you’d get the permission prompt. This isn’t the end of the world, but it does offend the senses.
If you allow notifications, where would you go to disable them? The websites UI doesn’t change at all.
This UX pushes the responsibility of notification management onto the browser, which frankly is awful in Chrome.
As a result, sites are getting users signed up, then forcing them to trial and error their way through the browser UX to disable notifications.
If you’re curious what the Browser UX is for disabling push, the desktop has two options. You can visit the web page and click the padlock in the URL bar to configure permissions.
If the web page is closed, users can click the cog on a notification, which takes the user to this page in the settings of Chrome.
Neither of these options are particularly pleasant for the user.
Your site should explain to your users how they can disable push. If you don’t, users are likely to take the nuclear option and block permission permanently.