[Webkit-unassigned] [Bug 198673] Need to way to feature-detect for "Add to home screen" instructions

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=198673

--- Comment #13 from Maximiliano Firtman <firtman at gmail.com> ---
(In reply to Marcos Caceres from comment #12)
> (In reply to Thomas Steiner from comment #11)
> > 
> > If we aren't happy with the way `BeforeInstallPrompt` fulfills (1), then
> > maybe let's discuss alternatives. In a toot
> > https://toot.cafe/@tomayac/110231078898885161,
> 
> The right place to discuss alternatives is either at the w3c, as part of
> manifest, or in the WICG’s manifest incubations repo. Happy to pick this up
> there. 
> 
> > I hinted at
> > `navigator.install()` or whatever. I think the use case (providing a
> > programmatic way to let users install your app) is valid. Does Safari agree
> > on the use case?
> 
> I can only speak for my self (and again, this is WebKit’s bug tracker, not
> Safari), but I don’t agree with the use case because the UI provided is (or
> could conceivably be made) sufficient so to obliterate the need for BIP or
> any .install() method. Same as we don’t have a .bookmark() method, because
> users know how to bookmark sites without sites needing custom bookmark
> banners + instructions. 
> 
> However, if you’d like a WebKit standards position on BIP, I kindly ask you
> file one: https://github.com/WebKit/standards-positions/issues.

It's been a while since my comment in this thread. So here is my position on this matter today. 

TL;DR: The bookmark sample doesn't count as a comparison because you always get the same result when you bookmark a URL. When you add a site to the home screen on iOS and iPadOS, you get a different result on different occasions; there is no reliability in the final experience.


I don't want to comment on specs or standards; it's not my expertise; you know better than me where to discuss and how. I know this is also a WebKit forum, not a Safari discussion. However, when deciding what to implement or not, I understand use cases and UX issues for users should be a priority. 

Today's situation is a UX issue for users, not if one API is good or bad. I'm unhappy with BIP, but it's better than nothing when the browser doesn't assist the user. 

You may say the API is unnecessary, and you may be correct. Still, we are all asking for it because Safari needs to be helping with the user experience on iOS and iPadOS specifically and it's not doing it. A Safari UX change will reduce developers asking for an API whenever possible. And you are right; that's Safari, not WebKit. 

A user will never know what will happen after using "Add to Homescreen." Sometimes it's an icon opening Safari with a URL; sometimes, it's a standalone app. That standalone app has an entirely different behavior, such as using isolated storage. It also now enables more abilities, such as Web Push and Badging, two APIs WebKit implemented when Safari decided to have them on iOS and iPadOS. 

Therefore, Safari on iOS and iPadOS is implementing Web Push but with a great catch when the users will never know when a URL can provide that enhanced experience. It is an obscure antipattern for users. 

Because of it, Safari is pushing web developers to tell the users that adding this URL to the home screen will give them that enhanced experience. And I can tell as a user that it's still an unreliable experience. I've found myself adding web apps to the home screen where for some reason, the manifest wasn't parsed correctly or in time, and then I've got a shortcut web icon to Safari or a standalone icon with the wrong icon. As a user, you don't know that before opening the icon for the first time. A Safari badge, menu change, or an API delivered from WebKit if Safari doesn't want to do it can help to increase the opportunity to have the expected user experience. "This webapp is ready for ATH".

Having a way to tell if the current web app is going to install a Safari shortcut or a standalone app is essential for the author if Safari is not doing that. Even with other browsers not implementing BIP, Safari is the only browser not showing a hint, an icon, a flag, or a simple label change in the menu when the current URL is "added" as a standalone app.

It's important to understand the complete picture, the context, use cases and UX issues. Devs asking for this is not just based on a whim. You are not Safari, but you are pretty close to them :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230420/00432f5a/attachment.htm>