Current functionality
Discourse works beautifully when you pin it your homescreen on an Android device from Chrome (or Firefox) – but this isn’t particularly discoverable out of the box. Is it worth thinking about advertising the fact that they can tap on the menu in Chrome/Firefox and add it to their homescreen? Then it’ll look and feel like a native app, without having any of the normal browser UI, like an address bar etc.
Future functionality: PWA
@codinghorror Would it perhaps be worthwhile jumping through the necessary hoops to get browsers to recognise Discourse instances as Progressive Web Apps? According to Yet another blog about the state and future of Progressive Web App - The blog of Ada Rose Cannon, this means
- has a service worker (requires https)
HTTPS will be out of the box for (I assume) most paying customers, and can be set up by those running their own instances.
- has a web app manifest (with at least minimal config)
Looks like Discourse already does this.
- it is the second distinct visit to the web site.
This will happen organically – although I note that Opera has been experimenting with providing users with an explicit indicator from the first visit, so this may become unnecessary.
Hacking in a service worker
It looks as though the only piece that is missing for this is a service worker. The good news, of course, is that there’s no requirement the service worker actually do anything! This means that is should be possible to “hack this in” by
- Adding a stub JS file, called, say,
sw.js, to the root of the domain - Popping the following snippet in the
<head>:
<script>
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js').then(registration => {
console.log('ServiceWorker registered in scope ', registration.scope)
}).catch(error => {
console.warn('Failed to register ServiceWorker', error);
});
}
</script>
(Of course, it may be necessary to “un-es6” this – but I think you can safely assume that any browser which supports service worker supports fat arrows and the global console object!)
Making the ServiceWorker do useful work
First prize would, naturally, be to have the service worker do some useful work. I’m not familiar with Ember, but it looks like GitHub - DockYard/ember-service-worker: A pluggable approach to Service Workers for Ember.js could provide a pluggable service worker engine upon which useful functionality could be built.
They allow you to effectively act as a proxy server between the web application itself and the network, caching and managing requests. It’d be pretty sweet if Discourse were semi-available offline – letting you read (or re-read) cached topics and so on. That is, I guess, the final end-point in this topic.
