Re: Push API change for permissions UX

On Sat, Oct 25, 2014 at 11:42 PM, Jake Archibald wrote: > This discussion is about how often push may be processed silently (without > showing a notification), not if a push notification may *only* show a > notification. Ok. I think this comes back to the old problem of that different UAs have d

Re: Push API change for permissions UX

Example https://www.youtube.com/watch?v=0i7YdSEQI1w - Twitter shows notifications without caching, creating a poor offline (or poor connectivity) experience. You can actually be left with less information after tapping the notification than before. On 26 October 2014 06:42, Jake Archibald wrote:

Re: Push API change for permissions UX

This discussion is about how often push may be processed silently (without showing a notification), not if a push notification may *only* show a notification. The latter was shown to be insufficient in the other thread. On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore wrote: >> I think it mig

Re: Push API change for permissions UX

On Fri, Oct 24, 2014 at 9:39 AM, Owen Campbell-Moore wrote: >> I think it might make sense to ask for permission to display >> notifications/UI at the same time as you ask for permission to "run in the >> background". > > I hope the above explains why we believe that while some sites may want to >

Re: Push API change for permissions UX

Hi All - my name is Owen and I recently joined the Chrome team. Taking a step back, we believe users have control such that they can permit a site to send them notifications (or notify them of an event using other UI) without permitting it to run arbitrarily in the background without their knowled

Re: Push API change for permissions UX

On 24 October 2014 09:09, John Mellor wrote: > For background sync[1], such a throttling approach would be ideal, as there > is no expectation of timeliness. But push is different: users can come to > depend on timely delivery of push notifications, and sufficiently > heavy-handed throttling would

Re: Push API change for permissions UX

On 23 October 2014 23:29, Martin Thomson wrote: > It means that important features that provide > these measures (do not disturb, more contextual event filtering) are > not available to applications by default. > System-wide do-not-disturb would still work (for example in Android Lollipop

Re: Push API change for permissions UX

On 23 October 2014 04:10, John Mellor wrote: > Can you elaborate? This would attach no penalty to developers who don't opt > in (at the one time cost of an additional permission prompt); and as I > explained above, developers who do opt in would indeed be incentivized to > always show user-visible

Re: Push API change for permissions UX

On 22 October 2014 20:55, Jonas Sicking wrote: > However I don't think that it makes sense for apps to commit to > displaying UI when there's an incoming push. I'm not sure what problem > that would solve? It means the user is aware of incoming pushes, which alleviates two concerns: 1. Geoip t

Re: Push API change for permissions UX

On 22 October 2014 11:02, John Mellor wrote: > a restricted form of push where each push event fired on the SW must trigger > user-visible UI. How would that work? Is the idea that there would be a default notification that the SW could alter the contents of (perhaps), but not prevent or indefini

Re: Push API change for permissions UX

Hi John, I think it *might* make sense to ask for permission to display notifications/UI at the same time as you ask for permission to "run in the background". Though someone would definitely need to check with mozilla's security team to see how they feel since I know they've generally wanted to

Push API change for permissions UX

Hi folks, Based on our UX studies for Chrome, we’ve found the clearest way to do permissions UX for the Push API will be to have one prompt[1] that grants both full push messaging and background sync[2], and a separate prompt[3] that grants notifications plus a restricted form of push where each p