Desktop PWA works with Discourse!

[sam (Sam Saffron)]

I remember getting pretty upset when Chrome shutdown the app launcher, this was a feature I used on quite a few sites.

Luckily thanks to work we have done for Android you can have it back now on your Discourse site.

Head to: chrome://flags/#enable-desktop-pwas , turn it on.

If you also want to capture links and send to the page enable Desktop PWAs Link Capturing and there is also some extra caching you can turn on.

Then, visit your Discourse site and click “Install to desktop…”

You now have a dedicated application you can launch for your Discourse site.

Special thanks to @Falco and @featheredtoast for pushing us to support this fancy on Android cause now it pays off and we get it on desktop as well!

On Chrome on Mac the terminology is a bit different, but it works nonetheless.

It is important to note that this will not work with for you on all sites, you need a manifest and some fancy to support it.

Note This is definitely a big Electron killer for simple repackages given that it is stuck on Chrome 59 now.

[sam (Sam Saffron)]

There are a few things I want to clean up here that I will do in a theme component.

I think that in PWA desktop mode

• The title should be a static “Discourse meta” cause the text duplication here is really annoying

• Mini Profiler needs to find another spot cause it is really annoying there.

• Big logo seems too much visually

• A back button and refresh button would be nice

Luckily we have window.matchMedia('(display-mode: standalone)').matches to detect if we are in this mode so its simple to make a component to clean this stuff up.

[Falco]

@sam

Luckily we have window.matchMedia(‘(display-mode: standalone)’).matches to detect if we are in this mode so its simple to make a component to clean this stuff up.

One thing I played with a bit is adding stats like:

• Pageviews from PWA
• Installations

To the Discourse Admin Dashboard and/or Google Analytics.

We can detect pageviews with that media query and installs with:

window.addEventListener('beforeinstallprompt', function(e) {
  // beforeinstallprompt Event fired

  // e.userChoice will return a Promise.
  // For more details read: https://developers.google.com/web/fundamentals/getting-started/primers/promises
  e.userChoice.then(function(choiceResult) {

    console.log(choiceResult.outcome);

    if(choiceResult.outcome == 'dismissed') {
      console.log('User cancelled home screen install');
    }
    else {
      console.log('User added to home screen');
    }
  });
});

[DavidGNavas (David García-Navas)]

Super cool feature!

@sam

It is important to note that this will not work with for you on all sites, you need a manifest and some fancy to support it

Is it planned to support this feature in hosted instances?

[sam (Sam Saffron)]

Oh it works on all discourse sites (hosted by us or self hosted), as long as you are on beta and up and have https enabled and enforced

Try it on random sites on the Internet and you will have less luck, Twitter does not work, mattermost does not and the list goes on

[DavidGNavas (David García-Navas)]

Thanks!

@DavidGNavas

Is it planned to support this feature in hosted instances?

I meant on Discourse-hosted sites. I tried on Meta and the desktop app works perfect, but in our site https://brain.goodrebels.com/ the desktop app opens a new tab in Chrome. Perhaps we have to wait a bit for the latest update? or change some settings in /admin?

[sam (Sam Saffron)]

Hmm we will investigate this cc @Falco @featheredtoast

I wonder if this is related to your site requiring login

[mcwumbly (Dave McClure)]

@sam

I wonder if this is related to your site requiring login

Worked for me on our require-logon site, FWIW

---

This is pretty interesting stuff. What are the advantages / disadvantages of using Discourse this way? I’d love to hear folks thoughts on this.

I know very little about this, so I’m just speaking based on what I saw in 2 min.

Wired: It’s really easy now to open the app now with Spotlight on Mac
Tired: I can only have one tab open

Wired: I can brag about how we have an app now (kinda)
Tired: I can only have one tab open

… you get the idea.

[codinghorror (Jeff Atwood)]

Yeah IMO this is kind of pointless. It’s like a web browser… but worse!

[sam (Sam Saffron)]

Yeah I get that, I would find this more useful if there was only 1 discourse site I visited and if the icon on the desktop taskbar updated with notifications. But, I float between lots of sites so for me there is more limited use unless I had an app to bind all my sites, and even then lack of tabs is a big pain.

For chat (eg slack, mattermost) I find this very useful which is why I actually started this research. If my job was to moderate a single Discourse site I would also find this useful.

So yeah, I do not think this will be for everyone, but for some it may be handy, especially if there was some value add in the taskbar.

[mcwumbly (Dave McClure)]

I think it could work well, but it would take some additional work on the design of the UI. For instance, in Slack, you don’t need browser tabs because the navigation between channels is built into the app as a first class citizen. Maybe similar things could be done with theme components, where the UI could be designed within these new constraints.

That might work very well for many of our users who do fit into this mode for the most part:

@sam

I would find this more useful if there was only 1 discourse site I visited

[codinghorror (Jeff Atwood)]

How does this relate to the instructions at

Implement Badging API

Here’s how to test this in Windows on Chrome (latest version 73, just released today): go to the three dots menu at the upper right in Chrome select More Tools → Create Shortcut tick the “Open as window” checkbox select Create Like so [image] I’ll try it out … it works! [image]

[sam (Sam Saffron)]

Same old wine in a brand new bottle.

[Falco]

Oh this topic was focusing on the ability to install Discourse in Desktops (which is no longer experimental).

The other one was mostly about the experimental Badging API. To use the Badging API you need to install to desktop, so this one here is a pre-requirement.

[codinghorror (Jeff Atwood)]

First post looks quite wrong though? If it is not “experimental” where is that chrome menu item??

[sam (Sam Saffron)]

Yeah this is totally out of date, no point carrying this topic anymore.

@sam

A back button and refresh button would be nice

Is a very big killer here usability wise. Now that his is official we should write a proper theme component to make PWA work as expected.

[Falco]

There is one here:

Back button in iOS PWA

Here’s a back/forward component I threw together. I used @media to make it appear since ‘Mobile’ doesn’t work for an ipad. This was developed for an app so it has no way to detect iOS PWA. I’d be happy to add it if anyone has ideas. [IMG_9980] https://github.com/davidkingham/mobile-navigation/ I found a snippet on this page, but my skills are lacking to implement it.

Looks like it’s aimed at mobile iOS.

@codinghorror

First post looks quite wrong though? If it is not “experimental” where is that chrome menu item??

To get the menu entry in Chrome we must enable the service worker in desktop.

[codinghorror (Jeff Atwood)]

@Falco

To get the menu entry in Chrome we must enable the service worker in desktop.

Yes but the tradeoff is that service worker adds a ton of support emails to our work… did you want to whitelist the service worker for Chrome and Firefox or something like that @sam in addition to Android?

[sam (Sam Saffron)]

@codinghorror

whitelist the service worker for Chrome and Firefox or something like that @sam in addition to Android?

I think we should whitelist Chrome now … hold off on whitelisting Firefox till this is done:

1407202 - (desktop-pwa) [Meta] Desktop Progressive Web App Support

[codinghorror (Jeff Atwood)]

Ok @falco can you do the needful on whitelist? We already whitelist Chrome / Android as I recall.