Remove standalone / fullscreen requirement

[triblondon]

The requirement for apps to have a display property of 'standalone' or 'fullscreen', implemented as a result of #143, is problematic. Many in the web community object to this being considered a web best practice, notably articulated by Jeremy Keith in his post, though I'm not endorsing all the sentiments he expresses there.

For me the question is whether Lighthouse is a community project designed to judge conformance with universally agreed best practices, or whether it is specifically designed to express the proprietary requirements of Google Chrome in respect to offering an install prompt. If the latter, then since the heuristics/requirements for installability are not subject to a standard, it's totally valid for Chrome to set whatever requirements it likes - though care should probably be taken to ensure that the intersection of all vendors' installability requirements don't leave developers with insufficient control over their own application design.

However, if Lighthouse is a community tool, then this rule could be seen to be narrowing a recent specification that offers developers a range of options for good reasons. If options like 'browser' and 'minimal-ui' are bad, why are they in the manifest spec?

If this is deemed justfiable on the grounds that 'native apps don't have a URL bar so PWAs shouldn't either' I would point to zoomability as a similar case - we consider sites that disable zoom to be bad practice, despite pinch-zooming the whole UI not typically being a feature offered by native apps.

This topic came up as part of a discussion of PWAs on a TAG thread.

cc @marcoscaceres @torgo

[paulirish]

For me the question is whether Lighthouse is a community project designed to judge conformance with universally agreed best practices, or whether it is specifically designed to express the proprietary requirements of Google Chrome in respect to offering an install prompt.

Really, it's both. And when there is a conflict between these two goals, then we need to resolve it as Chrome shouldn't require something that violates best practices.

I think it'd be good if Lighthouse required a value for the display property, but not requiring any particular value. We certainly want the developer to decide what makes the most sense for their users.

I believe there's an outstanding Chrome bug regarding its treatment of display in determining install promptability (e.g. crbug/596729 and crbug/471623, but I'm supportive of separating that from Lighthouse's evaluation here. Until the issue is resolved, we can note it as a documentation note in Lighthouse.

[samccone]

I think it'd be good if Lighthouse required a value for the display property, but not requiring any particular value. We certainly want the developer to decide what makes the most sense for their users.

+100

[brendankenny]

Should this be two audits? It sucks to say, "yep, you're 100% good on add to homescreen prompting" when they aren't.

As pointed out in w3ctag/design-reviews#123 (comment), installability signals are non-normative and up to the UA. If we expand add-to-homescreen auditing to e.g. Firefox (#356), there will be an even more pressing need to be able to handle both "progressive" best practices and browser requirements when they differ. "Best Practices" could include an audit that display has some value, but "User can be prompted to Add to Homescreen [in Chrome]" could have the existing audit under it, until the display requirements are changed upstream.

[brendankenny]

Actually, is setting display to something a best practice? The value falls back to browser if unset, which means no manifest should ever fail #496.

[triblondon]

The manifest spec does not require the property to be set, which is why it has a default. Lighthouse is not in the business of changing web platform specs by the back door, so why be contrary to what is a very clearly expressed spec point? If a web app best practice were to have a standalone display mode, then wouldn't that be the default for any app that shipped a manifest with no display property? Instead the default is 'browser'. So if that's a bug, maybe it should be addressed in the spec?

[marcoscaceres]

The decision to make "browser" the default was made because we (those of us working on the Web Manifest spec) foresaw the issues outlined in the "regressive web apps" blog post, and because we found extensive evidence that legacy applications rely heavily on the presence of, at least, a back button [1][2] - even if they claim otherwise.

We also acknowledge that other display modes don't provide the best user experience for many apps (which is why their in the spec, obviously).

But one really needs to design specifically for "standalone" for an application to function well: the research we did for one [1] demonstrated that only a tiny percentage of apps actually work as standalone: developers unintentionally rendered their sites useless in "standalone" mode in practice or simply dropped back into desktop mode. If we learned anything from "standalone", is that signaling as standalone will likely negatively impact users (hence "browser" as the default).

Quoting directly from [1] - published Feb 21, 2014, n=78,000 web sites - based on iOS's standalone mode:

Despite these 1097 sites claiming they can be used as standalone, what we found was that the majority of web apps (90%, or 324 out of 360) can not be used as standalone. Only a tiny fraction (10%, or 36 out of 360) are able to run as standalone - and 28% of those had significant limitations (described below). There is, in fact, a greater percentage (12%) of desktop sites masquerading as installable web apps than there are actual standalone applications.

... Of those 36 apps that were true standalone web apps (i.e., has an icon, is usable on a mobile device, can be navigated), 10 (28%) of those had issues where they either left the user stranded without being able to "go back" - or worst, suddenly navigated to the desktop version of the site. The only option for a user is to drop back to the home screen and open the application again....

[1] https://github.com/w3c-webmob/installable-webapps/blob/gh-pages/ios_standalone/README.md
[2] http://w3c-webmob.github.io/installable-webapps/#navigation

[brendankenny]

I think we're mixing a few issues here, so I'm confused by exactly what's being talked about :) To be completely explicit, I believe these are the points being discussed:

1. display === 'fullscreen' || display === 'standalone' is not a PWA "best practice" test

   Everyone who has commented so far seems to agree with this, so I'm not seeing an issue. Obviously there are those who disagree, hence Chrome's current add-to-homescreen-prompt criteria (cc @PaulKinlan)

2. We could instead simply test if a display property is set by the manifest

   According to the spec, an invalid or missing display gets set to 'browser', so this isn't going to work directly. correctly fall back on erroneous manifest display modes #497 fixes the manifest parser to correctly handle display fallback.

   We could test if display was set to a valid value. We track developer warnings in debugString, so we can surface those in the lighthouse report. Irrelevant to PWAs since display will still have 'browser' as the parsed value, but helpful for authoring.

3. Chrome currently requires a display value of 'fullscreen' or 'standalone' to get the add-to-homescreen prompt.

   This is outside of the scope of lighthouse and should be taken up in e.g. crbug/596729 or a better tracking crbug, if one exists yet.

4. Should Lighthouse still reflect Chrome's requirements in the "User can be prompted to Add to Homescreen" section, regardless of item (1), until (and if) the requirements change?

   @paulirish suggests documentation may be enough for this. I mentioned it's not ideal to provide an add-to-homescreen-prompt checklist and not include all requirements for getting the add-to-homescreen prompt in it, but keeping an audit for Chrome's current requirements would probably need to have an explicit "in Chrome" added to "User can be prompted to Add to Homescreen" if we decided to go that way.

[triblondon]

@brendankenny we're only mixing issues in the sense that they are being mixed by Lighthouse itself. Paul said earlier that Lighthouse is both a community testing tool for verifying best practice, and also a means to assert compliance with Chrome's installability criteria, and that these should be one and the same.

That being the case, all these issues are inextricably linked and are issues with Lighthouse. I'm picking up an implication from your response that Lighthouse should separate itself from Chrome policy (via 'in Chrome' annotations on tests, and presumably addition of 'in Firefox', 'in Opera' etc variants), and I'd say that may be a good way to deal with it.

If it has been established that Lighthouse is not somewhere to set policy but a tool to surface the policies of vendors and help developers comply with them, then the policy point moves to be an issue with Chromium. Right now though, I'm still unclear about whether Lighthouse has role in setting/creating/expressing Chrome's installability policy.

[paullewis]

we're only mixing issues in the sense that they are being mixed by Lighthouse itself.

You're right, and I think the best thing to do is deal with them individually, as Brendan's done. I think it's right that we follow the spec when looking for a display property, and that we can acknowledge that a non-value or a value of fullscreen, standalone, or browser is valid. That's distinct from whether you get installability in any given UA.

If it has been established that Lighthouse is not somewhere to set policy but a tool to surface the policies of vendors and help developers comply with them, then the policy point moves to be an issue with Chromium. Right now though, I'm still unclear about whether Lighthouse has role in setting/creating/expressing Chrome's installability policy.

We express Chrome's installability policy today, and we can (and will) update our messaging to be clearer. Quite how we do that is TBC, but we will definitely do it, and ideally in a way that allows developers to understand how installability criteria differ between UAs, as and when other UAs start to ship installability.

Our goal is to help developers be successful, irrespective of UA or implementation strategies. We care about outcomes, and so our goal (which we don't always meet, but are trying to) is to express the user-centric outcomes of auditing a given URL. From that perspective, all UAs are equally distant from Lighthouse, since our goal is to represent what will happen (across multiple UAs) if you do or don't do certain things.

From my perspective, we have the following todos:

1. Disambiguate the display property test. Change that to check for fullscreen, standalone, browser, or nothing at all (which implies browser)
2. Introduce a second test or annotate the current one. A large part of the issue here is around messaging, which is something we're going to have to iterate towards. We can mark the test in some way that makes it clear that this is a Chrome-centric audit, and, as other vendors ship installability, we ensure Lighthouse captures that, too.

And, of course, the conversation will continue on crbug and elsewhere as to what the criteria for installability should be.

[PaulKinlan]

@marcoscaceres got me thinking about an different approach to what @brendankenny was suggesting.

Would the set of tests for standalone be different from browser display mode? If for example, you don't offer navigation aids etc in standalone that is more of an issue than if you didn't have them when you just launch a browser tab. It might be worth exploring the tests that are critical based on the context of how they are intended to be launched and run.

[paullewis]

Would the set of tests for standalone be different from browser display mode? If for example, you don't offer navigation aids etc in standalone that is more of an issue than if you didn't have them when you just launch a browser tab. It might be worth exploring the tests that are critical based on the context of how they are intended to be launched and run.

This is a good point, and it taps into the fact that the different display modes imply different UX requirements for users. At this stage, the conversation is primarily around installability and ensuring the messaging is accurate for multiple UAs. But you should definitely open another issue where we can discuss how to test a site / app differently depending on display modes.

[paulirish]

I've just merged #496. It changes lighthouse behavior to validate that the user has defined a value for the display property. It must be set (to one of the 3 valid values).

We're not done here. There are (at least) three more steps I believe are left.

1. Adding an explicit check that you have requirements to trigger the a2hs prompt in Chrome.
2. Adding an explicit check that you have requirements to trigger the a2hs prompt in Firefox.
3. Request Chrome changes it prompt behavior to allow all 3 of the display values, (therefore allowing the explicit value of browser).

[triblondon]

Honorable Pauls &tc,

Do you have any update on the state of this? It seems that current behaviour of lighthouse is different from the behaviour of Chrome, and the lighthouse test is missing the 'minima-ui' value.

[dracos]

Have submitted a PR to add minimal-ui as an allowed value (going by the previous commit by Paul Irish that stated it was testing for allowed values).

[paulirish]

Okay time for an update. :)

Speaking for myself, I don't think the current UI of choosing browser feels like an app-like experience and I'm hesitant to introduce users to PWAs without a better UX. That said, I totally agree that apps/sites that rely on URLs for shareability (as all the best webby things do) are not served well by standalone/fullscreen. And there needs to be a better compromise solution.

The good news is that Chrome will soon be adding support for display: minimal-ui and including it in the display check for the install-banner prompt. I'd love to see Samsung browser support it and include in their PWA check as well.

As for Lighthouse, we want our PWA checks to reflect the working definition of a PWA. (Some other alignment is still necessary, as well). There's wide consensus that a webapp should be configured for install-banner prompting if its a PWA. So we are dependent on UA implementation details so that we can reflect to Lighthouse users what they can expect. Additionally, I'm very happy to help illuminate to users if there are browser differences on these details.

We plan to have Lighthouse start passing sites that use display: minimal-ui. Naturally, this will fallback to browser in browsers like Chrome today, however we're comfortable with Lighthouse proactively leading the charge here. We will also reintroduce the display check into the PWA section, so so anyone trying to get 100/100 will get nudged toward minimal-ui/standalone/fullscreen.

BTW - Some more links hidden in here

Just to link up related items:

Owens' comment on crbug:

The fact that you can't access the omnibox easily from standalone mode is known and we have a plan to fix that by supporting Chrome Custom Tabs (CCT) mode via display:minimal-ui and exposing something like an omnibox in a persistent notification.

comment from installable_manager.cc:

// TODO(dominickn,mlamouri): when Chrome supports "minimal-ui", it should be
// accepted. If we accept it today, it would fallback to "browser" and make
// this check moot. See https://crbug.com/604390.

[triblondon]

That's significant progress, thanks. I think maybe we disagree on whether an "app-like experience" is always necessarily a good thing. This still leaves developers choosing minimal-ui not because they feel it's appropriate for their app but because it is required in order to get the install prompt. But I'm very happy to see an option that includes at least some browser chrome and a visible URL being accepted as valid, which is a genuinely significant improvement. Thanks!

[paulirish]

Now fixed (as of #1847)

from the source:

• webapp-install-banner audit
• manifest value check

[MarcoTroost]

HI folks,

I love the work you've done with Lighthouse! The current display-modes validated by Lighthouse though do not represent the current spec, and i think this is rather annoying. Sometimes people really DO want their PWA to 'just' have the browser display-mode.

My website for instance www.droominfo.nl is somewhat monetised with banners. If one clicks on a banner, one should interact with the advertiser in another tab. I do not want my user to go to chrome and leave my pwa completely. The whole browsing experience ought to happen in an environment that my users are accustomed to, a browser 'offered' by my PWA.

I totally agree with triblondon on the bias regarding the 'app-like-experience'. Lighthouse suggests that the highest possible 'goal' of a website is to evolve into an app, and thereby must look and behave like an app.

Perhaps the definition of a PWA is quite the other way round.
A PWA is imho a supercharged website, that can utilize features from the mobile device and not a semi-app that can load some stuff from the internet.

Keep up the good work!