Amphtml: Design Review 2017-07-05 (amp-webpush)

[mrjoro]

Note that we will not have a design review the week of June 28, 2017.

The AMP Project holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

Time: Wednesdays @ 1pm Pacific
Location: Video conference via Google Hangouts

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

If you are unable to make the 1pm Pacific time due to time zone issues but you have a design you would like to present please make a note of that and we will try to find a time that works.

[jasonpang]

I'd like to design review amp-webpush.

Design Doc Link

ITI #8791

[cramforce]

I will miss the first half hour of the meeting.

[mrjoro]

Notes from the design review:

• is this using standard APIs?
  
  
  
  • yes
  
  
• how does the transport work for notifications?
  
  
  
  • it just uses the web push protocol that was introduced a couple of years ago; out of scope for the extension
  
  
  • intent of extension is to support publishers who want to implement it themselves (e.g. their own service worker), but also support people that want to support third party providers of notifications
  
  
• the popup is open on the publisher's domain, so the presence of a third party vendor is completely transparent to the user
  
  
  
  • in the popup the publisher can put whatever content they want
  
  
  • intention is for them to explain what notifications will be shown, etc.
  
  
  • can't use a subdomain, which makes it hard to make it more clear there's a third party involved
  
  
• how does unsubscribe work?
  
  
  
  • looked into an "unsubscribe widget"; currently to remove the permission the user has to go through user settings
  
  
  • you can remove the service worker, but the permission would remain
  
  
  • if users become accustomed to seeing an unsubscribe button on AMP pages it may be inconsistent with the non-AMP pages
  
  
  • Chrome team general
  
  
• once a notification is received, does the AMP runtime see the notification?
  
  
  
  • the payload is received by the service worker, which uses the notification task; the service worker can handle the payload
  
  
  • a notification always has to be shown (in the current browser implementations)
  
  
• should the subscribe button be completely customizable by the publisher?
  
  
  
  • yes, within the constraints of AMP styling
  
  
• are we sure the browser handles the case of the notification being subscribed to in an iframe?
  
  
  
  • all of the permission handling is handled in the popup (because it has to happen at the top level)
  
  
  • but there is an invisible iframe on the AMP page to determine if the user is currently subscribed to notifications (which has to be done on the origin domain)
  
  
• when the notification is received, it doesn't matter if you are viewing an AMP page or not
• relayout of the page
  
  
  
  • a blank spot when the user is subscribed? maybe we can figure it out and collapse it if the user is subscribed
  
  
  • we considered a banner that slides in from below if they are not subscribed; there is some precedence for this (e.g. cookie notices, app install banners); this is @dvoytenko's preferred option; drawback is that this is more of an interruption in the user experience vs. a button that could appear anywhere... we could choose to support both
  
  
  • we can put this in a fixed position to be more restrictive
  
  
  • use amp-bind when you click to hide it after subscribe? that's possible, but it still requires a relayout
  
  
  • maybe within the widget we have a "subscribed" vs. "unsubscribed" UI that would switch and prevent a relayout (as long as it is fixed size layout); this depends on what the website would show in the subscribed case (especially since there's no way to unsubscribe)
  
  
• does this API work with web workers?
  
  
  
  • could help with concerns about iframes being loaded on every page affecting performance
  
  
  • similar to iframes but cheaper; we use them in some places today
  
  
  • haven't yet tried to install a service worker from within a web worker; we should look into this
  
  
• what if they load it in a Custom Chrome Tab? there are no popups in a CCT
  
  
  
  • does CCT even support notification permission? yes
  
  
  • suggestion is to look at how amp-access handles popup vs. redirect; we should ideally make this code common for whenever anything needs to show a popup (it's a small amount of code)
  
  
  • @dvoytenko's suggestion is to just use the same code initially
  
  
  • amp-login-done
  
  
• process for developing it?
  
  
  
  • ideally collaborative with other people on the AMP team
  
  
• installserviceworker? it requires serviceworker URL has to be the same as the one on the AMP site, but a large number of websites serve notifications from an https subdomain (instead of a top-level http domain); given the volume of clients with this setup this doesn't work
• Chrome may be moving to requiring user interaction before the notification permission can be requested; how would this affect things in the future?
  
  
  
  • currently this isn't the case
  
  
  • but if it changes, it could be a button on the popup window ("would you like to see notifications" and user would have to click yes); this would then require three prompts (click on "subscribe" in the initial page, "yes" in the popup, Chrome notification permission UI)
  
  
  • we could potentially use the user action tokens we've talked about in the past if they exist
  
  
  • @ithinkihaveacat will follow up with Chrome team to find out more details