On URLs in Progressive Web Apps
I’m writing this as a short commentary on Stuart Langridge’s post The Importance of URLs which you should read (he’s surprisingly clever, although he looks like the antichrist in that lewd hat).
Stuart says
I approve of the Lighthouse team’s idea that you don’t qualify as an add-to-home-screen-able app if you want a URL bar
Opera’s implementation of Progressive Web Apps differs from Chrome’s here (we only take the content layer of Chromium; we implement all the UI ourselves, precisely so we can do our own thing). Regardless of whether the developer has chosen display: standalone or display: fullscreen in order to hide the URL bar, Opera will display it if the app is served over HTTP because we think that the user should know exactly where she is if the app is served over an insecure connection. Similarly, if the user follows a link from your app that goes outside its domain, Opera spawns a new tab and forces display: browser so the URL bar is shown.
But I take Jeremy Keith’s point:
I want people to be able to copy URLs. I want people to be able to hack URLs. I’m not ashamed of my URLs I’m downright proud.
One of the superpowers of the Web is URLs, and fullscreen progressive web apps hide them (deliberately). After our last PWA meeting with the Chrome team in early February, I was talking about just this with Andreas Bovens, the PM for Opera for Android. We mused about some mechanism (a new gesture?) that would allow the user to see and copy (if they want) the URL of the current page. I’ve already heard of examples when developers are making their own “share this” buttons and devs re-implementing browser functionality is often a klaxon signalling something is missing from the platform.
When I mentioned our musings on Twitter this morning, Alex Russell said “we’ve been discussing the same.” It is, as Chrome chappie Owen Campbell-Moore said “a difficult UX problem indeed”, which is one reason that Andreas and I parked our discussion. One of Andreas’ ideas is long press on the current page, and then get an option to copy/share the URL of the page you’re currently viewing (this means that a long press is not available as an action for site owners to use on their sites. Probably not a big deal?)
What do you think? How can we best allow the user to see the current URL in a discoverable way?
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
8 Responses to “ On URLs in Progressive Web Apps ”
How about a minimalistic URL bar at the top, similar to what Safari for iOS shows when the full address bar is collapsed (screenshot: http://i.imgur.com/uIJNZlr.png)? You could use the app’s “theme color” to make it blend in more with the app.
What does the third button on android do in a PWA ?
I agree with Šime: iOS simplistic location bar seems like a good idea.
I don’t like overriding the long-press gesture. Since it’s a common gesture it’s very likely that web app developers want to implement it as well. This kind of decision has already been a big pain with the 300ms click delay.
Also -1 for long press, it could be usefully for assistive technology
Maybe a special kind of sticky notification of the current web app, like the ones when you play media or record an activity on your phone. Via this notification you could also open/copy url?
In my recent take on this (cssence.com/blog/2016-05-beyond-progressive-web-apps), I considered letting apps have the swipe-from-top — at least in part, notifications and shortcuts to settings could still live there. However, in the comments of my blog post, Hugh Isaacs had the same idea as Robin above, so +1. While it may look weird for users, it would be a quick win in the current situation, without having to wait for major OS changes.
Password managers use the URL to determine which account to use, so I’d certainly want it available for browser plugins / share type things, as well as the user.
How about showing/copying the URL when long-pressing the top bar? (On iOS a tap of that scrolls to the top of the page, I don’t think it is used on Android?)
Showing the URl bar is absolutely imperative for security.
If I can’t see the URl, how do I know that I’m typing my password into the correct site?
I’ve written a bit about this at https://shkspr.mobi/blog/2015/05/web-based-oauth-is-a-security-nightmare-for-apps/ – if I’m asked to log in to an OAuth site, I *need* to know that it is not a forgery.
Personally, I’d display the URl as the page loads and then hide it beyond the top of the screen. If the user wants to get to it again, they can overscroll upwards.
The display of the URl could be as a toast (“Now loading from https://example.com/“) or just as a standard banner at the top of the page.