I can understand PWA wants to be more than just a web page and have their own UX. I have more experience in Backend software development and right now leading a small web/mobile/devops team, and always stress to not override browser controls unless absolutely necessary. Somewhat similar thing happens with scrolling. I feel most of the JS overridden scrolling is not needed.
- links are for navigation
- buttons are for action
Simple rule is "should this view have a url". Should the user be able to navigate directly to this page? Should it exist in the history? Should the user be able to share a URL to that page to someone else? Most times the answer to all of these is.
In your javascript application, it is trivial to do single page app view navigations (without triggering a full browser request) by listening to link clicks and acting on it just as you would if it were a button click. All frameworks and routing libraries will handle this for you out of the box. If you roll your own, its not that difficult to add this functionality.
General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.
I think this happens a lot nowadays because we create and style div elements from scratch while also hooking onto more fundamental events and preventing any browser behavior.
I will also sneak in a pass when I finish something that unexpectedly takes less points to finish.
In pwa we have w & a
For the app part, ux generally does not allow you to right click or pinch & zoom.
For the web part, it does.
The best compromise is media queries and have some ux for mobile and another for desktop.
From a business point of view, im not sure final user will value that investment
On iOS you even get a preview window with the links' content when using Safari.
But I assume few people do this, so your last point applies.
Oops. You can't nest table row <tr>s within anchors <a>, so you have a few options:
1. Each column has a link, and the link extends to the width of the containing cell.
Pros: It's easy to implement. It doesn't break browser behaviors.
Cons: There's unintended holes in the click targets. It's ugly as sin in code. It is quite confusing for screen reader users. It may be hard to get this right if your cells contain more layout than pure text. All in all, it's not an elegant solution.
2. Instead of making it a link, override the behavior of clicking on a row by registering a click event handler.
Pros: It does what you want. It's easy to generalize. It's a little bit of a kludge but certainly less hacky than 1.
Cons: It requires extra work to make it work well with screen readers. It requires extra work to make it work well with ctrl clicking and other behaviors - in fact, many webapps that apply this approach actually emulate the browser behavior, which, imo, is horrifying. Right clicking no longer gives contextual options for links, since there is no real link.
3. Restructure the DOM to not use a <table>. Perhaps use `display: table` with plain divs.
Pros: Now you can use a proper anchor tag link. It's also fairly easy to generalize. It shouldn't require too much work to get working well with screen readers.
Cons: Although it's less of a kludge in the end, it has one annoying flaw: just to get this behavior, you have to completely restructure your document. Which leaves you with choices: Should all tables be structured using other HTML elements instead of <table>?
Ultimately, some applications end up with trouble where anchor links are pretty hard for one reason or another. I don't think PWA or JS developers generally strive to break things or needlessly reimplement them; everything from client-side routing to custom link event handling has a reason to exist, and usually the intent is to make things work as well as possible.
That having been said, I've noticed a great deal of issues even with mature frameworks. For example, if you go to a really heavy PWA that has proper anchor links for fallback, try ctrl+clicking the anchor links and see what happens. You might find that it navigates in the current tab and spawns a new window!
(Note: I'm not suggesting this example is perfect; you could probably argue about whether the tabulated data should ever have clickable rows, or something like that. Still, it is a real thing that I've come across a few times now, and there's some pretty similar siblings to this problem.)
edit: Oh, and on a historical note... some of you who also were early adopters on XHTML will remember that in XHTML, you could actually put an href attribute on more elements, allowing you to get the behavior on list items, spans, etc. Sadly, it was never widely implemented.
When we're presenting data, one of our columns is nearly always a 'primary identifier' of some kind - a name, an id, etc. We make this column a hyper-link and then we also add a click handler to the row. This means it's still fully accessible to screen readers and tab navigators, but users who expect a more 'app'y experience are happy too.
The click handler has to be a little smart to ensure it's not receiving the mouse-up of a selection event, but it's not bad.
I starting making exactly this back in 2018 but didn't get people interested back then so I dropped it and let the domain expire, see the original (seems broken though):
https://web.archive.org/web/20180901171627/http://web-app.st...
It was my first time using a skeleton in CSS and using a Google Form as the way to submit a new app (with the spreadsheet as the database). I believe it was also my first PWA but I'm not 100% sure about that. While I learned a lot, some times I regret not having followed through, will keep an eye on https://progressiveapp.store/ to see how it goes.
Appreciate it!
Think about a random nontechnical Facebook user - How would they get their feet wet? Likely by opening the pwa of Facebook, realizing it’s pretty solid, and trying new ones after that. (I’m not saying Facebook is a good example, just the audience you might think about).
I’d definitely be into helping out with marketing strategy, lmk if you need advice or an extra hand.
Right, because the core technology PWA is based on, the web, hasn't been tainted with ads.
Many sites people have put on the web based on their business decisions are, sure.
But that doesn't mean the core technology has been fundamentally tainted, any business not operating on a model of generating revenue from passive views generally doesn't display ads on their sites/in their products.
* https://www.superhighway98.com/seo * http://jacek.zlydach.pl/blog/2019-07-31-ads-as-cancer.html
* https://www.youtube.com/watch?v=DnPmg0R1M04 * https://voxeu.org/article/advertising-major-source-human-dis... * https://www.forbrukerradet.no/side/new-study-the-advertising... * https://danielmiessler.com/blog/google-amp-not-good-thing/
* https://www.theregister.co.uk/2017/05/19/open_source_insider...
The worlds largest advertising company is well known for abusing its position to push technological features and standards that benefit it-even if nobody else does-suppress and hinder competitors and aggressively and continuously trying to erode the open web. Next up, Facebook is notorious for similarly attempting to subvert and erode the open web, whilst simultaneously invading your privacy and using you as psychological lab-rats.
Search is quite useless. It seems to only display list of matching names. So I can't even search for "game". It does not filter.
I think the UX is supposed to encourage experimentation, but I always find it daunting whenever I try to find an app for something. There is this bunch of huge icons, not enteirly clear names or just straight up deceiving ones and a rating. To get to even a slight neutral description what the thing is one has to tap in, many times also dive deep in description just to have an idea what the thing is trying to be. I guess with web platform it may be easier than normal apps, also I feel I must trust an app much more to install it, but this gives me the same vibes. A channel of spewed icons and mostly unhelpful names.
Sorry if it sounds harsh, I just can't stand how useless Play Store is at finding things.
Also, you've made a very common mistake of setting `outline: none` to your focus states! Very bad for people who navigate using a keyboard.
Good job on launching, by the way.
Appreciate it!!
Also, it's dead-easy to customise - there are a bunch of facilities for doing so, from global to component level, with CSS-in-JS or CSS class overrides. You can make it unrecognizable without that much work.
A lot of people don't consider the economics of UI animation.
Smooth animation only makes sense in powerful devices. For the past 10 years we've seen an increase in UI animations which required users to buy newer and more powerful devices to achieve smoother and more complex animations.
Look at any phone/tablet review and you will see the reviewer try to open the app drawer or something similar to showcase performance. "Look how fluid it moves!"
Perfectly fine devices are constantly being replaced and thrown away because they can't keep up with more and more demanding UI animations.
Another aspect is energy consumption, battery production, etc, which I don't think is negligible when considering billions of devices being used for hours every day.
And the sad truth is, very often UI animation is overused.
Ever tried to get users in emerging markets on old Android devices to discover, download and update your native app? It's a world of pain.
The topics of judgement you mentioned are all entirely subjective, but they run near identically for me.
Does it browse twitter? Yes. Is it good? Well, maybe if all you ever uses are PWAs, this is considered "good."
https://github.com/cdr/code-server
This is amazing. I mean it isn't a stretch considering the main VSCode app is Electron based, but having a hosted development environment like this has always been a dream...
I turn off all the OS-level animations using my phone's accessibility settings. It is a much better usability experience and "feels" far more performant - I perceive less time spent waiting, anyway.
I wish I could do it in apps too, so that I the time it takes to complete an action wasn't bounded by the duration of the "beautiful animation" someone felt it was helpful to include.
* I don't make a distinction between 'manifest files and offline support' ('PWAs') and other web apps. I suspect most people don't either.
(we're a daily prediction platform with cash prizes - think of us like a hybrid between HQ trivia, a sportsbook, and Jeopardy)
Just gonna leave us hangin'?
I mean, PWAs by definition run inside a VM that has to provide a very heavy runtime, don't they?
This isn't a (comparatively) minimal like the JVM -- this is usually a Chromium instance, with the full V8 engine, Canvas and DOM support, and sandboxing.
It's not reasonable to say that something with this much baggage should be able to run as quickly as a native application, which can often afford to have a much more minimal sandbox, no bytecode layer, a smaller memory footprint, and more deliberate and performant integration with underlying system APIs.
But yes there are classes of applications for which underlying implementation technology does not matter much while browser based access from anywhere is more important.
> FREE to install
> HTTPS is required meaning you data is secure
> Takes up less storage on your phone. No need to pay extra money for higher storage
> No in app purchases or ads. Just a clean and simple app experience
> Has an offline mode. Apps can be used in areas where this is no internet connection
All of them are either misleading or completely wrong. The comparison randomly switches from websites to phone apps whenever convenient.
It would be a lot better to provide a more objective description of what PWAs even are.
I have been lately working with lot of clients who want PWA's and I have found https://appsco.pe/ to be one of the nicest PWA gallery.
- Better isolation from my device. I don't worry about them sucking up information I don't want them to have. - I can share links to my friends (if the website has good URLs of course) - I can use it on every device. I don't need to worry if it has an Android App and website, I can just use the website on both. - I can use the same app as my friends no matter what phone they use.
It's trivial to implement but many devs don't pay attention to those things.
It is also partially the web's fault. There isn't an easy way to detect an "in-page" navigation. The best solution I am aware of is:
1. Add global "click" listener. 2. Check that the click target was an `a` tag. 3. Check that the click was a single left click with no modifiers. 4. Check that the `href` points to a page that you can render. 5. Call event.preventDefault() and handle the navigation yourself.
But step 3 isn't even sufficient as people can configure their browsers to open all links in new windows or tabs.
There is a "gallery" - a store of games. But most importantly, manifests are available as a JSON feed, which anybody can use. It is at http://www.spreadmygame.com/
This seems to be exclusively optimized on mobile devices, and is not even properly responsive. A progressive web app should be usable both as an app and in a browser. This is not the case here.
Does iOS support offline use of PWAs? (Or perhaps this is an issue with my phone... anyone able to reproduce, or find an App that does work offline?)
Steps: Open App, enable airplane mode, go to iPhone home screen, open the App again, App is unresponsive.
Apps I tried: https://progressiveapp.store/pwa/219 and https://progressiveapp.store/pwa/87
EDIT: Might be a bug: https://github.com/facebook/create-react-app/issues/8889
Orchestration of the resources (CPU, memory, storage) to run API services would also be possible in a distribution manner if we can envision something like Kubernetes to manage workload allocation across compute hardware (smartphones?) and if there's a way for participating nodes to obtain container images and storage volumes (IPFS / Tahoe-LAFS?).
Signing and trust would still be an issue, particularly for container images and storage volumes.
[1] - https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-...
I have multiple progressive web application that I’m currently working on and I’m struggling a bit with that point.
Other than that like another user mentioned there's any monetization methods on the web at your disposal (advertising, microtransactions, donations etc) it really comes down to what business model you want to operate on and what seems most natural for users of your product.
As far as a "buy it, you own the copy" model like with traditional media software and games go I don't think there is anything universal to use, most developers would implement their own licensing in their billing/accounts layer and expose a serial key or something that local data gets encrypted with as a rudimentary DRM, so the app can only be used later by having the right serial key (whether from LocalStorage/cache/a fresh login) for that paid user to decrypt and use their local data.
It would be interesting if some service like PWA Store were to offer some kind of universal DRM to developers wanting to sell offline PWAs on a one-off sale format that they can easily wrap their app bundle in
There's one big problem though, if the freemium model doesn't work...
I assume this isn't what it should look like.
Sorry about the bug report here, I couldn't find any contact link.
I don't actually know if it's possible using standard APIs that work on iPhone and Android
At least the demo worked.
You can probably implement facial recognition yourself as well.
[1] https://livebook.manning.com/book/progressive-web-apps/chapt...
The hn app is fast and slick, for example, but it doesn’t have comment collapse which is a major omission.
Pretty neat!
IOS it is still not supported yet but should be soon
Also they actively disabled service workers, the very tech that enables PWAs in the first place
IMO, the entire world has regressed into chaos when it comes to design and UI. Democratic design choices and process is far inferior to dictatorial approach we had going in 90's and into 2000's (See 98.css recently posted: https://news.ycombinator.com/item?id=22940564). Let everyone run loose and we all lose.
Yes, it was painful to develop applications using native UI elements but those apps provide a fantastic, consistent UI experience.
In addition, the entire Javascript ecosystem is rotten with horrible bloat built atop more bloat by many inexperienced software engineers - sorry, I don't meant to insult anyone but this is a factual observation from my own experience of developing on React and Angular. When a website that's serving trivial content is hogging so much CPU, it is time to refactor everything. It is actually time to refactor what we see as a modern browser.
That you can't easily hack on (as in "customization"; userscripts and the like), aren't based on standards and have no sort of isolation or permission management.
Both ways have their up- and downsides but I think the web is an upgrade. It's not the best possible solution and "native" could be where the web is today but we have it and it's okay.
Also, I think the democratization of programming (whether it be UI frameworks or application development or whatever) is probably the best thing to happen to IT. I think we (as in, society) should make it possible for everyone to do whatever they want and a standards-driven (mostly) easy to understand programming model is a good way of providing that possibility for IT.
I actually think it’s getting easier. Android and iOS are both offering quick, modern ways of building UIs with there upcoming UI frameworks thats IMO far less work than the web where things have to often be built from scratch or from some third party that will abandon it.
With the advent of web application we ignored it for a while (it is just a window with some strange stuff in it). However, with the mobile platforms (Android, iOS), bootstrap framework and the rise of strict user interface guideline by mega companies (like Google Material Design), the number of UX styles literally exploded. I try to enumerate them, but the web is full of variants.
As a dream, we should consolidate to device factors: Desktop, Mobile, Watch and Interactive. But Apple, Microsoft and Google are not on the same page here ;) If they would, magic could happen.
This is a common problem but it's certainly not the entire ecosystem.
Check Preact, Svelte, Mithril, Inferno, etc. Those are very lightweight alternatives to React, Angular, etc.
Also with SRR + hydration or SPA with code splitting you can achieve very lightweight apps.
I'm working on a Svelte SSR + hydration app right now and on each page I load about 5kB of JavaScript, some as low as 2kB. See this repo for an example on how to set this up with Rollup and a Node server: https://github.com/PierBover/svelte-ssr-example