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

Progressive Web App for FixMyStreet #1996

Closed
Dylanderv opened this issue Feb 13, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@Dylanderv
Copy link

commented Feb 13, 2018

Hi!

I would like to make an open source Progressive Web App as a client for FixMyStreet.
I wanted to know if you will have the use of it or not?

For this I need an API, I saw in this conversation that you weren't encouraging people to use the API. Did you changed your mind since early 2016?

@dracos

This comment has been minimized.

Copy link
Member

commented Feb 13, 2018

Hi, thanks for your comment. Would you consider perhaps contributing whatever is necessary to make FixMyStreet itself a progressive web app, rather than create a separate client? Do your ideas differ greatly from what the site already offers? I think it would be preferable for it to be part of the site, I'd certainly be happy for it to count as a PWA. We already use appcache (due to browser requirements that do not support service workers) for some offline staff activity, and using a service worker as well on top would be good. The main issue I can see arising is how you will deal with the mapping element, unless you can see some way of linking in with any offline mapping the mobile device has.

The mobile endpoint is still there as it was then; you can use it, but I'm not sure it would perhaps operate as you would expect/hope, and I'm afraid we can't guarantee anything about it. Of course, if this is for your own FixMyStreet installation, you might be able to work on improving that.

@Dylanderv

This comment has been minimized.

Copy link
Author

commented Feb 14, 2018

I'm a complete newbie in perl, I never touched on line of code of this language, and it's not my goal to put my hand in it.

The fact is that the technical stack for the PWA may be too different than the one in FMS.
In my opinion a PWA needs to be built from scratch, in order to match the specifications (like the time to interactive needs to be less than 3000 ms with a slow 3g for example).
And to do that, I was thinking of using some lightweight js library like vuejs or reactjs, and use tools I know to have a better optimisation.

The other thing is that I think the presentation layer (here the PWA) needs to be separated from the backend and supplied by an API layer build over the backend.

Finally, the PWA I want to build will be based on js with node and a build manager. These are not the tools you are using here for FMS, not the same dependancies manager or build manager. If we want to make continuous integration with automated test and everything for the PWA, having it in this repository will add a big complexity.

I hope you understand my point.

@dracos

This comment has been minimized.

Copy link
Member

commented Feb 14, 2018

Whilst I do understand your point, there is no reason why FixMyStreet itself could not be a progressive web app, with a service worker and a manifest, and indeed I hope it will be at some point. Given many aspects of PWA are client-side, I'm not even sure whether you'd have to write any Perl, certainly it's not something I could say either way off-hand. I have written PWAs in different languages, even PHP! I can't stop you writing something separate, I can't expect you to learn a new language (if necessary), but I just wanted to be clear there isn't a requirement that a PWA has to be separate "in order to match the specifications", and that will have its own issues and problems.

On your points about technical stacks, building from scratch, and 'presentation layer', please could I encourage you to read https://adactio.com/journal/9963 – the "progressive" is the most important bit of PWA, to my mind. Whilst we already have many calls made by our existing JavaScript to progressively enhance the site, it will never not have presentation also provided server-side.

FixMyStreet's front page here already has a time-to-interactive of less than 3000ms on slow 3G – everything needed is included in the initial response. There's more details on that at https://www.mysociety.org/2017/11/24/peak-performance/ . This could of course get even better with service worker caching etc, and it would be great if that could be done for all users of the platform; a service worker on the actual site would work for everyone.

@Dylanderv

This comment has been minimized.

Copy link
Author

commented Feb 15, 2018

Yes I totally understand that a PWA can be written in different languages and it doesn't have to be separate to be a PWA, but what I was trying to say is that I don't think working on a big monolithic application is the best thing to do, and I do think that separating the application in different layer is better (like this) and that's why I was talking about presentation layer. And you may know that even if you separate the presentation layer, it is possible to make server-side rendering.

I think, like you, that the progressive word is the most important in a PWA (and I don't think I told the opposite).

When I was talking about the 3000ms, I wasn't questioning FMS's performances at all, it was just an example because I wasn't aware if you knew that there was some specifications for PWA.

@dracos

This comment has been minimized.

Copy link
Member

commented Feb 15, 2018

There is no specification for PWA that states it must be responsive in <3000ms on slow 3G; there is no specification for PWAs at all :) Google's checklist (not a spec) at
https://developers.google.com/web/progressive-web-apps/checklist has 10 seconds as its baseline, and 5 seconds as its "exemplary".

If we added a service worker and a manifest (no Perl code necessary to do either) to FixMyStreet as it is now, it would meet the entire checklist for being a PWA. The only reason we haven't is because we haven't had the resources and no-one (except potentially you :) ) has volunteered, along with the added complication that we need to maintain our appcache-based offline updating for inspectors using older non-SW browsers, which will presumably make it a bit trickier. That might not meet your ideal, but as I already said, the main issue with any sort of PWA will be how to deal with mapping – without a solution to that, it doesn't really matter if the header/footers still work offline or not... :)

Here is a quick GIF of the site on mobile, 3G, 4x CPU slowdown, the main delay is the tile loading, which applies wherever a PWA is done (aside, going to make that Hide pins much bigger!):

A SW/PWA could still provide a better, quicker experience in certain areas; it would still require connectivity – which is fine – but it then pushes the question as to what do you actually want to achieve (which I asked in my original comment)? If it is e.g. saving a draft report if the user tries to submit the new report form when offline because they've lost signal since locating the report, then that would be JS-based only and work well on the existing website. If it is e.g. using only geolocation rather than showing any form of map if there's no connectivity to show a map, then again, that would be JS-based and work well on the existing website. Any thing I can think of to improve the experience would work nicely progressively enhanced on top of the existing site, benefiting everyone.

It is of course easier for you, the developer, to start from scratch, without the years of history and decision making (and mistakes, and cruft, and technical debt, and...) that have gone into the current codebase. But I believe we should do things that make things easy for the user, not the developer. Given people will be coming to the website, it makes more sense if that could be made more PWA-like, as much as possible. We can of course agree to disagree, but that's how I see it :)

PS I don't think our code is as 'monolithic' as you imply, because e.g. it already has many JSON endpoints for providing a progressive experience of the map in browsers that support it. But note that our baseline is, and hopefully always will be, that the map is an HTML 2 imagemap that works when the JS fails to load (as it once did many moons ago for a while in IE, when I left in a final comma by mistake and no-one noticed because the site carried on working) :)

@Dylanderv

This comment has been minimized.

Copy link
Author

commented Feb 15, 2018

Yes, I get it, but I'm not the one who will add the service worker in FMS sorry.

First I wanted to train on js library and PWA making, then I saw your project and I thought I could help you creating an PWA client (that's why I created this issue), but what you're asking me here is not really what I want to do.

I hope you'll find the ressources to turn FMS into a PWA, or find someone who can do this for you :)

@dracos

This comment has been minimized.

Copy link
Member

commented Feb 15, 2018

Thanks! And good luck with your endeavours.

@Dylanderv Dylanderv closed this Feb 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.