395446 - if the user chooses a result from autocomplete results, or types it manually, have that weigh heavily in ranking ac results

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[(not reading, please use [e-mail] instead)]

if the user chooses a result from autocomplete, have that weigh heavily in ranking ac results.

not we have a bug on typed weighing more already, which would be easiy to fix and good to do for m8.

<mconnor> btw, you mentioned poor man's quicksilver
<mconnor> I have an idea there
<mconnor> when we get around to frecency ratings calculated at load time, we should make stuff picked out of the autocomplete jump the rating a lot
<mconnor> so if I keep picking foo.com out of the autocomplete results, I should get that high in the list for anything matching
<mconnor> which is kinda/sorta how quicksilver learns
<mconnor> though it remembers "fo" == "foo.com" rather than just making foo.com rate higher for anything matching
<sspitzerMsgMe> there is a bug about using "typed" as the high order bit, and i need to see if we set visits at typed when we click on them ac results.
<sspitzerMsgMe> say we do (or we don't), we could have that as a transition type
<sspitzerMsgMe> and make those weigh more
<sspitzerMsgMe> typed or chosen

Comment 1

[(not reading, please use [e-mail] instead)]

I'd like to slip this into m8, if possible.

Comment 2

[(not reading, please use [e-mail] instead)]

for the typed transition affecting ac results, see bug #394066

Comment 3

[(not reading, please use [e-mail] instead)]

I lucked out, selecting items from the url bar ac list is already TRANSITION_TYPED!

so, if I fix bug #394066, we get this fix too.  working on bug #394066 now.

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: weigh typed searches above non-typed searches

but note, within a chunk of time, if two searches are both typed in, we defer to visit count (and then max visit date).

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: prefer typed, then bookmarked, then a clicked link, with ties broken by visit count (then visit date)

Comment 6

[Dietrich Ayala (:dietrich)]

Comment on attachment 280151 [details] [diff] [review]
prefer typed, then bookmarked, then a clicked link, with ties broken by visit count (then visit date)

technically, the change looks fine, r=me.

however, i'm a little worried about putting the bookmark part in a release without nightly tester feedback on it's efficacy. this fix is ordering, not really "weighting" (ie: different types are grouped, not interspersed based on external criteria). this is a concern in the case of bookmarks: in my personal use i use location bar autocomplete to find places i've been to *recently*, not to find items i've saved. after this change, an untyped history entry that i've been to this morning will be below all bookmarks that match my search. as users start bookmarking more (due to starring, tagging etc), bookmarks may overwhelm the results.

OTOH, putting this in a release will provide a much larger sounding board, so we'd likely get richer feedback than from the nightly tester group.

Comment 7

[(not reading, please use [e-mail] instead)]

dietrich, you bring up a good point about bookmarks, and locally, I'm seeing what you are worried about.

let me attach a patch that just does typed and I'll save the bookmark weighting (and not ordering) to bug #394066

Comment 8

[:Gavin Sharp [email: [e-mail]]]

See also bug 370117: it has a patch that makes us keep a record of how many times a form history autocomplete entries are used, so that we can sort them by frequency of use in the dropdown. That patch implements a formhistory-specific API, but we could instead modify nsIAutocompleteResult to enable the autocompletecontroller to notify the nsIAutocompleteSearch implementations of a selected result, and have it record that data and take it into account when it performs searches.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

><mconnor> which is kinda/sorta how quicksilver learns
><mconnor> though it remembers "fo" == "foo.com" rather than just making foo.com
>rate higher for anything matching

I think we should seriously consider this type of adaptive learning.  Another difference is that the first match in Quicksilver is set as the default action on enter (like Safari).

>after this change, an untyped history entry that i've
>been to this morning will be below all bookmarks that match my search. as users
>start bookmarking more (due to starring, tagging etc), bookmarks may overwhelm
>the results.

Or, this will cause users to be careful what they bookmark, which works against everything we've tried to do to make bookmarking easy.

I think we should always display bookmarked results, but they shouldn't be given precedence in the ranking.

Comment 10

[(not reading, please use [e-mail] instead)]

fixed.

Checking in nsNavHistoryAutoComplete.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistoryAutoComplete.cpp,v  <
--  nsNavHistoryAutoComplete.cpp
new revision: 1.22; previous revision: 1.21
done

note, I am not giving any extra preference to bookmarked items.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

I think we should consider the full quicksilver style approach as one of our 5 delight items.

Comment 12

[Dietrich Ayala (:dietrich)]

(In reply to comment #11)
> I think we should consider the full quicksilver style approach as one of our 5
> delight items.
> 

alex, that'd be *very* cool. as this bug is closed, can you file a new bug, clearly spec'ing out the behavior?

Comment 13

[(not reading, please use [e-mail] instead)]

> can you file a new bug,

alex logged bug #395735

Comment 14

[(not reading, please use [e-mail] instead)]

> alex logged bug #395735

oops, sorry, that is something else.  I'll log the bug.

Comment 15

[(not reading, please use [e-mail] instead)]

> I'll log the bug.

see bug #395739