Not The Post I Wanted To Be Writing…

I was on holiday after I/O last week when Jeremy wrote up some of his thoughts on the current state of PWA UI treatment for URL access. We chatted on Twitter (apologies to Frances) and he followed up here.

A few things seem obscured by the debate so far:

  • Most “opens” of PWAs happen in tabs through normal navigation. This has multiple causes, including an inability (which we’ll resolve at some point) for Chrome to be able to open navigations to PWAs from external sources in non-browser mode.
  • Very few sites were using display: "browser". This means that the change Jeremy objected to affects a minuscule number of sites (today). Now, obviously, Jeremy could go and evangelize all PWA developers to use display: "browser", but that sort of seems misguided because…
  • It doesn’t solve the problem of URL access or Sharing for sites that chose a different mode (e.g. fullscreen, standalone, or minimal-ui).

That last point is the high-order bit for me. Like Jeremy, I’m agitated over the lack of access to URLs for PWAs launched in a more immersive mode. That seems to be the thing to be frustrated about if you care about URLs and sharing and it’s my concern too — so much so that our team prioritized fixing it this quarter. New UI and gestures are hard to get right which is why I’m excited that Owen and Rebecca have been looking into how to make URLs accessible to PWA users no matter what display mode they’re in. We’ll have more to show on this front soon.

This matters because URL sharing is the proto-social behavior. It’s what enabled the web to spread and prosper, and it’s something we take for granted. In fact, if you look at any of my talks, you’ll see that I call it out as the web’s superpower.

We’re going to do something about this imminently because web developers who are building PWAs tend to forget about sharing. It’s been painful in our audits of partner apps to have to remind them to “build a share button” and then make sure it’s available on-screen in the right modes. It sucks to implement and it’s harder to use than a ubiquitous UI contract. At the same time, successful PWA developers are striving for UI consistency with the native platform their apps run on. They want their Web cake and the want to eat it like an App. The onus, then, is clearly on the browser to bring URL access back in ways that developers can’t defeat and can’t forget.

Which brings us to a final point that seems to have been lost: browsers can fix the real issue — sharing of PWAs and access to URLs — without anyone changing anything about their apps, and can do it out-of-band. Obviously, this is only true for browsers that support PWAs and have fast update cycles which, today, is all PWA-supporting browsers; namely Chrome, Opera, and Samsung Internet. The folks who work on these browsers — including myself — care as much as Jeremy does about the health and future of the web. I’m grateful to him for highlighting this issue and hope we can work together in the future to figure out ways to keep the best bits of the web healthy as PWAs become a common way to get back to sites users love.

9 Comments

  1. Posted May 31, 2016 at 4:07 pm | Permalink

    You should mention that displaying a URL also improves security. Sharing is good, but it’s only half the story.

    The ability to view the URL reduces the risk of phishing attacks which can lead to malicious activity in the background – installing malware, stealing personal credentials etc.

    And then there’s the ability to see the URL which might provide insight to the suitability of content, which might not be appropropriate for the person accessing it – either because of their preference, age or location.

    Chrome for mobile didn’t adopt the Google Safe Browser API until December 2015, so naturally we can’t make assumptions about Google’s intention to address security concerns from day 1.

  2. Posted May 31, 2016 at 4:12 pm | Permalink

    Sorry, one more thing :)

    You shouldn’t design anything based on how things are built “today”. It should be based on what we think will be built and how, in the future.

    Refer to the original WebView for an example.

  3. Posted May 31, 2016 at 4:18 pm | Permalink

    Thanks for the response, Alex.

    You mentioned:

    “Very few sites were using display: “browser”. This means that the change Jeremy objected to affects a minuscule number of sites (today).”

    …but amongst that minuscule (to Google) number are two of my own progressive web apps: https://adactio.com and https://thesession.org

    I totally get why the majority of progressive web apps would choose standalone or even fullscreen, but then to extrapolate that out to all progressive web apps is a step too far.

    I fear that, working at the scale that Google does, where real big data is readily obtainable, there’s a danger of dismissing edge cases for the perceived greater good. What appears to be a rounding error when you’re looking at overall numbers equates to real people down at the coalface.

    It’s possible to balance the big-picture long-term goals (“we need a way for users to get at URLs in progressive web apps, regardless of the display property value”) with the “minuscule” short-term—but just as real—concerns (“why is my progressive web app being punished for using display: browser when it’s currently the only way to give users access to the URL?”).

    You’ve got the big-picture view. You’ve always been good at having the big-picture view. But please don’t lose sight of the more immediate more mundane issues too.

  4. Posted May 31, 2016 at 4:22 pm | Permalink

    Paul: we’ve had this discussion on Twitter, but to re-iterate here for the benefit of those who weren’t part of those conversations: everyone should understand that Progressive Web Apps always begin life inside a tab. That is to say that to get to a full-screen PWA experience a user has to:

    • Visit a site and interact with it a bunch
    • Agree to a prompt to add it to the homescreen
    • Launch it from that prompt

    The site in question has to have been presented over TLS for any of this to happen, which means that it’s “really” example.com the user is talking to. If the site contains mixed content, the prompt isn’t show. If it starts to contain mixed-content later (while launched full-screen) or encounters a TLS error, a security indicator and the URL is shown, regardless of how it was launched.

    Further, if the user navigates to a URL that’s on another origin, that navigation takes the user to another tab in the browser (with the default URL bar). At no point is the PWA allowed to present full-screen content for other origins that don’t wish to be presented by that origin (e.g., an iframe) and the security system is set up to ensure that the icon on the homescreen that you tap only gives you a full-screen experience to the extent that you’re actually viewing content from the site you installed the PWA from.

    Hopefully that clarifies the issue for everyone else.

  5. Posted May 31, 2016 at 4:27 pm | Permalink

    Hey Jeremy,

    Thanks for responding. I take the point that access to the URL bar should be allowed for sites that want it. One option we’re considering here is a Chrome Custom Tab-alike UI for the minimal-ui treatment (among others). That’d get you the URL-bar (or similar) without much risk without putting it in the “sea of tabs”. Would that work for you?

    Regards

  6. Posted May 31, 2016 at 4:32 pm | Permalink

    Thanks Alex. I have a much better understanding now.

    I’m pleased to hear that you’re thinking about the URL bar and how to make that visible.

  7. Posted June 1, 2016 at 12:12 am | Permalink

    I like the sounds of a minimal-ui—something halfway between “let me see the URL” and “I’m back in a regular browser”.

  8. Max
    Posted June 1, 2016 at 2:16 am | Permalink

    Talking of not ignoring edge cases, there are a set of apps that have little or no interest in the URL. They are usually completely standalone and almost trivial in nature, and ports of apps that were packaged apps of some kind (eg crosswalk). Perhaps it would be appropriate to add a URL to the “help” page of the PWA of such an app, but the designers of these apps deemed it undesirable to constantly show the URL so that is how it should be.
    I’m just saying that we should be careful not to go completely in the opposite direction. Some method of being able to query a PWA’s URL after it’s been added to homescreen, but not part of the apps ui, is the way to go, IMO. It should solve the issue of the user asking “where did I get this from?” whether that be due to curiosity or a desire to share the app with someone else.

  9. Posted June 1, 2016 at 11:05 am | Permalink

    How about when launched from the home screen browser, standalone and minimal-ui apps started scrolled down just enough to hide the URL bar? s
    That gives a clear affordance for a URL, but could still give them the home screen icon. Scrolling up to get to the URL is an already natural gesture for any chrome android user. More with pictures at:

    https://medium.com/@kevinmarks/progressive-web-apps-and-url-bars-374f6bbdaf2f#.9hikqafg3