111–120 of 285 posts
Earlier quoted context omitted.
Thanks for putting it in context, the Bluetooth API has been a big source of frustration in my exploration of PWAs. So many simple setup apps wouldn't need to be native. A cross platform Bluetooth API for the web would provide really easy PoC with MCUs.
And a massive exploit capability for malware.
My estimate is there are 5,000-10,000 really poor PWA/SPA/etc for every actual good PWA/SPA. Going to a website and it loads some massive chunk of overengineered javascript when all I need to do is display one piece of text is infuriating.
Most apps do not need to be made by 10x developers who code in assembly.
Namely: if you swipe from the sides of the screen to go back/forward, you get a duplicate animation. If you swipe back from B to A, once the native (interactive) slide animation finishes, the page then jumps back to B and then does another (noninteractive) slide animation to A.
Fixing this would be as simple as disabling the page's slide animation, but whoever made this site didn't notice or didn't bother.
Apple does have some blame here. Disabling the page's slide animation wouldn't be a perfect solution since it wouldn't distinguish slide gestures from other ways to go back/forward (which ideally would still show an animation), like using the browser's back/forward buttons if accessing the site in a browser rather than as an app, or using a keyboard shortcut with an external keyboard. I don't think it's possible to easily detect which kind of gesture triggered navigation (in order to conditionally show the animation).
Another option would be to disable the native slide gesture entirely in favor of a fully JS-based one. In the past it wasn't even possible to disable it, but that has been fixed for years now [1]. However, it's hard to exactly replicate the native behavior.
Ideally there would be a more purpose-built interface to detect and customize the native swipe gesture.
[1] https://pqina.nl/blog/blocking-navigation-gestures-on-ios-13...
Earlier quoted context omitted.
Go to any webpage/PWA, hit the share button, hit “add to home screen“. That’s it. It’s not complicated or restricted in any way.
Its not intuitive for the average user. "Share" does not usually imply "Install" , and the add to home screen option for me is way down in the menu.
Adding bookmarks, finding on the page, printing, triggering extension actions/scripts… it’s a junk drawer.
It’s not hard to explain to users at least. It certainly could’ve been much worse. Not high praise but it is what it is.
Earlier quoted context omitted.
> But why do individuals push for that? Because we don't have the resources to build a native app for every OS out there.
Are you using Windows? I am happy that the people who contributed Linux/BSD/Android/iOS did not have your mentality, otherwise I would be forced to use Windows everywhere.
Web is free and people can build and release web apps they want.
Earlier quoted context omitted.
Isn't the idea of PWAs that you aren't doing it through Chrome, or not knowingly. You're just running an app, and Chrome (or Blink) is a library that the app can use?
> or not knowingly That's a big difference. What if I sold you a Linux computer that was actually running Windows with a UI that looks like Linux?
We push PWAs to iPads & Surface Go devices via Microsoft InTune for some of our clients today. This path started out very nightmarish (circa 2020) but it's going much smoother today. One of our customers actually came back to us with a slightly improved process based upon the one we gave them. They switched from iPad to Surface Go and used some extra endpoint management to make the PWA experience into a sort of kiosk…
> 2D barcode Which JS library do you use? I couldn't find a single library that can reliably scan PDF417 barcodes.
Media constraints are the #1 reason it won't scan in my experience. You need at least ~1000px horizontal to reliably decode PDF417. If the resolution is 720p or lower, you aren't capturing enough information for a decode.
We push PWAs to iPads & Surface Go devices via Microsoft InTune for some of our clients today. This path started out very nightmarish (circa 2020) but it's going much smoother today. One of our customers actually came back to us with a slightly improved process based upon the one we gave them. They switched from iPad to Surface Go and used some extra endpoint management to make the PWA experience into a sort of kiosk…
> 2D barcode Which JS library do you use? I couldn't find a single library that can reliably scan PDF417 barcodes.
Earlier quoted context omitted.
The whole point of PWAs is to provide cross platforms apps so if a feature isn't available on all/most platforms, I don't think it's fair to say that it's really usable at all in your PWA. You should be delivering the best possible experience for the user based on what their device can do, not the lowest common denominator of some arbitrary set of features. Progressive enhancement, API detection, and polyfilling are…
> Progressive enhancement, API detection, and polyfilling are all common strategies that can be used to mitigate almost all device differences. Keyword being "almost", and that in some cases if the platform doesn't support your feature, you're shit outta luck. By far the thing that prevented PWAs from bigger uptake earlier was Apple dragging their feet on push notifications support on iOS. There was simply no workaro…
Is there any evidence that this moved the PWA needle at all, he said hopefully? I would've predicted no effect on PWA adoption.
> …last I checked the "install to home screen" on iOS Safari was still a horrible user experience (the actions is hidden under the "share" menu, which makes no sense to me).
For better or worse, it's how iOS users are trained to "do something" with the current web page. Keeping in mind that "PWA" is jargon that average users won't be familiar with, what would be easier than (1) tap Share, tap (2) Add to Home Screen?