“You don’t control Xykon! He controls you!”
“Like I said: subtle.”
Redcloak, The Order of the Stick
Lots of discussion about progressive web apps recently, with a general consensus among forward-thinking web people that this is the way we should be building things for the web from now on. Websites that work offline, that deal well with lie-fi1, that are responsive, that are progressive, that work everywhere but are better on devices that can cope with the glory. Alex Russell, who originally coined the term, talks about PWAs being responsive, connectivity independent, fresh, safe, discoverable, re-engageable, installable, linkable, and having app-like interactions.
We could discuss every part of that description, every word in that definition, for hours and hours, and if someone wants to nominate a pub with decent beer then I’m more than happy to have that discussion and a pint while doing it. But today, we’re talking about the word linkable.
Strongly disagree with Lighthouse wanting “Manifest’s display property set to standalone/fullscreen to allow launching without address bar.”
A little background
First, a little background. Google Chrome attempts to detect whether the website you’re looking at “qualifies” as a Progressive Web App, because if it does then they will show an “install to home screen” banner on your second visit. This is a major improvement over the previous state of a user having to manually install a site they like to their home screen by fishing through the menus2 or using the “add to home screen” button in iOS Safari3. The Chrome team have then created Lighthouse, a tool which invokes a Chrome browser, checks whether a site passes their checks for “this looks like a PWA”, and returns a result.
So Jeremy’s point is this: Lighthouse is declaring that to be a valid PWA, you have to insist that when you’re added to the home screen, you stop showing the URL bar. And he doesn’t agree, because
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.
This is inspirational stuff, and it’s true. URLs are important. Individual addressability of parts on the web is important.
However. (You knew there was a “however” coming.) Whether your web app shows a URL bar is not actually a thing about that web app.
A little more background
A bit more background. In order to qualify as a progressive web app, you have to provide a manifest.4 That manifest lists various properties about this web app which are useful to operating systems: what its human-readable name is, what a human-readable short name for it is, what its icon should be, a theme colour for it, and so on. This is all good.
But the manifest also lists a
display_mode, defined in the spec as “how the web application is being presented within the context of an OS (e.g., in fullscreen, etc.)” Essentially, the options for the display mode are
fullscreen (the app will take all the screen; hardware keys and the status bar will not be shown),
standalone (no browser UI is shown, but the hardware keys and status bar will be displayed), and
browser (the app will be shown with normal browser UI, ie. as a normal website).
Now we see Jeremy’s point. Chrome propose that you only qualify as a “real” PWA if you request “fullscreen” or “standalone” mode: that is, that you hide the URL bar. Jeremy says that URLs are important; they’re not a thing to hide away or to pretend that don’t exist. And he has a point. The hackability of URLs is surprisingly important, and unsurprisingly dismissed by app developers who want to lock down the user experience.
But, and this is the important point, whether a web app shows its URLs is not a property of that app. It’s a property of how that app’s developer thinks about the web.
Property versus preference
If Jeremy and I were both to work on a website, and then discuss what should be in the manifest, we’d agree on what the app’s name was, what a shortened name was, what the icon is. But we might disagree on whether the app should show a URL bar when launched. That disagreement isn’t about the app itself; it’s about whether you, the developer, think it’s OK to hide that an app is actually on the web, or whether you should proudly declare that it’s on the web. That doesn’t differ from app to app; it differs from developer to developer. The app manifest declares properties of the app, but the
display property isn’t about the app; it’s about how the app’s developer wants it to be shown. Do they want to proudly declare that this app is on the web and of the web? Then they’ll add the URL bar. Do they want to conceal that this is actually a web app in order to look more like “native” apps? Then they’ll hide the URL bar. The
display property feels rather less like it’s actually tied to the app, and rather more like it should be chosen at “add-to-home-screen” time by the user; do you, the bookmarking user, prefer to think of this as a web thing? Include the URL bar. Do you want to think of it as an app which doesn’t involve the web? Hide the URL bar. It’s a preference. It’s not a property.
On the desktop
The above argument stands alone. But there are additional issues with having a URL bar showing on an added-to-home-screen web app. We should discuss these separately, but here I have them in the same essay because it’s all relevant.
The additional issue is, essentially, this. On my desktop — not my phone — I add an app to my “home screen”. This might add it to my desktop as a shortcut icon, or to my Start Menu, or in the Applications list, or all of the above, depending on which OS I’m on.5 If that PWA declares itself as being
standalone then how to handle it is obvious: open it in a new window, with no URL bar showing. Similarly,
fullscreen web apps launched from an icon should be full screen. But what do we do when launching a
browser display-mode web app on a desktop?
Since we’re launching something indistinguishable from just another browser tab, it should launch a browser tab, right? I mean, we’re opening something which is essentially a bookmark. But… wouldn’t it feel strange to you to pick something from your app menu or an icon from your desktop and have it just open a browser tab? It would for me, at least. So maybe we should launch a new browser window, with URL bar intact, as though you’d clicked “open in new window” on a link. But then I’d have a whole new browser window for something which doesn’t really deserve a whole new window; it’s just one more web page, so why does it get a window by itself? I manage my browser windows according to project; window A has tabs relevant to project A, window B has tabs relevant to project B, and so on. I don’t want a whole new window, and indeed I have extensions installed so that links which think they deserve a new window actually get a new tab instead.
It’s not very clear what should happen here. The whole idea of launching a website from an OS-level icon doesn’t actually mesh very well at all with the idea of tabbed browser windows. It does mesh well with the 2002-era idea of a-new-browser-window-for-every-URL, but that idea has gone away. We have tabbed browsing, and people like it.6
The Chrome team’s idea, that basically you can’t add an “OS-level bookmark” for a website which wants to be treated as a website, avoids these problems.
Jeremy’s got a point, though. Hiding away URLs, pretending that this thing you’re looking at is a “native” app, does indeed sacrifice one of the key strengths of the web — that everything’s individually addressable. You can’t bookmark the “account” page in Steam, or the “settings” window in Keynote or Word or LibreOffice. With the web, you can. That’s a good thing. We shouldn’t give it up lightly. But you already can’t do that for apps which use web technologies but pretend to be native. If Word or iTunes used a WebView to render its preferences dialog, would it be good if you could link directly to it with a URL like
itunes://settings? Yes it would. Would it be good if the iTunes user interface had a URL bar at the top showing that URL all the time? Not really, no.
There is a paternalism discussion, here. URLs are a good thing about the web; the addressability of parts is a good thing about the web. People don’t necessarily appreciate that. How much effort should we put into making this stuff available even though people don’t want it, because they’re wrong to not want it? Do we actually know better than they do? I think: yes we do.7 But I don’t know how important that is, when we can also win people over to the web by pretending that it’s native apps, which is what people wrongly want.
On balance, therefore, 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. I can see the argument against this, and I do agree that we’re giving up something important, something fundamental to the web by hiding away URLs. But I think that wanting to see the URL is not a property of an app; it’s a property of how you personally want to deal with apps. So browsers should, when adding things to the home screen, pretend that
display:browser actually said
display:standalone, but give people who care the ability to override that if they want. And if we want more people to care, then that’s what evangelism is for; having individual app developers decide how they want their app to be displayed just leads to fragmentation. Let’s educate people on why URLs are important, and then they can flip a switch and see the URLs for everything they use… but until we’ve convinced them, let’s not force them to see the URLs when what they want is a native-like experience.
- Jake Archibald eloquently names lie-fi as that situation where your phone claims to have a connection but actually it doesn’t, the lying sack of dingo’s entrails that it is, and just spins forever when you tell it to connect to a website. If you’ve ever toggled a device into airplane mode and back out again, you know what we’re talking about ↩
- although the Chrome approach is not without its problems ↩
- which is obscure enough that Matteo Spinelli made a library to show a pointer to the add-to-home-screen button; the library is wonderful, don’t get me wrong, but it ought to not need to exist ↩
- If you don’t know how to create one, see the manifest generator that Bruce and I created ↩
- and it should be noted that basically nobody actually handles PWAs properly on desktop yet; it’s all about mobile. But desktop is coming, and we’ll need to solve this. ↩
- Whether tabbed browsing actually makes conceptual sense is not up for discussion, here; we’ve collectively decided to use it, much as we’ve collectively decided that one-file-manager-window-per-folder isn’t the way we want to go either. ↩
- Hubris is a great idea. The Greeks taught us that. ↩