Mmmmmmm….Carrots!
Andrew Betts has called the Progressive Apps pattern “a bag of carrots” and, at some level, he’s right: the notion that something is an App does boil down to UI treatment and providing UI in return for developer effort is something browsers are in the business of doing.
He’s also right that what browsers give users and developers by implementing support for Progressive Apps (like Chrome and Opera have and which Mozilla is considering) is access to this differentiated UI treatment. It sure does sound flimsy! I mean, once a browser has support for Manifests and Service Workers, it’s just a bit of UI that lets you hide things like the default URL bar…what’s important about that? Everything, turns out.
UI treatment was the carrot that enabled SSL adoption and UI treatment is what will eventually sunset unencrypted network connections. These indicators are shown (or not) when developers do the right thing by users, and the browser is the guarantor of the user’s interests.
To users, the tech isn’t the product, the experience is. Andrew’s post captures this, but at the risk of being quarrelsome, seems to skip from initial window treatment (which we agree is important to “appyness”) to dismissing long-term experience differentiators like offline behavior and connection security which matter in the breach, not the norm. He’s also simply confused about search ranking changes: Google, to the best of my knowledge, doesn’t treat Progressive Apps any differently. Mobile-friendly, secure, fast sites? Sure. But those are attributes of any web experience (recall that all Progressive Apps begin life as regular pages). There’s no separate ranking boost (or demotion) for building a Progressive App.
Which leads us to the bit of Andrew’s post where he’s simply confused. I won’t dwell on those aspects because I feel it’s simply the result of misunderstanding, which knowing Andrew, will soon be corrected. Briefly, though: Andrew misunderstands the role of signals in search ranking, manifests, and Service Worker scopes. They are each potentially complicated topics. I probably owe more words on each, but TL;DR: the control over window focus that Andrew wants is coming via new Service Worker APIs. His concerns (when not unfounded) are going to be addressed (at least in Chrome).
Every browser is likely to implement their own version of Progressive Apps. It’s a general pattern (like “AJAX”), not a specific implementation. Chrome has set the hurdles to getting appy UI treatment at one particular point (TLS, Service Worker for offline, Manifest); others can do differently, but it is unlikely to make sense to do so.
In the same way that it’s a bad idea to provide a green lock icon for a fundamentally insecure site, it’s a bad experience for end users to offer an appy install flow for something that’s likely, in the user’s view, to “fail” as an app when disconnected, on MITM’d WiFi, or when the app doesn’t provide a high-quality icon. You’d hope never to find content with those negatives featured in an app store so browsers have incentives to ensure that users only upgrade sites that will prove equivalently useful when launched as apps.
By focusing on some corner cases (e.g. manifests that signal a desire to open in a tab), it’s possible to cast the ambiguities built into evolving a stable platform in pretty much any light you want. The “progressive” bit in Progressive Apps admits many evolutionary intermediate points. Andrew’s right that Progressive Apps are about incentives, but what the term calls out is a pattern that helps users discover things that embody (on average) a particular package of features that deliver long-term value. Not everything will make the cut, and that’s OK. The old web isn’t going away, but that doesn’t mean we need to pretend it has cleared these experience hurdles. Drawing the distinction is good for users, and that’s all that matters.
