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

PWA A2HS is inconsistent between browsers and the experience is awful #7

Open
IvoPereira opened this issue May 19, 2020 · 1 comment

Comments

@IvoPereira
Copy link

IvoPereira commented May 19, 2020

At first, let me tell you that this is a possible enhancement discussion for the library, and not a problem with it - at all!

Overview of the problem

To provide some context on this issue before pointing out what I would like to see (and contribute to of course):

Nowadays every browser seems to tackle the A2HS issue on their own way.

  1. Apple being Apple and totally disregarding PWAs is the main bottleneck. Service Workers have just been recently implemented in Service Workers (iOS Safari). From the looks of a discussion I've read on it doesn't look they will be implementing it anything soon.
  2. Firefox is not clear about their intentions and are postponing the decision to an unknown future until PWAs have a clearer future view. They are testing out possible callouts/popups in Beta/Dev versions.
  3. Chrome, Edge and Samsung Browser do have this functionality fully working. Why them 3? Because all are based on Chromium.

The reluctance of these browsers who haven't yet implemented any kind of attention grabber for the existence of an installable PWA is due the mess they realized that was made when developers could start asking for permission to send Notifications without any precondition at all.

That quickly led to an "usual" awful UX in a huge amount of existing websites that were constantly spamming you in each visit asking you to enable Notifications. A plague just like the cookies policy bar that has invaded the web the past year.

Fast-forwarding to today, Chrome does implement beforeinstallprompt but seems to be the only one interested in implementing it. Therefore, one more time, it causes some inconsistency for us the developers and for our users.

At the current state, we have no way to provide an uniform way of delivering a PWA install to our website visitors and we want to make that experience painless.

I think we may agree that everyone who develops a PWA should be able to efficiently provide an installation method for every user without fighting each and every browser, being able to deliver the most consistent installation experience possible.

What can we do?

In my opinion, we could try to make a customizable bottom bar (similar what the library currently does) but supporting Firefox and iOS cases, offering custom instructions to the user on how to proceed.

The view I had for this was something similar to the following:
image
(source: https://web.dev/customize-install/)

This, with the addition of the PWA App Icon would promote the installation of a PWA, allowing the developer to present a good benefit for the installation and an actionable "Install" button that would have an higher CTR than the current bar.

Clicking "Install" would differ based on the browser.

Chrome: As we are able to catch the Chrome's own incentive callout, we can save the triggered event and trigger the Add to Home Screen ourselves once we press the Install button. All good.

Firefox and iOS: As there is some uncertainty in these browsers, what I would suggest is that once the "Install" button is clicked, a popup would appear with different instructions according to each browser, possibly with accompanying images (customizable by the developer) to guide the user on how to install the PWA in their browser. If we wanted, we could as well abstract this and just call a callback function and each developer would implement it in the way they want to, however that would leave the burden to the developer to identify the disparities between every browser and eventually changing every guide according to them.

I am aware that the purpose of the library is to mainly help adding a PWA - at this time only on iOS -, but in my view, we could all benefit so much from this and do the job no one seems to care enough in browser development.

Let me know your thoughts!

@gedw99
Copy link

gedw99 commented Jan 13, 2022

hey @IvoPereira

Thats a very thorough rundown of the problem space, how we got to the current status quo mess and a solution.

there is a golang project that does some of this here: https://github.com/maxence-charriere/go-app/blob/master/pkg/app/gen/manifest.webmanifest

As you mention there are lots of edge cases for each OS and Device and Browser.

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

2 participants