276632 - make autocomplete be more like google suggest (make it most popular results come first)

Status: VERIFIED FIXED

(MailNews Core :: Address Book, enhancement)

Description

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

make autocomplete be more like google suggest (make it most popular results come
first)

here's what I mean:

right now, when I type: "e", I get a bunch of results.  The first <n> aren't
people I send mail to frequently.  The person I send mail to all the time is way
down, so I usually have to keep typing to get to that email address.

let's add an int field to ab card interface and increment it each time the user
sends mail (to,cc,bcc) to that address.

then, when doing AC, when looking at the results, let's sort by that value.

Comment 1

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

adding url to google suggest

Comment 2

[Scott MacGregor]

seems pretty easy for someone to jump in and make this happen...

Comment 3

[John McCormick]

I'd like to add a suggestion:

Who I e-mail tends to change over time. It might be better to base the sort on
recent data, so addresses to which I _used_ to e-mail all the time don't hang
around in the autocomplete area for years after they become invalid.

On the other hand, that significantly increases the complexity of
implementation, doesn't it? Either implementation would be useful :)

Comment 4

[Luca M.]

I agree.

There's another bug:

when you write in To: one address, then write ',' and a letter, the popup
doesn't appear...

i.e.:

[e-mail],b

it should show a popup with all emails begginning with 'b'

Comment 5

[Wayne Mery (:wsmwk)]

related Bug 208833 (Sort address completion list by most recent use).
depending on how these develop, a blocker or complementary improvement?

Comment 6

[Scott MacGregor]

Attachment: first cut at a fix

This patch is a first cut at sorting address book autocomplete results based on
popularity (i.e. how often you send e-mail to the address).

1) Adds a data base property for a popularity index
2) Adds a nsIAbCard property for a popularity index
3) When performing address book auto complete, sort matches of the same type
(i.e. name exact match results, email exact match results, name matches, email
matches, etc.) by popularity. The old code sorted results for each match type
by domain name if they matched the default domain. 
4) Remove obsolete domain match type code from the address book autocompletion
code now that we are inserting based on popularity.
5) Adds code to mail compose to bump the popularity index on send for each
outgoing recipient. I'm most concerned about this change because it causes us
to call EditCardToDatabase for each recipient on send. Is that going to cause
us to force commit the database?

I need to make us bump the popularity index on mailing lists too before this
patch is really done. 

Also, this patch leave LDAP autocomplete alone and has no impact on how LDAP
results are presented to the user.

Comment 7

[David :Bienvenu]

Comment on attachment 196881 [details] [diff] [review]
first cut at a fix

very cool.

Comment 8

[Scott MacGregor]

Attachment: updated fix that is more db friendly

only commits each address book once instead of after updating the popularity
count on each address book recipient.

the rest of the patch is unchanged.

carrying forward david's sr.

Comment 9

[Scott MacGregor]

I've checked this into the trunk so we can start getting feedback on it.

Comment 10

[Scott MacGregor]

Attachment: [patch checked in]additional fix

I forgot to actually push the address book card change back to the database
before the db got committed.

I also removed a useless null ptr check since the code bails out earlier if the
address book database object is null.

Comment 11

[[e-mail]]

Comment on attachment 197117 [details] [diff] [review]
updated fix that is more db friendly

"fo" :-P
>+        // find the start fo the search results for our particular
>+        // match type and then insert into that group of results 
>+        // sorted by the popularity index
>+        while (i < type)
>+          insertPosition += mMatchTypeCounters[i++];
>+
>+        while (insertPosition < nbrOfItems)
This might code slightly neater as a for loop, also using the known number of
matching type saves having to test for the type:
PRInt32 lastPosition = insertPosition + mMatchTypeCounters[i];
for (; insertPosition < lastPosition; insertPosition++) {
  ...
  if (aPopularityIndex > param->mPopularityIndex)
    break;
}

Comment 12

[Scott MacGregor]

I wonder if we should get rid of all of the match types:

http://lxr.mozilla.org/mozilla/source/mailnews/addrbook/src/nsAbAutoCompleteSession.h#87

with maybe the exception of nick name matches, so those always appear at the top
of the list. Let all of the other results get sorted together by popularity,
regardless of the match type.

Comment 13

[Scott MacGregor]

Attachment: [patch checked in]remove notion of match types, sort entire list by popularity

Seth and I were chatting some more about this and we think it makes sense to
use the popularity index across all the match types. No more distinguishing
auto complete results based on e-mail vs. nick name vs. display name matches.
Just sort the entire list based on the popularity index for each match.

This patch removes all of the match type information. A couple places still
needed to care about whether the match was a default domain / default match so
I still pass that information around.

I also turned on the old code for appending a default domain to ensure that the
default domain item is still the first item in the list when you turn that
feature on.

Now all matches are sorted based on popularity. Items with the same popularity
index are sorted alphabetically. 

LDAP matches appear at the end of the list like they did before.

Comment 14

[Scott MacGregor]

Attachment: [patch checked in] handle duplicate address book entries

This patch handles a case Seth was seeing where you have multiple entries in
your address book with the same e-mail address. It ensures that we use the
match that has the highest popularity index, thus ensuring that the e-mail
address appears as high as possible in the autocomplete results list.

Comment 15

[Scott MacGregor]

I've put this on the 1.8 branch too. This has no effect on Firefox at all.

a=me/bienvenu/sspitzer

Comment 16

[David :Bienvenu]

*** Bug 279640 has been marked as a duplicate of this bug. ***

Comment 17

[plop]

(In reply to comment #16)
> *** Bug 279640 has been marked as a duplicate of this bug. ***

let re-write what have beeb said in bug 279640:

(In reply to comment #3)
> in 1.5beta 2, we sort by frequency of use, so the addresses you send to more
> often will be higher in the list

(In reply to comment #4)
> note that I used to mail a friend about 400 to 500 times in 6 months, 2 years
> ago, and no more now.
> 
> What happens if I write to people let say once a week for 1 year from now ?
> 
> that far less than the 500 for the first one; still, I expect to get the latter
> address ...
> 
> volum reflects frequency, you you should average that only on ... let say the
> last 6 onths ...

Comment 19

[Pedro Pedruzzi]

It looks like this feature is broken or missing in thunderbird 3.0.

Could someone confirm this?

Comment 20

[plop]

Yes, and fixed in the meanwhile: bug 497722