Closed Bug 1126186 Opened 9 years ago Closed 9 years ago

Allow users to turn off recommendations

Categories

(Firefox :: New Tab Page, defect)

defect
Not set
normal
Points:
5

Tracking

()

VERIFIED FIXED
Firefox 39
Iteration:
39.2 - 23 Mar
Tracking Status
firefox38 --- verified
firefox39 --- verified

People

(Reporter: Mardak, Assigned: emtwo)

References

Details

(Whiteboard: .002)

Attachments

(6 files)

With related tiles, even users with browsing history will see additional content placed on the new tab page. We could have options that toggle:

1) recommendations in general
2) recommendations that are paid
3) Mozilla's recommendations

where (2) includes content that would have been labeled [sponsored] and (3) would be anything else such as Mozilla sites or organic site recommendations (e.g., popular with Firefox users). (1) would be a combination of (2) and (3).

The changes here will probably also fix bug 1060158 in the process as we would basically be replacing the Classic and Enhanced labels and hopefully put in something more scrutable.
Attached image New cog wheel concept
(In reply to Ed Lee :Mardak from comment #0)
> With related tiles, even users with browsing history will see additional
> content placed on the new tab page. We could have options that toggle:
> 
> 1) recommendations in general
> 2) recommendations that are paid
> 3) Mozilla's recommendations
> 
> where (2) includes content that would have been labeled [sponsored] and (3)
> would be anything else such as Mozilla sites or organic site recommendations
> (e.g., popular with Firefox users). (1) would be a combination of (2) and
> (3).
> 
> The changes here will probably also fix bug 1060158 in the process as we
> would basically be replacing the Classic and Enhanced labels and hopefully
> put in something more scrutable.

We probably need to think this through. We would want to keep it as simple as possible because settings aren't an area users frequent. It might be better to bundle up recommendations together and have that displayed on "Enhanced" mode.

We'll have to put a couple mocks together and include this on user research/telemetry.
Yes, I'm concerned too about adding this level of control.

To make the distinct controls understandable, we'd need to explicitly identify and disclose each tile type. This would mean that we actually expect users to know the differences between regular history tiles, basic recommendations, paid content, and even Mozilla tiles. I personally think this is a huge burden and would cause a lot of confusion.

We currently have mocks that show a page-level control that allows a user to turn off ALL recommendations/featured content. This would preserve any "enhancement" of History Tiles. Can we at least start with one, universal control, and test to see what others may be necessary?

-A
There's also a different type of relationship that users might be interested (or confused): whether or not the user has the sponsored site in their history.

I.e., should users have the option of turning off recommendations only from sites they've never been to.

E.g., target.com is paying us to show a related target.com tile when the user visits walmart.com. If the user has never visited target.com and the user could choose to only show recommendations from sites they've been to, the target.com tile would not show up.

dcrobot's suggestion of starting simple of having just a single big on/off switch for recommendations or not would probably be sufficient for now.
pfinch, I believe you mentioned it's probably best to start simple for now so just a single toggle for suggestions/recommendations and if there's demand to turn off only certain types of recommendations, we can look into adding those in?

Choice is good but too much choice is confusing? ;)
(In reply to Ed Lee :Mardak from comment #5)
> pfinch, I believe you mentioned it's probably best to start simple for now
> so just a single toggle for suggestions/recommendations and if there's
> demand to turn off only certain types of recommendations, we can look into
> adding those in?
> 
> Choice is good but too much choice is confusing? ;)

+1 on Occam's Razor, but I feel we need to test this for specific outcomes.

These are the key considerations as I see them:

-Control for the user over their experience is non-negotiable

-Not having a large proportion of the installed base opt out of Related Tiles is a key objective

=> the only way I see us doing this is by delivering value in the browsing experience and explaining it is valuable.

I would therefore recommend that we test the ability to switch off recommendations by category.  A moment's introspection tells me that there are some categories I want recommendations for and others I do not.  

However, come what may, we know that we intend to add more variations of Tile - notification Tiles being next up I think.  We want to make sure that if a user opts out of Related Tiles, that opt-out should not be applicable to products yet unreleased.  A master toggle switch should not set the expectation of an opt-out of all iterations of the New Tab page.
Assignee: nobody → msamuel
Depends on: 1136203
Bug 1136203 makes it so we can remove the Enhanced option although one tricky technical aspect is that enhanced = true is what we check to decide to send a view/click ping or not.
Summary: Allow users to turn off different types of recommendations → Allow users to turn off recommendations
(In reply to Patrick Finch from comment #6)
> if a user opts out of Related Tiles, that opt-out should not be applicable
> to products yet unreleased.
We can scope the meaning of the pref as we add more functionality or migrate prefs to new prefs that allow for finer-grained controls. E.g., newtab.recommendation = true/false now -> newtab.recommend.suggestSite = true/false + newtab.recommend.suggestGlobal = true/false (where global refers to the suggestion feature that could show a tile independent of what's in the user's browser history).
Iteration: --- → 39.1 - 9 Mar
Flags: firefox-backlog+
Whiteboard: .? → .002
Status: NEW → ASSIGNED
kghim, given that we're aiming for affiliate suggested, affiliate directory, sponsored directory for the initial suggested landing, what should the menu options be and do?

1) show top sites
1a) show paid (turns on/off sponsored directory)
2) show blank

From this menu, users wouldn't be able turn off all additional content (paid/unpaid suggested/directory) ?
Flags: needinfo?(kghim)
for 1a), we should go with "show suggested sites" This familiarizes the user for recommendations in new tab and the eventual introduction of paid suggestions.
Flags: needinfo?(kghim)
What's the behavior of turning off suggested sites? Is it only removing the affiliate mozilla suggested tile? Does it also remove sponsored directory tiles? And also affiliate directory tiles?
(In reply to Ed Lee :Mardak from comment #11)
> What's the behavior of turning off suggested sites? Is it only removing the
> affiliate mozilla suggested tile? Does it also remove sponsored directory
> tiles? And also affiliate directory tiles?

The behavior of turning off 'suggested sites' will remove suggested sites on history tiles as well as sponsored Directory Tiles. The affiliate directory tiles should not be removed. 

From the user's perspective, you'd want to use your history filled with your favorite sites or not, regardless of paid or unpaid. With the introduction of suggested affiliate tiles on history first, the emphasis will be on the quality matching of history with suggestions and not the commercial aspect. 

The way dcrobot had mocked up the new tab controls had both 'show featured (previously sponsored) and suggested (related) sites.' This is too much wording - I'd just go with 'show suggested sites.' And since we have to be consistent, I would suggest changing the 'sponsored' label beneath the directory tile to 'suggested.'
(In reply to Kevin Ghim from comment #12)
> The behavior of turning off 'suggested sites' will remove suggested sites on
> history tiles as well as sponsored Directory Tiles. The affiliate directory
> tiles should not be removed. 
Why wouldn't affiliate directory tiles be removed if we're removing affiliate suggested and sponsored directory? As you point out, if users want to see just their history tiles whether or not a directory tile is paid/unpaid, it would make sense to also remove unpaid directory tiles that are potentially preventing history tiles from being shown.
Iteration: 39.1 - 9 Mar → ---
Blocks: 1141617
One switch to turn off everything besides history tiles sounds good to me. For the implementation, perhaps we can make each tile type (enhanced, directory, suggested) toggleable with their own pref then toggle all those prefs with the one menu item?

When we later implement a UI for finer-grained customization, these individual prefs can be toggled separately.
(In reply to Marina Samuel [:emtwo] from comment #14)
> One switch to turn off everything besides history tiles sounds good to me.
Yup, let's go with that.
Oh, thought there was a separate bug for menu strings:

1. Show suggested sites
2. Show your top sites
3. Show blank page

kghim will follow up on whether "What is this page?" can be moved into the menu and just link to an external page instead of being an in-product popup.
This patch also changes the labels on the menu to be clearer and has some minor styling changes in the menu.

Note that "What is this page?" is still visible on the left of the cog menu though we're considering moving it into the menu. That may be a separate bug.
Attachment #8578967 - Flags: review?(adw)
Some feedback we've gotten on this design:

The check mark make it seem like only suggested sites are shown and not top sites by default.

Possible solutions:
1) Change the text to something along the lines of "show suggestions and top sites"
2) Make "show suggested sites" a sub item under "show top sites"
Do we want to have two different check marks? Where the subcheck has the empty [] when unchecked while the top level check is just blank when unchecked?

I suppose an alternative would be to allow and default to both "show suggested sites" and "show top sites" checked. (This makes the two menu items true checkboxes as opposed to radio item with checkmarks.)
Attachment #8579707 - Flags: ui-review?(philipp)
Attachment #8579707 - Flags: ui-review?(madhava)
Additionally, phlsa's suggested in bug 1132552 comment 3 to stay close to existing panel UIs such as the forget menu with its radio button

This support page has a screenshot:
https://support.mozilla.org/en-US/kb/forget-button-quickly-delete-your-browsing-history

Forget the last:
◯ Five minutes
◯ Two hours
⦿ 24 hours

But dcrobot in bug 1132552 comment 6 has concerns of checkboxes and radio buttons make the interface feel old instead of new.
Comment on attachment 8578967 [details] [diff] [review]
v1: Allow users to turn off all tiles that aren't history tiles

Review of attachment 8578967 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/locales/en-US/chrome/browser/newTab.dtd
@@ +10,2 @@
>  <!ENTITY newtab.customize.classic "Classic">
> +<!ENTITY newtab.customize.topsites "Show your topsites">

topsites -> top sites, right?
Attachment #8578967 - Flags: review?(adw) → review+
Comment on attachment 8578967 [details] [diff] [review]
v1: Allow users to turn off all tiles that aren't history tiles

Review of attachment 8578967 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/newtab/newTab.xul
@@ -44,3 @@
>      </xul:hbox>
>      <xul:hbox id="newtab-customize-blank" class="newtab-customize-panel-item">
> -      <xul:label>&newtab.customize.blank;</xul:label>

Can we remove these old strings now?
New strings for the menu:

Show suggested and your top sites
Show your top sites (yes space)
Show blank page

We should be able to remove the strings
https://hg.mozilla.org/mozilla-central/rev/75d6a950bf41
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
Iteration: --- → 39.2 - 23 Mar
Flags: qe-verify?
Flags: qe-verify? → qe-verify+
QA Contact: cornel.ionce
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Mozilla/5.0 (X11; Linux i686; rv:39.0) Gecko/20100101 Firefox/39.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:39.0) Gecko/20100101 Firefox/39.0

Confirming that the new strings for the menu are now:
Show suggested and your top sites
Show your top sites (yes space)
Show blank page

Tested on Windows 7 64-bit, Ubuntu 14.04 32-bit and Mac OS X 10.9.5 using latest Nightly, build ID: 20150323030203.
Status: RESOLVED → VERIFIED
(In reply to Ed Lee :Mardak from comment #20)
> Created attachment 8579707 [details]
> Potential subitem checkbox
> 
> Do we want to have two different check marks? Where the subcheck has the
> empty [] when unchecked while the top level check is just blank when
> unchecked?

I think the checkmarks are fine with the latest revision from Aaron (the one shown here), even with the different styles of boxes.
One thing we should do in the near future (doesn't need to block shipping) is to either dim and disable the nested checkbox when another top-level item is selected, or hide it altogether in that case.

Tangentially related: I filed one other bug (bug 1148355) about a stylistic issue where the non-selected items of that menu look like they can't be selected.

> I suppose an alternative would be to allow and default to both "show
> suggested sites" and "show top sites" checked. (This makes the two menu
> items true checkboxes as opposed to radio item with checkmarks.)
I'm not sure if I understand you correctly here: »Show suggested sites« can't be checked when »Show top sites« isn't checked, right?
Comment on attachment 8579707 [details]
Potential subitem checkbox

Forgot to set the review flag: r+ for the checkbox.
As I mentioned there are other minor issues in this mockup, but those can be dealt with in their respective bugs (bug 1148355 for the gray menu items and bug 1132552 comment 8 for the question around page dimming)
Attachment #8579707 - Flags: ui-review?(philipp) → ui-review+
Blocks: 1148859
Also confirming the fix for Firefox 38 beta 2, build ID: 20150406174117

Tested on Windows 7 64-bit, Windows 8.1 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit
Blocks: 1155443
No longer blocks: 1155443
Depends on: 1167616
No longer depends on: 1167616
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: