[b1tr0t]

Hi there, I'm the product manager for PWAs on the Chrome team.

Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t

Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recently (https://web.dev/progressive-web-apps). Consolidating and adding docs is an active area of investment, and our goal is to create a well lit path for developers to succeed with PWAs.

[hutzlibu]

Well, it would have been helpful to provide a simple example of a working pwa.

The example at

https://codelabs.developers.google.com/codelabs/your-first-p...

was way too complicated as a first example, if all I wanted to know was how to make my app installable and is also broken as it uses some outdated tools. (don't remember the details)

Also, it could have been mentioned somewhere, that when you serve from localhost, you do not need SSL to install it. Knowing that, would have saved me the trouble of messing with apaches config and certificates.

So that was very frustrating as a start.

Much more helpful was a very simple hello world pwa which was barely installable. But it worked. And from there it was easy.

https://medium.com/james-johnson/a-simple-progressive-web-ap...

[b1tr0t]

Thanks for the feedback! This is now the reference "first PWA" example: https://web.dev/codelab-make-installable. Let me know if you find it easier for new devs to get started with. The other codelab and a lot of other scattered content will be removed once we finish the migration to web.dev.

[vbezhenar]

Please consider contributing to MDN. It's the best source for web development and it would be great to keep everything there, properly cross-referenced, etc.

[efraim]

Don't they already do that? They are part of the MDN Product Advisory Board since 2017.

Blog post of the announcement: https://blog.chromium.org/2017/10/building-unified-documenta...

[diggan]

The statement from b1tr0t directly refute that Google is contributing to MDN, as they put it: "Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev". As far as I know, web.dev is not MDN and has nothing to do with MDN.

[b1tr0t]

Mentioned in another comment, but to be clear, our team contributes to MDN, and will continue to do so.

Web.dev is not an MDN replacement.

[b1tr0t]

As another user mentioned, we do contribute to MDN. MDN is where we point devs for reference documentation. web.dev is for guides, how to's and other support docs.

[diggan]

Heh, you're asking a googler who's basically responsible for some of the actions Google is taking with Chrome, trying to make the web only browseable via Chrome and centralizing information under their own Google brand, to contribute to a cross-company/community effort (Mozilla + Microsoft + open source hackers)? While noble, I can only wish you good luck.

I think the sail has long sailed for asking Chrome/Google to help out with the openness/sharing on the web/internet. It's time we just start ignoring them instead.

[davvolun]

Just want to note that you specifically mentioned Microsoft working with open source hackers in this comment saying that the ship has long since sailed on Chrome/Google contributing to the open web.

I don't know, never say never I guess. I'm certainly not going to defend Google's track record on openness and privacy -- there have been, under even the most generous of interpretations, huge missteps, and I don't think they deserve the benefit of the doubt -- but they do contribute. Edge backed by Chromium?

[diggan]

I was thinking about a particular announcement where Mozilla announcing that they are working with Microsoft on MDN.

Color me surprised when I discovered that also Google is mentioned there! Here is the announcement: https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

Reading that announcement makes b1tr0t's statement "We've started to consolidate docs under web.dev" even worse, as they previously said they are gonna contribute to MDN, but now they have turned and use their own shit anyways.

Screw you Google.

[b1tr0t]

Our team actively contributes to MDN. Web.dev is not an MDN replacement, it's a channel for guides & other supporting documentation.

[diggan]

Just so understand correctly, you're contributing reference documentation to MDN but then everything else goes into web.dev? Why not contribute the "guides and other supporting documentation" to MDN as well?

As I understand, the Product Advisory Board for MDN was created with Mozilla + others in order to combat the fragmentation of information, but your actions seems to do the opposite.

[searchableguy]

More background services would be very nice even though it's a bit of a security nightmare. A request was opened almost 5 years ago for background geolocation services.

Any plans for https://developers.google.com/nearby ?

I don't want Google or central authorities to decide which PWAs are "trustworthy" directly to ask for certain permissions but there could be a way or compromise. I don't remember which feature it was but it required yes from Google.

I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them. It should be mandatory and important or may show a default screen with permissions and few dangerous ways they can be used for.

[b1tr0t]

Background geo, including geofencing is challenging, but there may be a way forward. We're exploring this conceptually, but it's not in the plan for 2020. I'd certainly like to be able to improve the capabilities of web based ride sharing and similar apps that have a need for this.

Bluetooth discovery is an especially thorny area from a privacy perspective. What use cases did you have in mind?

Asking for permissions upfront has been found to be an anti-pattern in systems UXR. Research has found that users make better decisions and find the experience less interruptive when permissions are requested in context at runtime. For example, in a video chat app, it's better to ask for the camera/mic permission at the start of the first chat session, not when the app first starts. Mac OS, Android etc. and other platforms have all been moving in this direction over the past few years.

When the permission is requested, we're investigating ways that we can do more to communicate permission risks to the user. Nothing publicly shareable yet, but do expect experiments to be showing up in dev channels over the next few months while we try new things.

[hutzlibu]

"I really want the first screen after installing PWAs to be their privacy policy or detailing which permissions/how they use them."

Wouldn't it make more sense, to display this info before you install a pwa?

[searchableguy]

Oh, yeah before. Though, I think it should also show that screen if a user hasn't used the app for a while.