1232706 - Promote "Add to home screen" if user visits website often

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Web Apps (PWAs), defect)

Description

[:Margaret Leibovic]

Is a user visits a site a lot, we should offer to add it to their home screen.

We'll need to decide what "a lot" means here, and how we want to promote this.

Comment 1

[Barbara Bermes [:barbara] - NI please!]

I'd defer to Bill or Ben Francis for their previous research around this. I know Chrome is using heuristics that they are not super happy with yet, I think --> https://twitter.com/slightlylate/status/646755651847327745

It probably also depends on the time span and not just x times visited during x amount of months etc.

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I think this makes sense. Perhaps something more ephemeral than our in-product helper UI though. We could start with just a long toast/snackbar-like UI like what we suggested for TP before.

(In reply to Barbara Bermes [:barbara] from comment #1)
> It probably also depends on the time span and not just x times visited
> during x amount of months etc.

I don't have an idea of what number(s) to use right now but this also makes a lot of sense. 

We should also think about all the different methods we currently give our users to "Add to Home screen". This will affect our messaging (however we choose to notify the user).

Comment 3

[:Harald Kirschner :digitarald]

> I don't have an idea of what number(s) to use right now but this also makes a lot of sense. 

Chrome can update its heuristics in a day and is actively evolving numbers and heuristics itself. The last time we talked they went from 2 visits in a week to 2 visits in the last 5 minutes or so; much less conservative. We also talked about different heuristics for games (after playing 5 minutes?) vs content sites (returned 2 times within a day?). We should take a similar route to be able to experiment and hypothesize.

Comment 4

[Bill Walker [:bwalker] [@wfwalker]]

I agree with Harald, I would love to find a way to tune this heuristic after deploying it. Beyond that, I don't have any special insights.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: Screen Shot 2016-01-29 at 12.31.40 PM.png

I've decided to add a mini-helper UI to our roster of "tips UI" that we use to talk to our users. We should use this here, for the "Add to home screen" tip. Let's decide how we define "if a user visits a website often".

This should put us on par with current "Add to home screen" experiences out there ATM, and we can revisit messaging concerns as they arise. But I think this design is a good place to start addressing this bug.

Behaviour: 
 - Shows up and persists until dismissed explicitly
 - Stays fixed to bottom of the screen as users scroll

Comment 6

[:Margaret Leibovic]

We can try to be clever by using switchboard to adjust our heuristics. We would need to create different experiments for the different values, but I think it would make sense to pick a conservative guess and then roll that out to some percentage of our users to see how much it shows up (and how often people actually click on it).

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: spec_helperUImin.png

Attaching spec

This actually inherits a lot of styles from our helper UI for things like tab queue, send tab to device, tracking protection, etc... But I still called out most of the styles as best I could.

let me know if anythings unclear

Comment 8

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Note: Talked to mcomella about this already but, for the icon, the Firefox build icon can be the fallback here, but if we can - we could try and use the touch icon that will show up on the home screen.

Comment 9

[Bill Walker [:bwalker] [@wfwalker]]

There's more food for thought here:

https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=en

Comment 10

[Kevin Brosnan [Ex-Mozilla]]

I am a bit apprehensive about promoting something that we know can break in rather awful ways see bug 968427. All the homescreen icons can stop working in some situations. This feels a lot like promoting the bookmark migration code that increased crashes bug 1232608.

Comment 11

[:Margaret Leibovic]

(In reply to Kevin Brosnan [:kbrosnan] from comment #10)
> I am a bit apprehensive about promoting something that we know can break in
> rather awful ways see bug 968427. All the homescreen icons can stop working
> in some situations. This feels a lot like promoting the bookmark migration
> code that increased crashes bug 1232608.

Then let's figure out what we need to do to make sure these shortcuts don't break. This is an important feature we want to promote, we need to make sure it doesn't break.

Comment 12

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: promotion_banners.png

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: shortcut.gif

Comment 14

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8738991 [details]
promotion_banners.png

++++++++++

Comment 15

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8738993 [details]
shortcut.gif

talked on IRC

we should just switch to the home screen right after the user presses the button.

Comment 16

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #15)
> we should just switch to the home screen right after the user presses the
> button.

Looks like this:
https://www.youtube.com/watch?v=-OBo6gE3L_o

Comment 17

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: MozReview Request: Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r?margaret

Review commit: https://reviewboard.mozilla.org/r/45047/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/45047/

Comment 18

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: Github: Add experiment for "Add to home screen" promotion

Those patches are built on top of the history table. This is working quite well. That's why I'd like to land this and after we have the additional "visits" table we can look at the data and improve the heuristic as needed.

For the experiment I want to try to use Switchboard to distribute the values for the heuristic. This will allow us to play with some of the knobs without pushing new code. Additionally this will give us a sense of how to track the success of 'changing' experiments.

This is what I propose for the first iteration (See experiments.json):
* 50% of Nightly users - Rather aggressive because the population is low
* minimumTotalVisits: 5 - The website has to be visited at least 5 times before
* lastVisitMinimumAge: 30sec - The last visit has to be at least 30 seconds old. This is to avoid prompting for quick refreshs or accidentally closed sites.
* lastVisitMaximumAge: 10mins - The last visit should not be older than 10 minutes. This will make it unlikely to show too often. Chrome seems to use "Visited twice in the last 5 minutes" [1]. So I'd like to see how we perform with 10 minutes.

[1] https://developers.google.com/web/updates/2015/03/increasing-engagement-with-app-install-banners-in-chrome-for-android?hl=en

Comment 19

[Sebastian Kaspari (:sebastian; :pocmo)]

Also: I store the data about whether the user has created or declined to create a home screen shortcut in the url_annotations table. I wonder if we could use this data to modify/improve the frecency algorithm (Adding a home screen shortcut is probably a very strong indicator that this is an important site for the user).

Comment 20

[:Margaret Leibovic]

Comment on attachment 8739332 [details]
MozReview Request: Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r?margaret

https://reviewboard.mozilla.org/r/45047/#review41997

::: mobile/android/base/java/org/mozilla/gecko/promotion/AddToHomeScreenPromotion.java:102
(Diff revision 1)
> +        if (tab == null) {
> +            return;
> +        }
> +
> +        if (!Tabs.getInstance().isSelectedTab(tab)) {
> +            // We only ever want to show this promotion for the current tab.

So we won't ever show this for tabs loaded in the background, even after the user switches to them. I'm fine with that compromise.

::: mobile/android/base/java/org/mozilla/gecko/promotion/AddToHomeScreenPromotion.java:123
(Diff revision 1)
> +        }
> +
> +        HomeScreenPrompt.show(activity, url, title);
> +    }
> +
> +    private boolean shouldShowPromotion(String url, String title) {

It may be worth creating an in-tree documentation page for this somewhere in here:
http://gecko.readthedocs.org/en/latest/mobile/android/fennec/index.html

It would be good to have a place to point curious web developers.

::: mobile/android/base/java/org/mozilla/gecko/promotion/AddToHomeScreenPromotion.java:163
(Diff revision 1)
> +            // The last visit is to old. Do not show promotion.
> +            return false;
> +        }
> +
> +        final UrlAnnotations urlAnnotations = GeckoProfile.get(activity).getDB().getUrlAnnotations();
> +        if (urlAnnotations.hasAcceptedOrDeclinedHomeScreenShortcut(activity.getContentResolver(), url)) {

What thread is this method being called on? Looking at the Tabs listener logic, it looks like it will be called on the UI thread:
http://hg.mozilla.org/mozilla-central/file/e847cfcb315f/mobile/android/base/java/org/mozilla/gecko/Tabs.java#l644

We should probably be doing these DB queries on a background thread...

::: mobile/android/base/java/org/mozilla/gecko/promotion/HomeScreenPrompt.java:127
(Diff revision 1)
> +            public void run() {
> +                GeckoAppShell.createShortcut(title, url);
> +
> +                Telemetry.sendUIEvent(TelemetryContract.Event.ACTION, TelemetryContract.Method.BUTTON, TELEMETRY_EXTRA);
> +
> +                goToHomeScreen();

Is this what Chrome does? I suppose it makes sense to see where the shortcut ended up and move it around if you want, but this is different from what we do from our "Add to homescreen" menu items.

Speaking of which, we should file a bug about improving that flow. Right now there's no feedback after you select one of those menu items, and you're not sure if adding the shortcut even worked.

Comment 21

[:Margaret Leibovic]

Comment on attachment 8739336 [details] [review]
Github: Add experiment for "Add to home screen" promotion

Left some comments on the PR, but overall this seems fine. If the server doesn't support values your other patch should just catch an exception and keep the prompt disabled, so there's nothing blocking merging this before values are supported.

Comment 22

[Sebastian Kaspari (:sebastian; :pocmo)]

https://reviewboard.mozilla.org/r/45047/#review41997

> So we won't ever show this for tabs loaded in the background, even after the user switches to them. I'm fine with that compromise.

Yeah, I think it makes sense to only show this in the context of the user actively loading a tab right now.

> It may be worth creating an in-tree documentation page for this somewhere in here:
> http://gecko.readthedocs.org/en/latest/mobile/android/fennec/index.html
> 
> It would be good to have a place to point curious web developers.

This is a good idea! Maybe we should start this documentation outside of the tree as long as we might update the heuristic via Switchboard. Maybe MDN?

> What thread is this method being called on? Looking at the Tabs listener logic, it looks like it will be called on the UI thread:
> http://hg.mozilla.org/mozilla-central/file/e847cfcb315f/mobile/android/base/java/org/mozilla/gecko/Tabs.java#l644
> 
> We should probably be doing these DB queries on a background thread...

I'll have a look and update the code. I wonder if lint could warn me about this.

> Is this what Chrome does? I suppose it makes sense to see where the shortcut ended up and move it around if you want, but this is different from what we do from our "Add to homescreen" menu items.
> 
> Speaking of which, we should file a bug about improving that flow. Right now there's no feedback after you select one of those menu items, and you're not sure if adding the shortcut even worked.

This is what antlam asked for in comment 15 and on IRC. My first version of the patch had a in-app confirmation (See attached gif).

Chrome doesn't do this: They just show a toast.

Comment 23

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #20)
> Speaking of which, we should file a bug about improving that flow. Right now
> there's no feedback after you select one of those menu items, and you're not
> sure if adding the shortcut even worked.

I found bug 1240560.

Comment 24

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8739332 [details]
MozReview Request: Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r?margaret

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/45047/diff/1-2/

Comment 25

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8739332 [details]
MozReview Request: Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r?margaret

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/45047/diff/2-3/

Comment 26

[:Margaret Leibovic]

(In reply to Sebastian Kaspari (:sebastian) from comment #22)

> > It may be worth creating an in-tree documentation page for this somewhere in here:
> > http://gecko.readthedocs.org/en/latest/mobile/android/fennec/index.html
> > 
> > It would be good to have a place to point curious web developers.
> 
> This is a good idea! Maybe we should start this documentation outside of the
> tree as long as we might update the heuristic via Switchboard. Maybe MDN?

Good point. MDN sounds like the right place.

Comment 27

[:Margaret Leibovic]

Comment on attachment 8739332 [details]
MozReview Request: Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r?margaret

https://reviewboard.mozilla.org/r/45047/#review42345

Comment 28

[Sebastian Kaspari (:sebastian; :pocmo)]

https://hg.mozilla.org/integration/fx-team/rev/619cbf869369713e8425a3d06b9498b32a1cd20e
Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r=margaret

Comment 29

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/619cbf869369

Comment 30

[Marcos Caceres [:marcosc]]

Please let me know if I need to update the Installability Signals list in the spec:
https://w3c.github.io/manifest/#installability-signals

They are non-normative, but can benefit from our experience here.

Comment 31

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Marcos Caceres [:marcosc] from comment #30)
> Please let me know if I need to update the Installability Signals list in
> the spec:
> https://w3c.github.io/manifest/#installability-signals
> 
> They are non-normative, but can benefit from our experience here.

Thanks for the link! I think the reverse will also be true: We can experiment with different signals to see what affects they might have on a person's engagement with a website. This is just in the "experiment" stage, but we'll try to keep you updated with what we learn.

Comment 32

[Francesco Lodolo [:flod]]

Can someone explain what happens to the button with longer strings? For reference
https://transvision.mozfr.org/string/?entity=mobile/android/base/android_strings.dtd:contextmenu_add_to_launcher&repo=aurora

Comment 33

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: add_button.png

(In reply to Francesco Lodolo [:flod] - AWAY APRIL 13-17 from comment #32)
> Can someone explain what happens to the button with longer strings? For
> reference
> https://transvision.mozfr.org/string/?entity=mobile/android/base/
> android_strings.dtd:contextmenu_add_to_launcher&repo=aurora

The button can grow (see attachment). I just saw that in some cases the button can overlap the icon - I'll file a follow-up bug for that. If this is not good enough for all languages then we can address this in the follow-up too.

Comment 34

[Marcos Caceres [:marcosc]]

Just a heads up that I'm currently working on specifying the "beforeinstallprompt" and "install" events together with the blink folks (non-standards variants of which are supported by Chrome). Their current model could be improved a little, so we are working on in the spec. I'm hoping to have that specified next week. I can help implement parts of those in Gecko, but will need Fennec to dispatch the "install" event once install succeeds. Also, the "beforeinstallprompt" is cancellable: allowing developers over when the automated install prompt can be shown. Some more details can be found here:

https://github.com/w3c/manifest/issues/417#issuecomment-200192679 

(that's not exactly what I am specifying in spec - but gives a rough idea ... particularly in regards to ev.preventDefault() and the ev.prompt() Promise's behavior).

No bugs exist for the above yet.

Comment 35

[Sebastian Kaspari (:sebastian; :pocmo)]

Thanks for the heads-up, Marcos! I'd be happy to help in a follow-up bug to implement the "install events" on Fennec side.

Note that the current implementation is an experiment behind switchboard flags (in Nightly). We want to gather data on if/how home screen shortcuts are used and tweak the heuristics for prompting.
Also right now we do not treat the shortcuts as entry points for web applications but as just "better bookmarks".

Comment 36

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Added to Fx48 Aurora release notes

Comment 37

[Michael Comella (:mcomella) [NI reported issues only; no longer employed by Mozilla]]

Drive-by (skimming through the code because I was curious about the implementation!): it looks this patch added new xml for the homescreen prompt even though we have several other prompts that share the same animations and styles (e.g. tab queue). Sebastian, did you consider merging these dialogs?

Comment 38

[Andrzej Hunt :ahunt]

(In reply to Michael Comella (:mcomella) from comment #37)
> Drive-by (skimming through the code because I was curious about the
> implementation!): it looks this patch added new xml for the homescreen
> prompt even though we have several other prompts that share the same
> animations and styles (e.g. tab queue). Sebastian, did you consider merging
> these dialogs?

Bug 1266182 : )

(That's a kind of catch-all let's see how much we can unify the prompt code bug - there's not too much specific detail there yet.)