673907 - sync pushes mobile history out of the history UI, making it useless

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Dietrich Ayala (:dietrich)]

When I try to find a URL I know I had just recently browsed on my phone an hour ago, I'm unable to because sync has quickly and efficiently already added the 359 URLs from my desktop browsing session just now. Many of these are Gmail URLs, so not only is my mobile history pushed into unfindability, but the entries that are there are unreadable.

Should the history UI show mobile history first? Or weight it higher when on phone?

I don't know what the answer is. But sync makes the current implementation useless when trying to find that URL you know you just browsed to on the device.

Comment 1

[Tony Chung [:tchung]]

Cc'ing services dev team.   is this a sync backend fix, or fennec should handle frecency of history requests?

Comment 2

[Richard Newman [:rnewman]]

Sync doesn't differentiate between mobile and desktop history at all, and arguably should not. You could just as easily switch "mobile/phone" and "desktop" in your description.

I could imagine a "this device only" history store, or have the mobile device play some tricks to make its history items more important... but there would be implementation annoyances, and it's certainly not a feature of Sync.

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Should this be in Toolkit:Places?

Comment 4

[Richard Newman [:rnewman]]

(In reply to comment #3)
> Should this be in Toolkit:Places?

It's a UX decision first and foremost. Any resulting work item would probably land in the Places queue first.

Comment 5

[Dietrich Ayala (:dietrich)]

Yep, rnewman is correct - we need Mobile UX design work here first. This is a Fennec bug.

Any Places (or whatever else) changes that need to be made for implementing the design should be filed as bugs against those components.

Comment 6

[Steve Fink [:sfink] [:s:]]

(In reply to Richard Newman [:rnewman] from comment #2)
> Sync doesn't differentiate between mobile and desktop history at all, and
> arguably should not. You could just as easily switch "mobile/phone" and
> "desktop" in your description.

I certainly visit a different set of URLs on my phone than I do on my desktop, so I think a distinction is reasonable. But that may not be specific to mobile.

> I could imagine a "this device only" history store, or have the mobile
> device play some tricks to make its history items more important... but
> there would be implementation annoyances, and it's certainly not a feature
> of Sync.

Yes, this. The probability of wanting a past URL from the same device is far greater in my usage than a tab from a different device. The weight of that distinction varies, though -- my tablet URLs are much closer to my desktop URLs than my phone URLs.

I'm sure this is the wrong place for a design discussion, but my preference would be to make each device have its own tab group. I'll ignore multiple tab groups per device, since I don't find them useful currently. Frecency should conceptually weight each tab group independently and learn over time what the relative weights should be for a given device. (So weights are pairwise -- they're a function of the device I'm using and the device I'm pulling from. Or maybe s/device/tab group/g.) But I think I also want the weights to decay within each tab group -- or said otherwise, when I start typing a URL, I want to see a couple of good matches from my local device history, a couple of good matches from a "similar" device history, but still see one or two from a "dissimilar" device history.

So my tablet would figure out that my desktop history is about as good as the tablet's history, but my really frequently used phone history items are fair game too as long as you don't show too many.

And I could override it to have multiple devices share a single tab group, which is similar to giving them maximum pairwise affinity except you don't show as many from that group as you would if they were separate groups. This is the current behavior, and I think it's appropriate for some devices. (Though perhaps this could be folded into the formula somehow, I dunno.)

Finally, I'd like the resulting formula branded into the side of a pony that is delivered to the front door of my choosing.

Comment 7

[Philipp von Weitershausen [:philikon]]

(In reply to Steve Fink [:sfink] from comment #6)
> (In reply to Richard Newman [:rnewman] from comment #2)
> > Sync doesn't differentiate between mobile and desktop history at all, and
> > arguably should not. You could just as easily switch "mobile/phone" and
> > "desktop" in your description.
> 
> I certainly visit a different set of URLs on my phone than I do on my
> desktop, so I think a distinction is reasonable. But that may not be
> specific to mobile.

Does a tablet count as a mobile device because it's running Fennec, or as a desktop device because it's nearly the size of a netbook? I personally have no good answer for this question, mostly because from my personal experience it doesn't matter. It's the web and I use it roughly the same everywhere I am.

So really the point is: I don't think anecdotal evidence is going to get us far. We're all power users who understand the technical details far too well. The question becomes which product do we want to build for our users? For Sync, we have unapologetically chosen the "we make all your devices the same" route because that's the kind of experience that seems most compelling to us. As it turns out, that's also the experience that others are building with great success.

> I'm sure this is the wrong place for a design discussion,

Indeed it is.

> but my preference would be to make each device have its own tab group.

In the short term, this is what we may be doing. Though I suggest you pick UX's brain on this idea. The argument that they make is: it turns out, people don't stop doing personal stuff at work or work stuff at home. Or even on the road or in the coffee shop.

> Finally, I'd like the resulting formula branded into the side of a pony that
> is delivered to the front door of my choosing.

RESO/INCO for not providing an address.

Comment 8

[Steve Fink [:sfink] [:s:]]

(In reply to Philipp von Weitershausen [:philikon] from comment #7)
> (In reply to Steve Fink [:sfink] from comment #6)
> > (In reply to Richard Newman [:rnewman] from comment #2)
> > > Sync doesn't differentiate between mobile and desktop history at all, and
> > > arguably should not. You could just as easily switch "mobile/phone" and
> > > "desktop" in your description.
> > 
> > I certainly visit a different set of URLs on my phone than I do on my
> > desktop, so I think a distinction is reasonable. But that may not be
> > specific to mobile.
> 
> Does a tablet count as a mobile device because it's running Fennec, or as a
> desktop device because it's nearly the size of a netbook? I personally have
> no good answer for this question, mostly because from my personal experience
> it doesn't matter. It's the web and I use it roughly the same everywhere I
> am.

Which is why my proposal does not make use of form factor or Fennec vs desktop, and instead learns from the actual usage patterns.

> So really the point is: I don't think anecdotal evidence is going to get us
> far. We're all power users who understand the technical details far too
> well. The question becomes which product do we want to build for our users?
> For Sync, we have unapologetically chosen the "we make all your devices the
> same" route because that's the kind of experience that seems most compelling
> to us. As it turns out, that's also the experience that others are building
> with great success.

With respect to bookmarks, that seems to be what Sync does. But tabs? My phone is showing me just the last tabs I had opened on my phone, not my 200+ desktop tabs, for which I am grateful. (I understand that this has little to do with Sync's data model.)

I'm really only talking about the frecency calculation and the UX. Sync might need to label tabs with what devices/tab groups they have been used on -- a bit vector per tab, plus global incrementing tab group IDs? -- but that's speculation until the UX is decided.

> > I'm sure this is the wrong place for a design discussion,
> 
> Indeed it is.

Where is the right place?

> > but my preference would be to make each device have its own tab group.
> 
> In the short term, this is what we may be doing. Though I suggest you pick
> UX's brain on this idea. The argument that they make is: it turns out,
> people don't stop doing personal stuff at work or work stuff at home. Or
> even on the road or in the coffee shop.

I can buy that. But that still doesn't mean that my desktop tabs should have equal weighting and therefore swamp my frecency results when I pull out my phone. We're leaving valuable independent variables on the table, so to speak.

> > Finally, I'd like the resulting formula branded into the side of a pony that
> > is delivered to the front door of my choosing.
> 
> RESO/INCO for not providing an address.

If the pony is so crappy that it can't get the address telepathically and use a friggin' GPS, then I don't want it anyway.

Comment 9

[Matt Brubeck (:mbrubeck)]

I don't know why, but in my experience, frecency does get affected more by on-device use than by synced data.  On several devices I've been using for a while, synced to the same account, different URLs are at the top of the awesomescreen on each device, and they are the URLs that I've used most on that specific device.

So basically, this WORKSFORME once I've spent a while using a device.

Comment 10

[Richard Newman [:rnewman]]

(In reply to Matt Brubeck (:mbrubeck) from comment #9)

> So basically, this WORKSFORME once I've spent a while using a device.

We include frecency data in records that we sync, but we don't actually apply that data. That means that your browsing behavior on the device is what shapes the awesomescreen.

Probably originally a bug, but I kinda regard it as a feature!

Comment 11

[BMO Automation]

Closing all opened bug in a graveyard component