Infrequently Noted

Ada pitched into the conversation about the state of PWAs -- particularly Chrome's heuristics which prompted a Twitter discussion about some of the finer points of the user and developer experience. The background to these conversations is that today, the way users learn that they can install a Progressive Web App is via a prompt browsers decide to show at their discretion. The reason for heuristics is the quality bar that Ada so deftly summarized (and which Remy had an "aha!" moment about recently):

In the case of Chrome it encourages web app developers to build using newer Web Technology such as Service Workers and Web App manifest. It is great because it encourages the building of Web Apps as opposed to native by greatly reducing the barrier to getting your company’s app on the user’s home screen.

Andrew called this a "bag of carrots" and he's not entirely wrong. When I designed the heuristics that Chrome uses to designate something worthy of prompting it was with the user values of reliable performance, ease of recall, and long-term security in mind. Any site can continue to live all its days in a tab; nothing is taken away from that mode. PWAs are about adding new capabilities to existing ones.

The browser's goal is clear: create a hurdle tall enough that only sites that meet user expectations of "appyness" will be prompted for. Maybe Chrome's version of this isn't great! Feedback like Ada's, Andrew's, and Jeremy's is helpful in letting us know how to improve. Thankfully, in most of the cases flagged so far, we've anticipated the concerns but maybe haven't communicated our thinking as well as we should have. This is entirely my fault. This post is my pennance.

Prompting: The First, Worst Guess

The prompting solution to PWA discovery was our first, worst guess at how to communicate to users that they are on a site that can act like an app. Despite the prompt's defects, it bootstrapped what we now think of as "Progressive Web Apps" with Chrome, Samsung Internet, and Opera all implementing versions of it in their Android browsers (note: no browser on iOS supports this as Apple [prevents meaningful competition][13]).

Getting just this much done was an enormous lift. The team had to overcome organisational skepticism that, bluntly, was daunting. Like "when this is all over I'll write a book and it will not be a comedy" daunting. If you think Google is a one big happy family or has "A Plan ^(TM)"...um...well...I encourage you to apply! They can't fire me for encouraging smart folks to work here, right? Regardless, we pulled it off. But an early first attempt, no matter how difficult, isn't going to be where PWA discovery ends.

Obviously I can't talk about what Chrome will or won't ship -- I have neither the power nor the crystal ball required to make statements like that -- but I can outline a few alternatives to the current "go to example.com, use it for a while, do a jig, pray for the prompt" approach to PWA discovery. I'll also take a moment to cover some of the FAQs about the current design, including Ada's.

Engaged-user Prompting

"Engaged-user prompting" is the current (and in Chrome today, only) way to discover that a site you're on is a Progressive Web App. Remy recently noted why it wasn't a crisis that this doesn't mirror app-store listing: the main action that users need to perform to discover the content is the same thing they do to use the site/service. Progressive Web Apps cut out the App Store middle-man. If you can convince a user to visit your site, you have an opportunity to help them engage with your service. The prompt builds on that engagement and lets users who are engaged choose to keep the experience to the homescreen, where it can then launch in a more immersive mode.

Alone, though, this has major drawbacks.

First, users have been trained for the past decade to look for "apps" in App Stores and might not understand the install prompt. This is part learning-curve and part legitimate concern. To the extent that users encounter these prompts and try them out, we just need to wait for time to pass before the App Store expectation is dampened. To the extent that users and developers truly want App Stores, it's possible in the future. More on that below.

Next, in today's Chrome, there isn't any way other than the prompt for the user to understand that the site they're on is an app. If the user rejects the prompt there isn't much the site can do about it. Yes, there's the "Add To Homescreen" menu item, but it doesn't differentiate between plain-old-websites and PWAs in any visual way (despite using PWA metadata if available...very confusing). As a user, I'd love a visual indicator that let me know if sites I'm on are PWAs that I could keep; this is what "ambient badging" (the next section) is about.

Lastly, as Ada noted, developers aren't in control of the prompting timing. This is intentional. In conversation with developers and users, we came to understand 2 things very clearly:

1. Users bloody hate the web's cesspool of prompts and interstitials. It got so bad that Search finally had to do something about it, marking sites that prompted users who did nothing other than land on a page not mobile-friendly. It's hard to see how an experience like that is anything-friendly, but I digress.
2. Web developers do not feel as though they are doing anything wrong -- or worse, feel powerless to prevent their businesses from -- prompting users in ways that create horrible experiences.

The predictable result of this situation is that if a browser allowed users to be prompted to add something to the homescreen whenever the developer wanted, the overall experience of using the web would suffer. This isn't academic: we did this wrong with Geolocation and now we're having to walk it back; through pleading, data, and yes, breaking changes. As a team that cares most about users and a healthy web ecosystem, repeating mistakes like this simply isn't acceptable. The predictable result of designing the API the way Ada and others have suggested would be that we'd have to change it later. That change would likely have been of the form "you can call this API all you want, but the prompt isn't going to show until the user has engaged with your site".

What we went with in the end is simply the same thing, but inverted: by doing all the work to make your thing a Progressive Web App, you've signaled to us that you really do want users to keep this thing to their homescreens. If the timing isn't right, Chrome, Samsung Internet, and Opera let you delay the prompt and show it at a time of your chosing later using onbeforeinstallprompt.

Where the prompt design ended up is exactly where it would have come to rest anyhow; we just short-circuited user pain and spammy experiences.

One final point on prompting: the browser controlling when prompts happen was inevitable, but doing it this way has also allowed us to iterate and experiment. Chrome continues to change the engagement heuristic used to trigger the prompt. In the last year it has fallen from requiring 3 navigations with an hour between 2 of them to only requiring that the user scroll and tap while in a site for a few minutes. All of this is a direct response to developer feedback that they'd like the prompt to trigger more often, which we're balancing with user feedback about when and how often they're prompted. We're also watching the rates at which users accept the prompts. A fall in those rates would signal that we're being too aggressive, but thus far we haven't seen a drop.

The net effect, then, has been that PWAs haven't been introduced to users as a way that they can be spammed or which they (in general) resent. This mirrors how we designed Web Notifications: unlike native apps that frequently take the installation step as carte blanche to spam users with notifications, Web Notifications are always opt-in and easily user-controlled. This sort of careful API design that takes the cumulative experience of users into account is what sets the web apart. Unlike other software ecosystems, the web is not predatory by default and we aim to keep it that way while extending its capabilities further.

Ambient Badging

But enough about what we've done; what's next? Ambient badging!

Wouldn't it be great if there were a button in the URL bar that appeared whenever you landed on a PWA that you could always tap to save it to your homescreen? A button that showed up in the top-level UI only when on a PWA? Something that didn't require digging through menus and guessing about "is this thing going to work well when launched from the homescreen?" Such a button/indicator would let us do things like say to friends, colleagues, and customers "to get the Example app, go to example.com and tap the Frobulate button".

This sort of badging doesn't require any engagement from the user; it's a non-invasive signal that says "hey, this is something you can keep!".

We're actively working on ambient badging in Chrome for Android, but I'm honestly surprised that no other browser has beat us to the punch. When combined with prompting, ambient badging solves (or I hope it will solve) the inability to "verb" PWAs, to have a common visual and conversational vocabulary around "keeping" PWAs, and dealing more elegantly with discoverability for developers who feel frustrated by the prompt's capriciousness.

App Stores

App Stores have been part of my thinking around PWAs long before they were called "PWAs". All of the technology that we use for PWAs -- Manifests, Service Workers, and URLs -- are compatible with any store that wants to list them. This, I think, is a major un-tapped area of exploration and it's not exclusionary to ambient badging or engaged-user prompting. It's possible for a browser or platform to implement one, two, or all of these mechanisms in parallel.

Imagine a future version of a desktop OS you use every day. In our ever-more App Store-mediated desktop OSes, it seems natural to go looking for apps to "keep" there. In this sense, App Stores are search engines for "keepable" experiences. PWAs are exactly that: keepable experiences. The meta-data around listing and installation are all available and no separate bundle or package needs to be made. All the app store in question needs to do is to verify that the person listing the app is actually the owner, that the app meets whatever legal guidelines they enforce, and that the site meets the PWA criteria. Most of this is automatable and all of it is possible with the PWA technology we've deployed already. To the extent that changes are necessary to support it, the Manifest spec is explicitly designed to be extensible.

App Stores are another area where I'm surprised that we haven't seen more non-Chrome innovation. Can't wait to see what happens there next. PWAs are great fit for these "keepable experience" search engines.

Search

If PWAs are by-design App Store-compatible -- assuming those stores want to allow them to be listed and "kept" and aren't just pursuing proprietary visions where businesses pay exhorbitantly to re-develop for each platform and form-factor -- then Search engines are the proto-App Store.

It's possible to imagine Bing.com supporting specially highlighted & badged links that can be opened stand-alone by default if the resulting URL is a PWA...say a separate "open standalone" link next to a result. It's also possible to imagine separate "keep and visit" buttons in search results for URLs that are part of PWAs. Again, this future has been part of my thinking around distribution for PWAs for a long, long time, but it has only relatively recently become possible for crawlers to detect and enforce the quality bar that PWAs set.

Obviously, I have no inside information about what Bing's engineers think the future should look like, but if it seems natural for search engines to list Native Apps (which they do today), then this also seems mighty reasonable.

The Limits of "Keep" Are PWAs Strength

We've got pretty strong data from native app ecosystems that users don't use many apps, uninstall heavily, and in general find installation frustrating and taxing.

What's important about PWAs, then, is that they are OG "streamable apps". Most users won't install most PWAs most of the time, and that's fine. Hoping for more is how the tech industry found itself over-funding a gold rush only to reap the predictable consequences. The notion that native apps are "better" has largely been a self-reenforcing mantra borne of a Silicon Valley monoculture wherein the needs of billions are simply presumed (without investigation) to be the same as the behaviors of VC's kids, nephews/nieces, and close associates.

It's maddening. It's idiotic. But it's also why the web has a shot. Bubbles burst and the web will finally be ready to pick up the slack when this one does.

[13]: https://developer.apple.com/app-store/review/guidelines/#functionalito https://developer.apple.com/app-store/review/guidelines/#software-requirements