Discourse Push Notifications

official

(Alan Tan) #226

If you are using Chrome or Firefox on iOS, it should still work.


(Felix) #227

In his tests, it didnt. I don’t own an iOS-Device, so I cant test it on my own.


(Mittineague) #228

Are you sure? I was under the impression that other browsers were like “wrappers” with the same webkit and nitro under the hood. This has changed?


(Jeff Wong) #229

Got to the bottom of this by finding an old iPad to test on, and I can confirm the bug. It’s fixed in the latest.

Thanks for reporting!


(Felix) #230

Thanks for fixing! I’ll add a german translation for the new features tomorrow :wink:


(Alan Tan) #231

Oops you’re right. I just remembered the plugin does not support iOS devices.


#232

Hello people!

I have a question regarding the Your site must use HTTPS part…
I’m running Discourse behind NGINX reverse proxy. Till the proxy, there is https enabled, but then all of the traffic goes to :80 port of the container.
In order for this plugin to work, should I have the traffic go to the https port of the container or not?

Right now, the plugin isn’t working and I’m trying to identify the issue

Thank you for your time!


(Alan Tan) #235

As long as the site is loaded over HTTPS, it should work. Whether the traffic from your proxy to the container is over https or not does not matter AFAIK.


(Jeff Wong) #236

A few new features from the past week:

Banner prompt

When enabled, this adds a banner for push notifications. It has been refined to fit in to the look and feel of other notification banners such that it does not steal too much real estate while still being an important element on the page:

Icons

The icon sets are now unified to match the notification icons from the notification dropdown:

You now have the ability to customize the small “badge” icon shown in the corners of the notifications using the push notifications icon url setting. This is best customized with 96x96 monochrome images with transparency.

Eg, if I were to use my user icon:

The notification will display as follows:

That’s all for now!


New notification permissions request bar?
(Rafael dos Santos Silva) #237

Yay it’s also working on Firefox mobile!


(Kane York) #238

Can you add a hook into the existing notifications permission request instead? Personally, when I see a bar like this I instinctively “bounce” and try to tell the website “no”.
I had a pretty striking double-take when I saw that it was Meta with that annoying bar!


(Kane York) #239

Just refreshed after accepting the permission popup that appeared without clicking on the banner, and it’s still there:


(Mittineague) #240

I have that, but I think that is for Desktop notifications, that I do have enabled.

I’m not sure if it might be related, but earlier I allowed Push notifications and soon after my browser (Vivaldi) became unresponsive. It could be because I was running a resource heavy query locally, but maybe not?


(Rafael dos Santos Silva) #241

Most sites are using a “pre-permission” banner, trying to be less intrusive. The default Chrome UI for example on mobile is a blocking popup :scream:.

Example:

Of course we still care and don’t want to annoy our users. Do you think we need to tweak any banner criteria?

Good catch, I think we need to check for Notification.permission != 'granted in


(Kane York) #242

Ideally, the push notifications plugin would be able to hook into this code here:

discourse/desktop-notifications.js.es6 at 7a093ea5d675d36092c3baf7fcb2a7ae40d200d9 · discourse/discourse · GitHub

So that when someone clicks “Accept” they get automatically signed up for push notifications.

The only time the plugin should be adding its own banner is when Notification.permission === 'granted' but !pushNotificationSubscribed - i.e. someone accepted desktop notifications before the plugin was installed.

Really? You must be in a different experiment cohort, I get a scroll-dismissable bottom-of-the-screen “popup” tray. (It goes away when I scroll down & comes back when I scroll up, in sync with the URL bar hiding/appearing.)


(Jeff Wong) #243

You do bring up a few good points of feedback:

  • I should not display the banner when the user has accepted permissions.
  • I need to find a way to better integrate the two notification systems - push notifications and desktop notifications.

re: notification permission prompts, I also see the super annoying popup:

Worse, I need to allow or block now - I cannot dismiss or defer it by clicking outside of it, either. If it prompts without me doing anything, I’m inclined to deny the things. I could have sworn I had a version before where I had the tray like you mentioned, but this is what I see now.

This is why I think the banner is a good compromise. Until we can be sure that all browsers have some slick out-of-the-way signal to inform the user the website wants to send notifications, this is the best option for those who want to prompt.


(Kane York) #244

In that case, the wording could definitely be improved.

Do you want push notifications when people reply to your posts? Enable           :x:


(Jeff Wong) #245

Ah, nice - I am 100% down for rewording the banner. I like the way that shows context as to why the software wants your permissions :+1:


(Rafael dos Santos Silva) #246

I think we should go with “replied” instead of “mentioned” which is more frequent and easier to understand.


(Kane York) #247

And that wording suggests a different time to ask for permissions - right after you post something and the question hasn’t been answered yet.

Instead of asking as soon as you log in, by asking right after you’ve made a post1, the value proposition is extremely obvious and people can give Informed Consent to receive notifications.

1: Except for the @/discobot intro PM, that should be excluded from the permission prompt banner.