Implemented Ensure compliance as a Progressive Web App

Mouth

Well-known member
Ref: https://developers.google.com/web/progressive-web-apps/

Progressive Web Apps

A new way to deliver amazing user experiences on the web.

PWA CHECKLIST

Progressive Web Apps are user experiences that have the reach of the web, and are:
  • Reliable - Load instantly and never show the downasaur, even in uncertain network conditions.
  • Fast - Respond quickly to user interactions with silky smooth animations and no janky scrolling.
  • Engaging - Feel like a natural app on the device, with an immersive user experience.
This new level of quality allows Progressive Web Apps to earn a place on the user's home screen.
 
Upvote 40
This suggestion has been implemented. Votes are no longer accepted.
  • PWA is faster load times
  • Does not affect how XF does push notifications and that the existing constraints still exist (referring to iOS)
  • User is not going to use icons when that can get the same experience (PWA) in the web browser (PWA works from both the full screen icon and just using the browser)
  • Knock on native apps about back out of the browser (basically calling this is an advantage for PWA because users can quickly access the site from their normal browser)
In fact the only negative argument I made is it doesn't fix the push issue with iOS.
 
I wouldn't focus so much on the PWA icon. The prompt for 'add to home screen' which can add the icon can be configured in your service worker to either prompt or not and even if you do choose to prompt, some web browsers like Chrome will only prompt after certain amount of repeat visitor activity on your site and if your site is too slow to respond, Chrome will choose not to prompt anyway.

What PWA Is For Xenforo Owners?

The simple gist of it for everyone reading this thread/post is PWA allows better page load speed/experience in either regular web browsers (that support service workers) as well as in native installable apps (icon) via either 'add to home screen prompt' or manually in certain browsers. This is especially true for mobile slow/poor connection speeds and visitors that are geographically farther away from your site/server's location. For those technically minded, that is improved metrics for first contentful paint, first meaningful paint, dom content loaded times, speedindex/visual above the fold render time, time to interactive and to some extent, time to first byte (ttfb).
 
I wouldn't focus so much on the PWA icon. The prompt for 'add to home screen' which can add the icon can be configured in your service worker to either prompt or not and even if you do choose to prompt, some web browsers like Chrome will only prompt after certain amount of repeat visitor activity on your site and if your site is too slow to respond, Chrome will choose not to prompt anyway.

What PWA Is For Xenforo Owners?

The simple gist of it for everyone reading this thread/post is PWA allows better page load speed/experience in either regular web browsers (that support service workers) as well as in native installable apps (icon) via either 'add to home screen prompt' or manually in certain browsers. This is especially true for mobile slow/poor connection speeds and visitors that are geographically farther away from your site/server's location. For those technically minded, that is improved metrics for first contentful paint, first meaningful paint, speedindex/visual above the fold render time, time to interactive and to some extent, time to first byte (ttfb).

Good post!

What are your thoughts on the LOE it would take for XF to add this and are there any obstacles (server requirements, etc) for a typical XF forum owner to get this working?
 
What are your thoughts on the LOE it would take for XF to add this and are there any obstacles (server requirements, etc) for a typical XF forum owner to get this working?
PWA is mainly the service worker which is javascript based so experience with javascript. For server side only requirement is HTTPS and SSL certificate and if you do want the 'add to home screen prompt', a fast enough and optimally configured server to respond to requests in time otherwise Chrome won't prompt if too slow to respond i.e. if you load your site up with javascript/ads to the point that your time to interactive speed suffers and your response time is slow, then that prompt may not happen.

FYI, if you want Xenforo to response faster, wait for next 1.5/2.0/2.1 releases with full PHP 7.3 support - PHP 7.3 is much faster than previous versions from my benchmarks https://community.centminmod.com/threads/16090/:) and can be potentially even faster https://xenforo.com/community/threa...foro-php-performance-via-pgo-training.156939/ :D
 
Last edited:
PWA is mainly the service worker which is javascript based so experience with javascript. For server side only requirement is HTTPS and SSL certificate and if you do want the 'add to home screen prompt', a fast enough server to respond to requests in time otherwise Chrome won't prompt if too slow to respond i.e. if you load your site up with javascript/ads to the point that your time to interactive speed suffers and your response time is slow, then that prompt may not happen.

When you added PWA to your site, how did you handle the editor for users that are offline? Is this something you hide via the service-worker? Essentially if offline then don't load the editor?
 
When you added PWA to your site, how did you handle the editor for users that are offline? Is this something you hide via the service-worker? Essentially if offline then don't load the editor?
My PWA implementation is rough, right now offline just serves cached content and then background syncs data that was made when offline, so once online again, a background sync is made. Well in theory - haven't really tested it much. My focus is just on page load speed and improving page load performance. Pretty much all I am obsessed with :D
 
@eva2000 can we try out your PWA on your site somewhere?

@AndrewSimm these are the benefits that I can see:
  1. WPA can be used to create an Hybrid App: WPA can be wrapped into an App combined with native PUSH and ALL native App functions you want and then installable from Google Play or Apple Store. Even for XF sites with 3rd party addons.
  2. Easier to use on mobile than responsive.
  3. Extremely Fast
  4. SEO benefit
  5. Bandwidth saving
  6. Your members can be prompted to add a button to their home screen
  7. Mobile share is possible on chrome. (which is one of the most important features IMHO) This should allow your members to share their documents, images, videos to your forum, media gallery or addons.
 
can we try out your PWA on your site somewhere?
My forums are PWA enabled by default https://community.centminmod.com/ just visiting and using the forums via normal web browser is via PWA service worker :).

Registered forum members can also opt to disable PWA via user preference option by checking box shown below. Unchecking the box, will re-enable PWA.

190279

Install native app manually via Chrome menu, you will see Install Centmin Mod Community Forums link. On Windows 10, that will install native icon app link on your desktop and via Android will be on home screen.

190280
 
Last edited:
@eva2000 can we try out your PWA on your site somewhere?

@AndrewSimm these are the benefits that I can see:
  1. WPA can be used to create an Hybrid App: WPA can be wrapped into an App combined with native PUSH and ALL native App functions you want and then installable from Google Play or Apple Store. Even for XF sites with 3rd party addons.
  2. Easier to use on mobile than responsive.
  3. Extremely Fast
  4. SEO benefit
  5. Bandwidth saving
  6. Your members can be prompted to add a button to their home screen
  7. Mobile share is possible on chrome. (which is one of the most important features IMHO) This should allow your members to share their documents, images, videos to your forum, media gallery or addons.

Are you sure on the first one? I know you can embed web pages into apps but not sure how the service worker would work embedded inside an app. It sounds like you are suggesting that XF could create an app to handle native push and embed the webpage inside the app instead of having a separate code.
 
It sounds like
Please try not to fill in too much for others, because this leads to misunderstanding. I am suggesting no such thing.
I would like XF to have PWA functionality, so that addon developers can create hybrid apps that work for 3rd party addons.
Are you sure on the first one?
Please read the experience of this developer who used his Progressive Web App to add native capabilities and publish it to 3 app stores:
Its not an exhaustive example but it does give you a feel for whats possible.
 
Please read the experience of this developer who used his Progressive Web App to add native capabilities and publish it to 3 app stores:
That was a good read, and the services he mentions like PWABuilder and MacInCloud might come handy in the future. 😎
 
Did some testing and with caching (service worker) does give some problems. So i left the service worker empty and used deferred prompt. This way you don't have to cache anything and the user can hit a button to show the install banner.

Normally you could put something in the service worker file so chrome thinks you are caching, but doesn't work for me. Only caching the front page (or were your start_url in the manifest is pointing to) would also be an option and enough for google to automatialy show the install banner.


Add this to page_container (head) for xf1:
Code:
<link rel="manifest" href="manifest.json">

<script>
      window.addEventListener('load', function() {

        var outputElement = document.getElementById('output');
        var btnSave = document.getElementById('btnSave');
        var deferredPrompt;

        navigator.serviceWorker.register('service-worker.js', { scope: './' })
          .then(function(r) {
            console.log('registered service worker');
          })
          .catch(function(whut) {
            console.error('uh oh... ');
            console.error(whut);
          });

        window.addEventListener('beforeinstallprompt', function(e) {
          console.log('beforeinstallprompt Event fired');
          e.preventDefault();

          // Enable the button.
          btnSave.removeAttribute('disabled');

          // Stash the event so it can be triggered later.
          deferredPrompt = e;

          return false;
        });

        btnSave.addEventListener('click', function() {
          if (deferredPrompt !== undefined) {
            // The user has had a postive interaction with our app and Chrome
            // has tried to prompt previously, so let's show the prompt.
            deferredPrompt.prompt();
 
            outputElement.textContent = 'Install banner opened';

            // Follow what the user has selected.
            deferredPrompt.userChoice.then(function(choiceResult) {
   
              console.log(choiceResult.outcome);
   
              if (choiceResult.outcome == 'dismissed') {
                console.log('User cancelled homescreen install');
              }
              else {
                console.log('User added to homescreen');
              }
   
              // We no longer need the prompt.  Clear it up.
              deferredPrompt = null;
            });
          }
        });
      });
    </script>

Plus some icon and color settings.

Add the manifest.json file to your root and also an empty service-worker.js file.
Example manifest:

And put this button somewhere (i have it in a notice)
Code:
<button id="btnSave" class="button" disabled>Click to install our Web App!</button>


Problem with caching in chrome is also getting it out everyone's browser cache if you make a mistake. If you are testing cache with service-worker this can come in handy:
Code:
<script>
if ('serviceWorker' in navigator) {
  caches.keys().then(function(cacheNames) {
    cacheNames.forEach(function(cacheName) {
      caches.delete(cacheName);
    });
  });
}
</script>
 
Last edited:
Google did not create AMP out of the goodness of their own hearts. Google created AMP because they want YOUR content on THEIR servers with THEIR ads and analytics.

Why are users flocking to AMP? Because most websites look like this on a phone (with thanks to the Oatmeal):

191805

If your website plays well on a mobile phone (As XenForo 2.x does out of the box), you do not need AMP, PWA, FWB, or anything else.
 
As for the "every website needs to have an app", f- Reddit and every other website that insists on my installing their app which then just displays the content in a web UI anyway. Apps = silos.
 
Don't forget GDPR, Cookies, Notifications, Location Services, Newsletter signup, etc.! And this doesn't even mention the content jumping around constantly through JavaScript chicanery to try to get you to click on ads which have just appeared where content used to be. Or you have to scroll through the ad. Or... or...

191806
 
When I saw that headline @RobinHood the way I read it was "OneSignal ruined Web Push Notifications for PWAs". All they had to do was restrict it to people who were logged into the site with a soft modal prompt. For guests, it should always be a button press instead of a prompt.

Maybe it's pessimistic; IMO it's too late to fix it.
 
In the place I found it, one person mentioned that one potential way to get around it could be to only allow the request once the PWA is actually installed on the phone and the user has launched it using the icon.

Someone even said this, which sounds pretty shady

My "favorite" is all the sites that seem to be running this bit of javascript that asks if they can show you notifications before they actually send the request to the browser. That way, if you say no, they can try again later because they haven't actually been blocked at the browser level.

So many sites that should know better are doing this. Looking at you, Tom's Hardware.

Even with all this, and even if we eventually get them on iOS, they'll still be notifications 'lite' compared to native app notifications. They keep getting more rich, configurable and interactive as the os level, which is a really good thing.

Doubt we’ll ever get that level of granularity through a PWA notification.

194725
 
The popups to allow notifications unsolicited really is annoying and intrusive, but if a member initiates such a feature via their settings then that is valuable.
 
My "favorite" is all the sites that seem to be running this bit of javascript that asks if they can show you notifications before they actually send the request to the browser. That way, if you say no, they can try again later because they haven't actually been blocked at the browser level.

So many sites that should know better are doing this. Looking at you, Tom's Hardware.
This is what I meant by soft prompt. I don't think the last part about not remembering saying no is always intentional. I think that's just how the code was developed, as we did with Mobile Suite, and with hundreds of simultaneous users, we got the feedback and added a user preference.

If those sites like Tom's Hardware send notification prompts to guests, they actually wouldn't have a way to remember the browser except for cookies, which can be deleted. The problem is not the soft prompt, it's that they are prompting guests.

If OneSignal does it that way by default, then most people do it that way (since most use OneSignal), unknowingly or otherwise; that's the root of it.
 

Similar threads

Top Bottom