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

Finish service worker caching #129

Closed
iandunn opened this issue Jun 21, 2019 · 8 comments
Closed

Finish service worker caching #129

iandunn opened this issue Jun 21, 2019 · 8 comments
Labels
[Component] PWA Service workers, manifest

Comments

@iandunn
Copy link
Member

iandunn commented Jun 21, 2019

See the @todo notes in mu/-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.

@vdwijngaert
Copy link
Member

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!

@westonruter
Copy link
Member

Yes, see also wceu/wordcamp-pwa-page#6 (comment):

The way to do this would be to send an ETag in the REST API response, and then when making the request include the value in an If-None-Match request header. The REST API controller should then compare the value in the If-None-Match request header with the the ETag that would be sent, and if they are the same, send a 304 Not Modified response. This would prevent wasting client data pulling down the same data that has not changed.

A good ETag could be the max post_modified date of whatever is being queried.

@ryelle
Copy link
Contributor

ryelle commented Aug 6, 2019

Responding to some of the comments from that file so I can get a better handle on the tasks:

prompt to install app to home screen is automatically showing on mobile

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.

also, says "install wordcamp" instead of "install wordcamp europe" - maybe manifest issue?

Created an issue for this: #196

after adding to home screen, there's a delay and a "wordcamp" interstitial screen before the site appears.

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 theme-color (no theme supports) and then the custom-background theme setting (which only CampSite & Twenty Ten support) - so we might want to add in a customizer setting on Site Identity to control that. Created an issue for this: #197

experience on mid-level phone (moto e4) and fast bandwidth is pretty poor

Created issue: #198

what's the point of adding to home screen?

I mean, personally I use it as a bookmark. I don't think there's anything in this comment to address.

maybe avoid loading images on slow connections

I agree that this is better suited to the core PWA plugin than us working on it.

having multiple tabs open, when 1 has a youtube embed playing, then refresh other tab, the video in first tab stops playing

I can't replicate this just from this description, but I'll keep an eye out.

open issue w/ pwa lpugin - this may be plugin territory, but save offline button to add to precache route?
similar to that one site
or does it do that automatically already?

@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)"

@iandunn
Copy link
Member Author

iandunn commented Aug 7, 2019

I think it's fine– it's just like a "bookmark" to the site

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.

personally I use it as a bookmark. I don't think there's anything in this comment to address.

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):

A lot of it's about exercising care with the stuff that a user is allowing you to do on their computer, and being aware that this is a person you're dealing with, which I don't think we do enough of.

There are so many sites that I go to that, the first time I go to the site, they're immediately like, "Hey! Give me your location! Hey! Can I send you push notifications?!? Hey! Can I do..." and I'm like, "No! No. You get none of that!"

So I think we need to seem a little less needy, and give people context for when things are important, and how we intend to use them, and give users control over how we use them.

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.

Can you explain more about what this means

Yeah, I should have left better notes :)

IIRC, that was a reference to
https://chrisruppel.com/blog/service-worker-offline-content/. That article talks about the general idea, and that site itself has a "save article offline" button on every blog post. Some of the most important pages are pre-cached, but that button allows users to opt-in to additional offline caching of content they're specifically interested in.

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.

@ryelle
Copy link
Contributor

ryelle commented Aug 7, 2019

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?

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).

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,

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).

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 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.

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.

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.

Then we can think about adding a contextually-appropriate "Save Offline" button, or some other non-intrusive way for users to opt-in.

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.

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.

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.

@westonruter
Copy link
Member

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.

Yes, this can be controlled now, by calling preventDefault() on the beforeinstallprompt event.

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.

IIRC, that was a reference to
https://chrisruppel.com/blog/service-worker-offline-content/. That article talks about the general idea, and that site itself has a "save article offline" button on every blog post. Some of the most important pages are pre-cached, but that button allows users to opt-in to additional offline caching of content they're specifically interested in.

Followed up in a comment on the opened issue: #201 (comment)

@iandunn
Copy link
Member Author

iandunn commented Aug 13, 2019

[it] adds it as an app to the home screen. I don't use browser bookmarks on a mobile browser

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.

Is it more intrusive for you? it's just a small little banner at the bottom of the page for me.

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'd actually say that it should be date-based- during the conference & the few days prior.

I think that's an even better idea 👍

this mini-infobar should actually be going away in favor of an install button that appears in the omnibox (URL bar)

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.

@ryelle
Copy link
Contributor

ryelle commented Jan 14, 2020

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.

@ryelle ryelle closed this as completed Jan 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Component] PWA Service workers, manifest
Projects
None yet
Development

No branches or pull requests

4 participants