975213 - Decide behavior of user removing/dragging Top/Sponsored Tiles

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Jennifer Morrow [:Boriss] (UX)]

The first iteration (Directory Tiles v1) of the Tiles project is intended to demonstrate a type of tile users will see (Directory Tile) and begin the process of gathering CTR and Impressions performance data on tile usage to determine if there exists value both for our users and partners.  Sponsored Tiles, which are paid to be include in the Tile Grid, are sourced from partners.

Specifying the behavior of the Grid will mean defining the exact behavior Tiles, pinned and unpinned, Sponsored and Top.  In v1, this particularly means defining tile display behavior when users delete tiles on first run.

Comment 1

[Ed Lee :Mardak]

I believe the main consideration is the behavior in situation like..

#1 History 1, #2 Top 1,     #3 Top 2
#4 Top 3,     #5 Sponsor 1, #6 Sponsor 2
#7 Sponsor 3, #8 Sponsor 4, #9 Sponsor 5

If the user removes item #4 Top 3, is there
- a "Top 4" that would shift info #4 in assuming extra backfill for Top
- a "Sponsor 6" that would shift into #9 with the rest of Sponsor shifting up 1
- a "History 2" that would shift into #9 assuming extra backfill for History

For the last one, is it okay for History to appear after the Top/Sponsor Tiles?

Comment 3

[John Hesling [:John99] (NeedInfo me)]

At any time including immediately after First run:

Will a user still be able to pin any bookmarked item in the place of a top or sponsor tile?
Will that newly pinned bookmark tile then remain in the position it is pinned in,
 without the original Top or Sponsor tile reappearing. 
The user would not expect choices to be overridden or be  prevented.

Comment 4

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Ed Lee :Mardak from comment #1)
> I believe the main consideration is the behavior in situation like..
> 
> #1 History 1, #2 Top 1,     #3 Top 2
> #4 Top 3,     #5 Sponsor 1, #6 Sponsor 2
> #7 Sponsor 3, #8 Sponsor 4, #9 Sponsor 5

Because the exact number of Top and Sponsored Tiles we have will rely on partner discussions, let’s take a few different cases into consideration.

Note: “Top” Tiles are selected by Mozilla because of their value for users and the Mozilla mission, but there’s likely no financial partnership with them.  Sponsored Tiles are selected by Mozilla out of partner arrangements.  For the purposes of this bug, they’re functionally equivalent, since they’re displayed the same way.  So, I’ll just refer to:

   a.  Top Tiles: meaning Mozilla-picked sites (“sponsored” and not)
   b.  History Tiles: based on organic user browsing (3 visits = now a potential History Tile)
   c.  Backlog: Top Tiles and History Tiles that are not currently visible in the Grid

Two changes would be made via tiles:

1. On first run, users will see 9 Tiles.  If the user removes one, they will see that same tile that they removed replaced with a Tile from the Backlog.  

This is in contrast to our current system of shifting all of the tiles on a removal, which causes a visually noisy UI “jump.”

2. A site should not be made a History Tile until the user has been there on 3 separate occasions.  This fixes a current issue in which a user’s first browsing task in a fresh profile fills up the Tiles immediately with that task (this problem: http://cl.ly/image/1T1d3P1J272I)

If a user first opens Firefox and, before visiting any site at least three times, begins removing tile after tile, we replace that tile with the next Tile in the Backlog.  Once we’re out of backlog and/or History Tiles, blank tabs will be shown.

To Ed’s excellent questions:

(In reply to Ed Lee :Mardak from comment #1)
> If the user removes item #4 Top 3, is there
> - a "Top 4" that would shift info #4 in assuming extra backfill for Top

Yes, if we have one.  And if the user removes that Tile, #5 shifts into its place, etc.  Blank tiles show when the backlog has been exhausted.  There are not certain Tiles that are fixed to certain positions: any Tile removed would display the next in Backlog.

(In reply to Ed Lee :Mardak from comment #1)
- a "Sponsor 6" that would shift into #9 with the rest of Sponsor shifting up 1

The next site would shift into the Tile the user has removed, rather than shifting the grid.  In other words, no matter what the next Tile in the Backlog is, it will appear in the spot a user removes a visible Tile.

(In reply to Ed Lee :Mardak from comment #1)
> - a "History 2" that would shift into #9 assuming extra backfill for History

For Directory Tiles, no Tiles are “sticky,” and all are replaced by History Tiles as the user browses.  So, without the user interacting with New Tab at all, any site they visit on three separate occasions is a History Site and has precedence over any preexisting Top Tile.  The grid would fill in as before (though with the caveat that sites are only “History Tiles” if they’ve been visited three times), starting with the top left (#1) tile being replaced with the first History Tile” the user produces.

As the user builds up History, any Top Tile Backlog we may have gets pushed to the “end of the list.”  

As an example, let’s say a user begins a new profile with 9 visible Top Tiles and 3 Top Tiles in Backlog.  If they immediately remove Tile #4, they’d see the next Backlogged Tile in that spot.  If they they begin browsing and, organically, create 10 History Tiles, 9 would display in the Grid and the first item of Backlog would be the 10th History Tile.  The 11th item of Backlog would be the first Top Site (that they have never removed).

Pinned tabs don't move from their position unless the user removes it.  Then it would be replaced with the next item in Backlog, as any other tab would be.

We will likely try a version of Tile in which some are “sticky.”  While not in this version, the behavior should essentially be the same as above but with the caveat that Sticky tiles don’t move, but the other Tiles do around it (stone-in-a-stream style).

I’m going to mark this bug as closed, since this answers the original question.  But, that’s a lot of information and assume that some may be unclear.  I’ll keep checking this bug, so please feel free to ask questions & give feedback.

Comment 5

[Ed Lee :Mardak]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #4)
> 1. On first run, users will see 9 Tiles.  If the user removes one, they will
> see that same tile that they removed replaced with a Tile from the Backlog.  
> 
> This is in contrast to our current system of shifting all of the tiles on a
> removal, which causes a visually noisy UI “jump.”
Boriss, which part are we trying to avoid? The animation of tiles shifting around or that so many tiles get their positions changed?

If it's just the immediate shifting around, would it be okay if the new tile that appeared be placed in a different position next time newtab is opened? I.e., the new tile that appeared in say spot #3 would then be in spot #9 on next new tab with the other tabs filling in from #3-8?

What you described is technically a bit tricky because the current implementation has some ordering based on frecency and what you described will cause something with low frecency to jump ahead of other items with higher frecency without actually pinning the site to that spot.

ttaubert, do you remember the decisions behind having this type of shifting around functionality in the first place?

Comment 6

[Ed Lee :Mardak]

(In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #4)
> 2. A site should not be made a History Tile until the user has been there on
> 3 separate occasions.  This fixes a current issue in which a user’s first
> browsing task in a fresh profile fills up the Tiles immediately
The current patches treat Directory Tiles as 1000 frecency, so on a new profile, the immediate browsing would not show up anyway as they're further behind in the backlog compared to Directory Tiles. Theoretically as the patches are now, if the user removes all the Directory Tiles, s/he'll see those random immediate browsing pages.

I suppose there's a decision of is it better to show blank than those pages if the user went through the effort of removing so many tiles.

> If a user first opens Firefox and, before visiting any site at least three
> times, begins removing tile after tile, we replace that tile with the next
> Tile in the Backlog.  Once we’re out of backlog and/or History Tiles, blank
> tabs will be shown.
So this mean if the user keeps removing tile #1, eventually that first tile will be blank?

> (In reply to Ed Lee :Mardak from comment #1)
> > - a "History 2" that would shift into #9 assuming extra backfill for History
> For Directory Tiles, no Tiles are “sticky,” and all are replaced by History
> Tiles as the user browses.
When you say 'no Tiles are "sticky"' that's referring to just Directory Tiles (i.e., top/sponsored - not history). And how is the not-sticky different from other history pages that shift off as other pages get higher frecency?

Comment 7

[Jennifer Morrow [:Boriss] (UX)]

(In reply to Ed Lee :Mardak from comment #5)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #4)
> > 1. On first run, users will see 9 Tiles.  If the user removes one, they will
> > see that same tile that they removed replaced with a Tile from the Backlog.  
> > 
> > This is in contrast to our current system of shifting all of the tiles on a
> > removal, which causes a visually noisy UI “jump.”
> Boriss, which part are we trying to avoid? The animation of tiles shifting
> around or that so many tiles get their positions changed?

Both.  Mostly the animation - the idea that a tile changed in place rather than "pulled in," disrupting the set, is preferable.

> If it's just the immediate shifting around, would it be okay if the new tile
> that appeared be placed in a different position next time newtab is opened?
> I.e., the new tile that appeared in say spot #3 would then be in spot #9 on
> next new tab with the other tabs filling in from #3-8?

You'd still need a spot filled in the tile just removed, though, so I'm not sure how you're getting around this problem.

> What you described is technically a bit tricky because the current
> implementation has some ordering based on frecency and what you described
> will cause something with low frecency to jump ahead of other items with
> higher frecency without actually pinning the site to that spot.
> 
> ttaubert, do you remember the decisions behind having this type of shifting
> around functionality in the first place?

If this is too hard for this iteration, not a big deal to push it to later.

(In reply to Ed Lee :Mardak from comment #6)
> (In reply to Jennifer Morrow [:Boriss] (Firefox UX) from comment #4)
> > 2. A site should not be made a History Tile until the user has been there on
> > 3 separate occasions.  This fixes a current issue in which a user’s first
> > browsing task in a fresh profile fills up the Tiles immediately
> The current patches treat Directory Tiles as 1000 frecency, so on a new
> profile, the immediate browsing would not show up anyway as they're further
> behind in the backlog compared to Directory Tiles. Theoretically as the
> patches are now, if the user removes all the Directory Tiles, s/he'll see
> those random immediate browsing pages.
> 
> I suppose there's a decision of is it better to show blank than those pages
> if the user went through the effort of removing so many tiles.

That's a good point!  But, I think we can safely fill them in.  Eventually, we either need to 1. fill in tiles or 2. leave them blank in perpetuity or 3. pick some arbitrary future point to fill them in.  Not sure how 3 is really better than 1, and 2 is pretty useless.  Unless you're... really into rectangles.

> > If a user first opens Firefox and, before visiting any site at least three
> > times, begins removing tile after tile, we replace that tile with the next
> > Tile in the Backlog.  Once we’re out of backlog and/or History Tiles, blank
> > tabs will be shown.
> So this mean if the user keeps removing tile #1, eventually that first tile
> will be blank?

Yep!  Or, until there's a Backlog Tile available again.

> > (In reply to Ed Lee :Mardak from comment #1)
> > > - a "History 2" that would shift into #9 assuming extra backfill for History
> > For Directory Tiles, no Tiles are “sticky,” and all are replaced by History
> > Tiles as the user browses.
> When you say 'no Tiles are "sticky"' that's referring to just Directory
> Tiles (i.e., top/sponsored - not history). And how is the not-sticky
> different from other history pages that shift off as other pages get higher
> frecency?

The Directory and Other tile would have just the same level of stickiness.  eg, they all behave like the tiles today do, shifting off with lower frequency.  The difference in Directory Tiles is that there isn't much frequency there to begin with.

Comment 8

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Ed Lee :Mardak from comment #5)
> ttaubert, do you remember the decisions behind having this type of shifting
> around functionality in the first place?

No, AFAICT there was no explicit decision. I went forward and implemented that and UX didn't dislike it I guess :)