Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can we move this forward? #7

Open
LarsKemmann opened this issue Jul 29, 2020 · 23 comments
Open

How can we move this forward? #7

LarsKemmann opened this issue Jul 29, 2020 · 23 comments

Comments

@LarsKemmann
Copy link

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!

@Twaha-Rahman
Copy link

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.

@amitlzkpa
Copy link

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.

@joshbuker
Copy link

joshbuker commented Nov 8, 2020

+1

@beverloo, who can we reach out to to indicate interest and move this initiative forward?

@benji6
Copy link

benji6 commented Feb 20, 2021

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

@Guy-Sela
Copy link

@beverloo is the project still in motion? (no updates for over two years)

@beverloo
Copy link
Owner

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.

@joshbuker
Copy link

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.

@tomayac
Copy link

tomayac commented Apr 28, 2021

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.

@Guy-Sela
Copy link

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" :)

@benji6
Copy link

benji6 commented Apr 28, 2021

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.

@PeppeL-G
Copy link

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.

@LarsKemmann
Copy link
Author

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.

@secumundo
Copy link

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.

@ein-christoph
Copy link

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.

@tomayac
Copy link

tomayac commented Aug 24, 2021

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)."

@tomayac
Copy link

tomayac commented Dec 3, 2021

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!

@joshbuker
Copy link

@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. 😕

@beverloo
Copy link
Owner

beverloo commented Dec 3, 2021

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.

@secumundo
Copy link

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.

@joshbuker
Copy link

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.

@lborgman
Copy link

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.)

@secumundo
Copy link

Looking around ...

@PeppeL-G
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests