notification-triggers
notification-triggers copied to clipboard
beverloo
How can we move this forward?
Notification triggers will be a super valuable feature and the design seems sound, especially the potential for adding geofencing & similar notification trigger types in the future.
I was planning to use this in an app and just saw the notice that the origin trial ended (today?!). How can we get this moving forward? It's a real need for many apps!
Notification triggers will be a super valuable feature and the design seems sound, especially the potential for adding geofencing & similar notification trigger types in the future.
I was planning to use this in an app and just saw the notice that the origin trial ended (today?!). How can we get this moving forward? It's a real need for many apps!
I agree. It's a big addition for the Web. This API in conjunction with the current Notification API and the Push API will give the web platform the tool that was available on the Native platform for ages.
Yes. This looks a very valuable feature. Even I was considering it for an app but came across this thread. It simplifies web-app development significantly and can improve user engagement in a purposeful way. Please bring this back to the table.
+1
@beverloo, who can we reach out to to indicate interest and move this initiative forward?
According to https://web.dev/notification-triggers/#enabling-support-during-the-origin-trial-phase the origin trial will be ending on February 24? Have just realised this API exists, but I want to echo the sentiment of everyone else on this issue. There is a whole category of apps that would need to be built natively without this API - would be great to see this added as it will really move PWAs forward
We ran two Origin Trials for this API, during which we saw very little use and received no feedback on its functionality. That unfortunately doesn't give us the confidence required to determine whether this is the right approach. Next up is a decision on whether to proceed with another Origin Trial or to shelve this for now, which I hope to have time for next week.
We ran two Origin Trials for this API, during which we saw very little use and received no feedback on its functionality. That unfortunately doesn't give us the confidence required to determine whether this is the right approach.
I suspect this is systemic of a chicken and egg problem.
Timely notifications are a mission critical feature, so as an app developer I need something that is guaranteed to work for all platforms. This includes users of other mainline browsers like Firefox, which aren't covered by Google origin trials.
PWAs would be ideal, but unfortunately they lack certain functionality compared to native apps. The PWA framework just isn't mature enough to support apps that require these features.
Thus everyone that would consider this feature useful have already moved onto a write-once-compile-everywhere solution instead. The only people who will show up in origin trials are likely novice developers who don't know better, or hardcore PWA aficionados. Neither are likely to see strong usage metrics, as their audience is either limited to a smaller audience (Chromium users only), and/or is restricted purely to alpha testers.
For example, I've personally been forced to move towards Quasar for my app.
We have observed very decent public support on Twitter, including a high-profile article on CSS Tricks and several talks. This very Issue also has multiple thumb-ups. All this counts as developer signals as defined in the Blink process. The arguments brought forward by @athix are also true. It seems to be a chicken and egg problem indeed.
I second @athix and @tomayac. I think a better way to gauge the need for such a feature would be to simply extrapolate from the usage pattern in native apps, and there it's absolutely ubiquitous. I see no reason to think it'll be any different in PWA. In fact, it's such a fundamental feature, I'm surprised it's still missing (take my use case, for example. All I need is a customizable sound push notification that can be scheduled and work offline. To have to go native for such a minute, basic feature is absurd. I'm sure I'm not alone here...).
Origin trials are not representative. Very few even know about them, let alone participate, and those that do are not representative of the bulk of potential users, so I wouldn't put too much weight on it.
"If you build it, He (they) will come" :)
I'll just echo what everyone else has said - if your app requires this functionality you would be taking a huge and unnecessary risk building it as a PWA around the origin trial instead of just building it natively around stable APIs.
A lot of web APIs are optional and offer non-functional enhancements, but I suspect that this is a feature that isn't optional to most of the apps that would leverage it, hence it's unsurprising that there's been little uptake on the origin trial - only hobbyists are likely to dabble with it right now. We know the functionality has a lot of value because of how heavily it is used in the native world.
I agree with what others are saying. If time based notifications are critical for my app I would build a native app. If they are not critical I would build PWA and simply not use them since they won't work in all browsers.
The only apps I would consider testing time based notifications in are "prototype" apps or similar where I can make sure users use a supported browser. Unfortunately I don't make any such application.
It seems to me that origin trials presume a level of available free/experimentation time and risk tolerance on the part of developers and, apparently, real-world customers that simply doesn't align for all-or-nothing features like this one. It's one thing to use origin trials for a progressive-enhancement feature like a CSS selector, better image/compression format, or something along those lines that the user can negotiate, but it's not a suitable approach for gauging interest in fundamental features.
As web-developers we depend on quite a few APIs that are not available on all platforms. Think web-push. And not all PWAs are meant for a general public. I have a number of apps that are meant only for a company or the family (or friends) so that I can make sure everybody runs them in the right environment. I actually have two or three apps that are just for me. Notifications would fit in nicely e.g. for an app I wrote for a medium sized company or for my personal shopping / scratch book app. Don't overthink this. It would be a GREAT API to use - even if it is limited to Chrome.
The Notification Trigger API is awesome! I have been using this API in my self-written PWA Calendar App for over half a year now. I use the PWA Calendar across Windows, Linux, and Android and never had any problems with it. Of cause it would be nice if on Windows and Linux Chrome / the PWA wouldn’t have to be kept open (in the background) for the notifications to be shown like it is the case on Android where it does not matter whether some instance of chrome or the PWA is running. Overall I agree with the general chicken and egg problem as described here. However, this API is super useful and its functionality is as far as I know not achievable with other existing techniques. I think apart from the cross-browser support the API just needs to get more attention.
We did some partner outreach and heard about the following use cases:
- A broadcaster: "Use these notifications so that say there are 10 days left to view a particular episode in a series a user likes, a notification could pop up."
- A media company: "[Live broadcast] reminder, local television show reminder."
- Two travel companies: "Reminder that your booking/appt/reservation is tomorrow."
- Two ticketing/streaming companies: "Opt-in notifications for when ticket pre-sales go live, reminders when a show might be leaving streaming".
- A gardening retail company: "[O]pt-in reminders for growing seasons on plants (pre or post purchase)."
We have just announced that we're no longer pursuing this API. Please see crbug/891339#c72 for details. Thanks for y'all's interest!
@tomayac are there any alternative solutions in the pipeline? Without an alternative, this signifies the death knell of PWA's future as an alternative to native applications. :confused:
Using Web Push Notifications continues to be the recommended option, which will work well in the majority of cases, especially when used with a low ttl.
I hate to contradict you Peter. But web push is in no way an alternative for Notification triggers. First: web-push requires a working network. Second: web-push is in no way guaranteed to be delivered, especially not when a device is in doze. As you may be aware, there is currently a discussion going on why PWAs do not have a notification environment like native apps. PWAs can't deliver call notification which renders something like webRTC relatively useless. We can not deliver web-push in (more or less) real time which renders PWA useless for anything that would require instant notification (such as weather alerts, stock notifications, breaking news, chats etc). With the culling of the notification triggers we can't even have something like a birthday reminder, appointment calendar or "take your pills grandpa" . Though some are pointing at technical difficulties, I am sure most of us coders suspect other reasons behind this rubber cage that has been raised around PWAs.
I am sure most of us coders suspect other reasons behind this rubber cage that has been raised around PWAs.
To speak the forbidden name as it were:
I suspect it's related to the expected loss of revenue from app developers moving away from App Stores and using web based payment systems instead. Unsurprising, but frustrating and disappointing.
Of the two mobile giants, Google was our best bet at actually getting this. If they're pulling the plug, PWA has no foreseeable future imo.
On the bright side, Quasar has basically eliminated my personal need for PWA to actually be viable. And at the same time, if the API instability was legitimately the reason for pulling the plug here and it gets resolved, then I don't have to rewrite anything to port apps from native to PWA down the road.
I think the way to move this forward is to make it just a time trigger. A trigger to wake up the service worker. Other things than a notification might have to be done too.
Use something similar to setTimeout - with the possibility to cancel the timer. (But add function arguments to the API, not just function and timeout.)
As others have pointed out, I think Google has no interest in moving this forward. With this functionality, many apps that can only be implemented as native Android apps today would be implementable as Progressive Web Apps instead, and that would hurt their Play Store. They want to hold this back. Feels like we're back with IE 6 again.