-
Notifications
You must be signed in to change notification settings - Fork 79
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
Finish service worker caching #129
Comments
This should be pretty straight forward using the stale while revalidate strategy. If the right http headers are used (and exposes for cors use), this should reduce server load and client side traffic quite a bit! |
Yes, see also wceu/wordcamp-pwa-page#6 (comment):
|
Responding to some of the comments from that file so I can get a better handle on the tasks:
According to the criteria for showing the install badge, this is because we've added a manifest. I think it's fine– it's just like a "bookmark" to the site while you're online, and of course if you're offline we want the UX to be better but we're improving that now.
Created an issue for this: #196
That's the splash screen that loads while the browser is booting. We can customize the icon, name, and background color. The background color comes from theme settings, a setting called
Created issue: #198
I mean, personally I use it as a bookmark. I don't think there's anything in this comment to address.
I agree that this is better suited to the core PWA plugin than us working on it.
I can't replicate this just from this description, but I'll keep an eye out.
@iandunn Can you explain more about what this means? is it related to "maybe button to download all pages (not all posts or other cotent types, just pages, so that whole site heirarchy is accessible offline)" |
My concern is that it feels very intrusive, and is probably not wanted by most users in most cases, in the same way that pop-up ads, newsletter subscription modals, etc aren't. I'd prefer to disable it until we're able to provide a solid set of PWA enhancements that will make it worth the user's time/energy/attention. Even then, I'd prefer to do it in a way that feels more respectful, like having a "Save Offline" button in the normal flow of the Schedule page, so that they can choose to click it if they want, but it's not pushed on them, and doesn't distract them from whatever goal they had in mind when they visited the site. I'm not sure how much control we have over the how that all works, though, or if it's all dictated by the browser.
I feel like I'm missing something; there must be more benefit to you than just being a bookmark, since browsers already have a bookmarking feature? It doesn't seem like any additional content is saved offline just because the site was added to the home screen, and it doesn't seem like there's any guarantee that caching will be preserved when sites are added to the home screen. So I'm not sure what a user gets from adding it that they wouldn't get just from visiting the site normally. I feel like there needs to be a compelling benefit if we're going to push it on to users via the "add to home screen" layover, and that benefit needs to be clearly communicated to them before we ask them to install it. Personally, I'd hate it if every time I visit a website I get bombarded with "add to home screen" layovers, in addition to cookie modals and all the other awful junk that pervades most sites. That reminds me of a quote from Aaron Gustafson (timestamp 29:16):
I think I've heard of sites that don't ask the visitor to install anything until they've visited a second time, or spent a certain amount of time on the site, etc. I think something like that would be worth exploring, but probably in the future. Maybe we could prompt them to install it after they've bought a ticket, since at that point it's relevant to have the schedule available offline. For now, it think it makes sense to just disable the overlay, since users can still add it to their home screen from the browser menu. Then we can think about adding a contextually-appropriate "Save Offline" button, or some other non-intrusive way for users to opt-in. I'm open to pushback, but those are my thoughts.
Yeah, I should have left better notes :) IIRC, that was a reference to That's probably something for the PWA plugin to consider first, but if they don't want to do it, or we want to do it before they can, it might be something for us to explore. I'd definitely want the idea to be logged somewhere before we delete that comment, though. |
I mean, it does what it says it does - adds it as an app to the home screen. I don't use browser bookmarks on a mobile browser (TBH i don't really use bookmarks, period). For WCEU, I added it to my home screen during the conference so I had the site easily accessible, and removed it after the conf was over. It was obviously just a browser to the website, but that was exactly what I wanted (since there was conf wifi).
Is it more intrusive for you? it's just a small little banner at the bottom of the page for me. According to Google, if you ignore it, it will go away for 3 months. It also shouldn't be shown on re-visits, which seems to be accurate for me today (I no longer see the banner, though I did a few times yesterday).
But the PWA isn't necessarily "Save Offline", and by visiting the schedule you've actually already saved it offline, regardless of adding to home screen/"installing" the app.
If we're going to conditionally enable it, I'd actually say that it should be date-based- during the conference & the few days prior. I'll visit a WordCamp site occasionally before the camp, but I only need that quick access during the conf itself.
We should probably get some designer input on this, especially if we want to create a custom flow. The patterns for promoting PWA installation can be helpful there.
It's definitely an interesting idea, but just by navigating to the page it's cached (at least, it's meant to be - it was in FF, but I was having trouble testing this in Chrome). in any case, opened #201 for this. |
Yes, this can be controlled now, by calling Nevertheless, this mini-infobar should actually be going away in favor of an install button that appears in the omnibox (URL bar). So this should actually be irrelevant in the future.
Followed up in a comment on the opened issue: #201 (comment) |
That's a good point, now that you mention that, I realize that I've done that myself at times. I still don't feel like that's a compelling enough reason to justify an intrusive overlay, though.
That feels very intrusive to me, just as bad as a pop-up ad, a newsletter subscription modal, etc. It's all BS that distracts me from the reason I visited the site in order to badger me to do something the site owners want me to do, rather than letting me decide for myself what I want to do. I can see some people just ignoring that, but for me personally, it really bothers me, and collectively it has a profoundly negative impact on my UX.
I think that's an even better idea 👍
That seems like a big UX improvement to me 🎉 I think we'd probably still want to manually disable it, though, so that it doesn't hurt UX in the meantime, and continue to on older browsers. |
After all this convo, I think the only thing that wasn't split into a separate issue was the "distracting install banner" issue, which was just fixed with #315. I'm going to close this issue— if there's anything else, we can open new issues. |
See the
@todo
notes inmu/-plugins/service-worker-caching.php
and this:This can be used as a tracking issue, but we'll probably want lots of small PRs, and maybe a few smaller issues as well. One giant PR would be difficult to review.
The text was updated successfully, but these errors were encountered: