Closed Bug 1232706 Opened 4 years ago Closed 4 years ago

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

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 48
Tracking Status
firefox48 --- fixed
relnote-firefox --- 48+

People

(Reporter: Margaret, Assigned: sebastian, NeedInfo)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-needed)

Attachments

(7 files)

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.
Flags: needinfo?(bbermes)
Flags: needinfo?(alam)
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.
Flags: needinfo?(bwalker)
Flags: needinfo?(bfrancis)
Flags: needinfo?(bbermes)
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).
Flags: needinfo?(alam)
> 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.
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.
Flags: needinfo?(bwalker)
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
Flags: needinfo?(michael.l.comella)
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).
Attached image 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
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.
Flags: needinfo?(michael.l.comella)
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.
Depends on: 968427
(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.
Assignee: nobody → s.kaspari
Version: 35 Branch → unspecified
Status: NEW → ASSIGNED
Attached image promotion_banners.png
Attachment #8738991 - Flags: feedback?(alam)
Attached image shortcut.gif
Attachment #8738993 - Flags: feedback?(alam)
Comment on attachment 8738991 [details]
promotion_banners.png

++++++++++
Attachment #8738991 - Flags: feedback?(alam) → feedback+
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.
Attachment #8738993 - Flags: feedback?(alam) → feedback-
(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
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
Attachment #8739336 - Flags: review?(margaret.leibovic)
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 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.
Attachment #8739332 - Flags: review?(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.
Attachment #8739336 - Flags: review?(margaret.leibovic) → review+
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.
(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.
See Also: → 1240560
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/
Attachment #8739332 - Flags: review?(margaret.leibovic)
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/
(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.
Attachment #8739332 - Flags: review?(margaret.leibovic) → review+
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
https://hg.mozilla.org/integration/fx-team/rev/619cbf869369713e8425a3d06b9498b32a1cd20e
Bug 1232706 - Promote "Add to home screen" for frequently visited websites. r=margaret
https://hg.mozilla.org/mozilla-central/rev/619cbf869369
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
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.
Flags: needinfo?(s.kaspari)
(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.
Attached image 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.
Flags: needinfo?(s.kaspari)
Depends on: 1264243
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.
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".
Depends on: 1265351
Depends on: 1266383
Added to Fx48 Aurora release notes
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?
Flags: needinfo?(s.kaspari)
(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.)
Flags: needinfo?(s.kaspari)
Blocks: 1269908
No longer blocks: 1269908
Depends on: 1269908
Depends on: 1270034
Depends on: 1276910
Depends on: 1277180
Depends on: 1280071
See Also: → 1421174
You need to log in before you can comment on or make changes to this bug.