Discussion about the heuristics on when to show the "install" banner
Reported by
felipenm...@gmail.com,
Apr 7 2016
|
||||||||
Issue descriptionChrome Version : 49.0.2623.110 OS Version: OS X 10.10.5 Discussion about the heuristics on when to show the "install" banner: We were discussing this on a slack channel. I believe we could find a balance about it, to allow developers to somehow, trigger the banner. Notes: - I totally understand and agree that it must be well treated not to become an "ad" kind of action. - We agreed that the USER should decide when(and if) to install a webApp. - If a user buys a new phone, the user will have to remember all the WebApps he has installed, and then visit them...wait for 5 minutes and visit them again, so it can be installed and he/she will be able to add it to the screen or folder they are used to have it. - Some apps are focused in notifications and we don't use very often. Take swarm for example. We install it and then we get to know when our friends are traveling from its notifications. We only open it when we travel(which is usually not very often). - New apps will have to have their names way more "rememberable", once even if my best friend told me a webapp is amazing, I will only be able to install it afterwards and I WILL forget it! When I need to use it, I will not remember the name(url!?) of it. - After using the first time, the cache/localstorage/offline support will be there. If the user forgets the page address, this data will never be reused (even if the user wanted to use it) but will still be there. Having in mind those concerns, we were talking about the possibilities. One idea, was to maybe add to the heuristics the information about the web notifications. If the user has accepted them, or has visited the page from one of them, it means the user is somehow interested in the page. We could take in consideration the time of the visit, as well. If the user is interacting with the page for a while, even if it is the first load, they could be prompted if they want to install it. I would like to hear from you, what you think about this. (note: some of those concerns are things I take a lot of care, specially because my memory is terrible)
,
Apr 13 2016
,
Apr 20 2016
,
Apr 20 2016
,
Apr 20 2016
Not sure who else has been looking at heuristics, but Dom should be able to triage.
,
Apr 20 2016
Assigning to owencm@ as the product owner for this. I'm very wary of enabling developer triggering for the banner. We're already planning on incorporating user interaction with a site (not just visits) to the heuristic, so that the banner could trigger once the user has sufficiently interacted with a site - not just on notifications. We definitely don't want to annoy users at any point. When a user buys a new phone, if they restore their device, that should also restore their web app shortcuts.
,
Apr 21 2016
There's definitely room for tweaks here. I met with Ainslie and Rolfe in the last couple of weeks to get their thoughts about the next generation of A2HS. (this makes me realize we really need to meet to discuss Q2 plans and for me to share the outcome of those discussions!) Ainslie's main feedback was that he thinks we should try some ambitious experiments and see what the data looks like - the volume of A2HS is way below what he cares about for reducing his "decisions per navigation" metric. I think once we move to using the Site Engagement Service for A2HS that we should do some A/B tests spread on a wide range of values and collect the data to see how they behave. Speaking of developer prompting, it could be interesting to explore having a lower heuristic for explicit developer triggering in response to a user action. For example if the user spends 30 seconds on the site (or whatever low SES measure we chose) we could fire an installpromptavilable event with a prompt callback that must be called in response to a user action. The prompt UI could then be more of a confirmation than a passive banner like we have today. This seems like an ideal candidate for Phosphor/Origin Trials incidentally where all the browser vendors agree with the problem but we don't know the right API to solve it and collecting data would be super useful. Hmmmm...
,
Apr 21 2016
,
Sep 8 2017
Archiving this as: - this is a really old bug - notifications should already be taken into account - we are actively discussing adding more developer control |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by jonathan.garbee@chromium.org
, Apr 8 2016Labels: -Type-Bug -OS-Mac OS-Android OS-iOS Type-Feature