Intent to Experiment: Notification Triggers

[Richard Knoll]

Contact emails

kno...@chromium.org, pe...@chromium.org

Spec

Explainer: https://github.com/rknoll/notification-triggers

Summary

Showing notifications at a specific time requires web applications to use the Push API. This is not ideal as it requires an active network connection and needs to wake up the browser to fetch additional data like image resources.

With this API we allow developers to prepare notifications in advance to be shown at a specific time in the future. At that time no additional network request is required anymore and no service worker code needs to run in order to show the notification.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/sFb2H2pwEug/discussion

Goals for experimentation

We’d like to get developer feedback on this new API to see which use cases we haven’t thought about. We’ve designed this API to be extendable for other types of triggers (e.g. location based) if there is sufficient interest for this.

Experimental timeline

M78 - M81

Any risks when the experiment finishes?

No.

Ongoing technical constraints

None

Debuggability

Chrome DevTools already provides a UI to show events related to notifications such as scheduled, displayed and closed. Developers can also get a list of all notifications, including scheduled ones, via a JavaScript API.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes, except WebView as the Notification API is not supported yet (tracking bug).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5133150283890688

[Yoav Weiss]

On Fri, Sep 6, 2019 at 6:14 PM 'Richard Knoll' via blink-dev <blin...@chromium.org> wrote:

Contact emails

kno...@chromium.org, pe...@chromium.org

Spec

Explainer: https://github.com/rknoll/notification-triggers

Summary

Showing notifications at a specific time requires web applications to use the Push API. This is not ideal as it requires an active network connection and needs to wake up the browser to fetch additional data like image resources.

With this API we allow developers to prepare notifications in advance to be shown at a specific time in the future. At that time no additional network request is required anymore and no service worker code needs to run in order to show the notification.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/sFb2H2pwEug/discussion

Goals for experimentation

We’d like to get developer feedback on this new API to see which use cases we haven’t thought about. We’ve designed this API to be extendable for other types of triggers (e.g. location based) if there is sufficient interest for this.

Are you planning to also gather user feedback (either directly or through metrics) to make sure this is not degrading their experience?

Have you considered the abuse potential for this and ways to mitigate it?

(the latter question is not necessarily something that requires concrete answers before starting an OT, but it's definitely good to start asking those questions at this point)

 

Experimental timeline

M78 - M81

Any risks when the experiment finishes?

No.

Ongoing technical constraints

None

Debuggability

Chrome DevTools already provides a UI to show events related to notifications such as scheduled, displayed and closed. Developers can also get a list of all notifications, including scheduled ones, via a JavaScript API.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes, except WebView as the Notification API is not supported yet (tracking bug).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5133150283890688

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKBTsuScKr2gsKF%2B9f7ca9SA1F68QdeNo6ARoFeLkXj67zFjkw%40mail.gmail.com.

[kno...@chromium.org]

On Friday, September 13, 2019 at 1:23:45 AM UTC+9, Yoav Weiss wrote:

Are you planning to also gather user feedback (either directly or through metrics) to make sure this is not degrading their experience?

Have you considered the abuse potential for this and ways to mitigate it?

(the latter question is not necessarily something that requires concrete answers before starting an OT, but it's definitely good to start asking those questions at this point)

We'll gather basic metrics to measure usage and how developers use the API (e.g. how far into the future do they schedule notifications). Another metric could be to measure the time delay between the scheduled time and the actual display time. I'm not sure how to compare that to the alternative (push messages) though. Do you have other ones in mind to measure the experience for users?

As to possible abuse of this, yes, we have and are thinking about this. For example, we currently require sites to show a notification as a response to a push message to make sure the user is informed about that background activity. Scheduling a notification with a trigger will *not* count as showing one in the first implementation. This is to avoid sites to simply schedule one very far ahead to get around the visibility requirement of push messages.

Thanks!

- Richard

[Chris Harrelson]

LGTM

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/42961f5b-cd1e-413f-ae1f-b09f2fa0f208%40chromium.org.

[Richard Knoll]

Hi, quick update on this I2E, it will now start with M80 instead of M78.

Experimental timeline

M80 - M83

Thanks!

- Richard