Closed
Bug 707611
Opened 13 years ago
Closed 12 years ago
Reduce the effect of visit count in autocomplete scoring
Categories
(Camino Graveyard :: Location Bar & Autocomplete, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: stuart.morgan+bugzilla, Assigned: stuart.morgan+bugzilla)
Details
(Whiteboard: [camino-2.1.1])
Attachments
(1 file)
2.33 KB,
patch
|
alqahira
:
review+
|
Details | Diff | Splinter Review |
Based on feedback it seems like we're giving too much weight to old bookmarks people don't care about any more. This patch does a few things: - Changes the base relevance score from 'visit count' to 'sqrt(visit count)'. I probably should have done that originally; incremental value of subsequent visits after a reasonably large N is obviously not linear (e.g., a bookmark visited 400 times is not 2x more relevant than one visited 200 times). This should make the age-bucket multiplier much more effective. - Dials up the age multiplier. Moves 0.1 from 1 year to 6 months; changes 1 year to 0.01. - Caps results older than 6 months to a base score of 1. That will guarantee that even if you visited some bookmarked site thousands of times, but then stopped using it and left it in your bookmarks, it won't dominate. I don't have a good way to test this, so I'm thinking we should either make a test build to distribute, or just land this and have people try nightlies. I'm leaning toward the latter. Thoughts?
Attachment #579002 -
Flags: review?(alqahira)
I'll look at this tomorrow; off-hand it seems reasonable. Based on some of the forum reports, though, it seems like at least some of the people getting bit by this lost large chunks of history in the 2.0.9->2.1 update :/ (Not saying we shouldn't do this, just that there do seem to be other factors involved in skewing results, too.)
Comment on attachment 579002 [details] [diff] [review] Scoring tweaks >+static const NSTimeInterval kSecondsInSixMonths = 60 * 60 * 24 * 182; If half of 365 is 182.5 and half of 366 is 183, why 182 here; I figured it'd be rounded up? That's really a question, though, not an objection. I agree these changes seem to be the right thing to do, and they seem to me like they're correctly implemented. I was able to confirm, via side-by-side tests, that some formerly-frequently-visited bookmarks that haven't been visited in several months did decline in rank slightly (e.g., a bookmark with 21K visits not visited since April dropped 1 place) and then return to original rank with a recent visit. However, I also saw some rarely visited bookmarks without recent visits jump into the list in a couple of cases; I suspect the interaction between the ranking and the source limit and everyone's bookmark/history set is going to produce a few weird results in some cases, but I'm not sure there's anything we can do about it. So r=ardissone
Attachment #579002 -
Flags: review?(alqahira) → review+
Stuart, are you planning on landing this soon? Should I land it for you?
Assignee | ||
Comment 4•12 years ago
|
||
Not sure when I'll have time; feel free to land it for me.
(In reply to Stuart Morgan from comment #4) > Not sure when I'll have time; feel free to land it for me. http://hg.mozilla.org/camino/rev/dc93af9a722b
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [camino-2.1.1]
You need to log in
before you can comment on or make changes to this bug.
Description
•