1114751 - address autocomplete should favor matches in personal address book

Status: NEW

(Thunderbird :: Message Compose Window, enhancement)

Description

[Humphrey P van Polanen Petel]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

initiated a new email
typed the name of one my contacts



Actual results:

the first address on the drop down list came from <collected addresses>
the second address came from <personal address book>


Expected results:

the address from <collected addresses> should not have been there

note

<collected addresses> is a fall back for when there is no match in <personal address book>

Comment 1

[Wayne Mery (:wsmwk)]

There may already be a report about favoring or designating certain ABs. 
So farthat's not a direction we've taken.
Thomas knows the buugs better than me

Comment 2

[R. Lynn Rardin]

I believe the behavior described by Humphrey was introduced in Thunderbird 31.4.0 and I assume that this is a bug.  When multiple matches were found as an address was being entered and autocompleted in the To: field, previous versions of Thunderbird offered the best match from the Personal Address Book as the default selection.  Additional matches from the PAB and Collected Addresses were included in a drop-down list below the default match.  Version 31.4.0 offers a list of matches from the PAB and Collected Addresses, but the ordering of the list seems to be more random and the best match from the PAB is frequently not the default selection at the top of the list.  I thought initially that the list was alphabetical, but that doesn't appear to be the case.

An example:  If I have a PAB entry for a contact with a nickname assigned and enter the nickname exactly in the To: field, the PAB entry with the matching nickname may be in the middle or even at the end of the drop-down list of matching addresses.  There seems to be no rhyme or reason to the ordering of the list.  Matches above the address for the PAB entry may have been introduced to Collected Addresses many years ago by a single message sent or received, while the address associated with the PAB entry has been used hundreds or even thousands of times.

Comment 3

[Thomas D. (:thomas8)]

(In reply to R. Lynn Rardin from comment #2)
> I believe the behavior described by Humphrey was introduced in Thunderbird
> 31.4.0 and I assume that this is a bug.  When multiple matches were found as
> an address was being entered and autocompleted in the To: field, previous
> versions of Thunderbird offered the best match from the Personal Address
> Book as the default selection.

That's not true as described, source AB has never been a factor of sorting afasik, but it might have appeared so for you for *other* reasons.
TB24/Pre-TB31-algorithm was sorting in this order:
- highest popularityIndex across all ABs (LDAP might be exception, don't know)
- then alphabetical (don't remember on what, but probably as shown in dropdown list)
the result set was limited cards matching
- foo bar* (field begins with)

TB31/Pre-TB31.4 algorithm (eliminate search failures, more powerful search):
- *foo* AND *bar* (set of searched field values contains each search word)
- but kept old sorting algorithm
-> might expand the result set (only for short single searchwords)
-> allows rapid reduction of result set (using multiple searchwords)
The unfortunate UX of that was this (especially for very short single search words):
Typing "Jo" might not toplist your favorite "John Doe" IF there are other, more popular matches (higher poupularityIndex), e.g. "Applejoseph" (perhaps 10 years ago you communicated with him frequently, but you had forgotten about him because he never occured in the result set for your particular search patterns; note that same problem can also occur pre-TB31).

TB31.4 keeps the expanded result set, but new sorting algorithm:
- full match of "foo bar" search string at the beginning of field words scores high (so that "Jo" will more easily find contact with e.g. display name "John Doe", or "Doe, John"; and potentially less relevant inner substring matches are downrated)
- then popularity index
- then alphabetical
That's a rough description off my head; for details, see Bug 970456.
For many cases, this should restore the old behaviour when users just typed from beginning of names expecting their most popular/used name match to come up.

> Additional matches from the PAB and
> Collected Addresses were included in a drop-down list below the default
> match.  Version 31.4.0 offers a list of matches from the PAB and Collected
> Addresses, but the ordering of the list seems to be more random and the best
> match from the PAB is frequently not the default selection at the top of the
> list.

Again, PAB has never been a factor, and will not be the best choice for everyone. It's very hard to guess what your best match really is, because it differs across users / scenarios / use patterns. Further improvements have been suggested (autocomplete frecency Bug 382415, similar to FF awesome bar), but are hard to implement with the little manpower we have.

> I thought initially that the list was alphabetical, but that doesn't
> appear to be the case.
> 
> An example:  If I have a PAB entry for a contact with a nickname assigned
> and enter the nickname exactly in the To: field, the PAB entry with the
> matching nickname may be in the middle or even at the end of the drop-down
> list of matching addresses.

Yes, that's an actual bug, Bug 325458.

> There seems to be no rhyme or reason to the
> ordering of the list.  Matches above the address for the PAB entry may have
> been introduced to Collected Addresses many years ago by a single message
> sent or received, while the address associated with the PAB entry has been
> used hundreds or even thousands of times.

As outlined above, we *do* consider how often you used a contact.
But current popularityIndex design is very poor as it doesn't age nor otherwise ever reduce, so it needs improvement along Bug 382415, Bug 1058583.

Comment 4

[Thomas D. (:thomas8)]

Similar: Bug 220370 Allow user to select which address book(s) to use for autocompletion (implement per-AB pref to include/exclude AB from auto-completing)

There's also Bug 546737 (still unconfirmed): Allow manual adjustment of auto-complete contact order, contacts sidebar order
...but that vague idea has received no interest or support and I doubt it's viable/useful in view of better dynamic (auto-adapting) designs like frecency, or manual prioritization by nickname (after bug 325458).

BTW, to work around nickname bug 325458, just use very unique nickname (not found in any searched field of any other contact), like nickname "jd#" for "John Doe". Works like a charme, 100% of the time.

Comment 5

[Thomas D. (:thomas8)]

Humphrey, Lynn, your input is appreciated, thanks for letting us know.

Looking at comment 0, I think it is filed against TB31.x (pre-TB31.4) and just wants that typing "jo" should bring up "John Doe" like ever before. Notwithstanding further improvements (see my comments above) I think we have fixed that to our best abilities in TB 31.4(!) and it should now work for many everyday popular cases. So I think comment 0 was just jumping to conclusions of suggesting *something* to fix that issue.

I don't buy the idea of this bug that Personal Address book, by default, has the more valuable contacts that should be toplisted; nothing can stop users from starting a new msg to each new contact and rely on TB to collect that after sending into "Collected Addresses", and leave it there. So if anything, this would be a request to allow per-AB weighting for ordering of autocomplete results.

I do NOT see this bug as a well-founded/laid-out conceptual request for introducing per-AB weighting into ordering algorithm of autocomplete results (yet). Anyone who actually wants to pursue that idea would have to spell out in much more detail how that should interact with our current sophisticated sorting algorithm and planned concepts like frecency.

I have some doubts whether AB weighting really helps; imo an option of excluding specific ABs from autocomplete entirely per Bug 220370 would be a more promising approach (and much easier to implement, too...).

So I don't expect much to come out of this bug; but I'm not sure yet if it can be shot down already :)

And yes, ftr, it will never be possible to get it right for everybody and all use cases, but we're trying our best, albeit with limited manpower resources and a large legacy of old bugs.

Comment 6

[R. Lynn Rardin]

Thomas, I appreciate all of the details you took the time to include in comment 3.  I apologize for not realizing how much effort had gone into developing the current sort algorithm.  It surprises me that users don't expect PAB entries that they've taken the time to create to have more weight than the other sources used for address autocompletion, but maybe my use of the PAB is atypical.  Although limited resources probably make this an unlikely outcome, it seems like the addition of a user-configurable AB weighting scheme might be a nice addition to TB's feature set.

Comment 7

[Humphrey P van Polanen Petel]

I have been following this bug for a while and I get the impression that you developers are too close to the code, leading to a mindset where you think you know better than the users.  Mind you, I really do appreciate all the effort you are putting in, but in this case I think you are making things more complicated than necessary.  Please remember the KISS principle.

This is how I think strings should be matched:

First from the *beginning* (the default)
then from anywhere.

The results should be presented with the matches from the beginning first followed by matches from anywhere, which can be overridden by using the wildcard '*'.

Comment 8

[Magnus Melin [:mkmelin]]

That's how it is now. (Except for the wildcard.)

Comment 9

[Humphrey P van Polanen Petel]

True today, but not yesterday when I wrote the comment.

Was there an update I didn't notice?  Current version is 31.4.0

Comment 10

[Wayne Mery (:wsmwk)]

I find myself agreeing with comment 5.  Which is not to say that you don't have a problem that needs attention. But many users have many address books, not just PAB and CAB. And some don't even have CAB.  So if there are entries in your PAB, presumably ones that have previously been used at least once as compared to ones in CAB that have not, then something that needs adjustment - but I suggest not a rather inflexible choice of one AB over another, which also adds further complexity to an increasingly complex autocomplete algorithm.  

(But I do like the idea of Bug 220370.  Which is a corallary to another bug which wants mail accounts that are wanted only as archives and therefore should not check for new mail.)

Comment 11

[Magnus Melin [:mkmelin]]

(In reply to Humphrey P van Polanen Petel from comment #9)
> True today, but not yesterday when I wrote the comment.
> 
> Was there an update I didn't notice?  Current version is 31.4.0

That changed with 31.4.0 yes.

Comment 12

[Wayne Mery (:wsmwk)]

Magnus, on further research this is essentially bug 158728.  Bug 158728 was wontfixed given the rationale of bug 64662 comment 9 and comment 10, i.e. that requests that are not frequency based should be done via add-on.

I leave it to you to decide whether it is feasible to introduce some mechanism to accomodate this request in core, or wontfix it based on the above precident.

Comment 13

[Andrew Martin]

My users have encountered this problem after upgrading to Thunderbird 31.4.0. Now when composing, addresses that they have not sent any mail to in years (but probably were frequently mailed years ago) are appearing at the top of the auto-complete suggestion list, whereas addresses that have been mailed frequently and recently are appearing much farther down the list. Is it possible to make the algorithm take into account how recently the addresses have been emailed when ordering the list?

For example, in addition to popularityIndex create lastMailed which stores the timestamp of the last messages sent to that address. This would allow you to show suggestions ordered on both the popularityIndex and lastMailed time.

Comment 14

[Magnus Melin [:mkmelin]]

It should be pretty easy to accommodate this. The question just is how much impact it should have...

Comment 15

[Andrew Martin]

Ok great, let me know if I can help beta test!

Comment 16

[Thomas D. (:thomas8)]

(In reply to Magnus Melin from comment #14)
> It should be pretty easy to accommodate this. The question just is how much
> impact it should have...

I strongly discourage taking this route in a way that defaults to an inflexible prioritization of entries from any one AB over entries from another. As I described in comment 5 (to which Wayne agreed in comment 10), we have no way of safely predicting which AB is more important for users, much less to assume that contacts from "Personal AB" are necessarily more relevant than contacts from other ABs, because:
- by normal usage (Write new message, type address, send), many (even most) AB entries can actually end up in Collected Addresses, which is no indication whatsoever that they are less relevant for retrieval.
- there might be other user-defined ABs which are more important than all out-of-the box ABs

So I agree with Wayne's proposal to do similar Bug 220370, which adds a lot more value by allowing to exclude certain ABs from the autocomplete lookup. Hence such ABs can be used for a variety of usecases not possible today:
- archival ABs
- ABs containing specific traditional mailing lists whose individuals aren't usually addressed
- ABs that contain contacts that are usually retrieved in groups, e.g. use contacts side bar to search and add the group of contacts "tagged" "TB Core Team" (as a subgroup of all TB volunteers)
- etc.

Imo the only possible way to do this would be to allow the user to define a free order (customizable weighting) of preferred ABs, which I think will add a lot of complexity in code for doubtful value:
- assuming that one AB should permantly be prioritized over another (whilst still in use hence not completely excluded) is conceptually problematic because it will make it harder to get at the entries from less preferred ABs even when they are actually wanted, forcing users to type more and more precise searchwords to exclude the results from preferred ABs.
- an algorithm of cross-AB "frecency" (Bug 382415, perhaps bug 1058583) will have the same effect, but is much more versatile and useful because
  a) instead of blanket, stiff per-AB prioritizations, the focus is on the actual frecency of the individual contact, which might differ from the average frecency/relevance of other entries in same AB and
  b) it allows for dynamic changes to the frecency/relevance of whichever contact or group of contacts: if I start using those contacts from Personal AB more often, they will gradually move to the top with better frecency values; if data distribution or data usage changes, any other contacts from any other AB including Collected Addresses can come to the top (according to their real-life frecency, which will always be more precise than any pre-determined prioritization).
- Adding any pre-prioritization which is not inspired by "frecency" of individual contacts will further undermine/annihilize the our current UX-concept involving popularityIndex its better successor "frecency algorithm". Iow, we can't eat your cake and have it!

Comment 17

[Thomas D. (:thomas8)]

Premature commit, correction of last paragraph of comment 16:

- Adding any invariable pre-prioritization which is not inspired by actual "frecency" of individual contacts will further undermine/annihilate the current UX-concept of dynamic/adaptive prioritization using popularityIndex or its more refined future successor, "frecency algorithm". Iow, we can't eat our cake and have it!

Comment 18

[Thomas D. (:thomas8)]

(In reply to Andrew Martin from comment #13)
> My users have encountered this problem after upgrading to Thunderbird
> 31.4.0. Now when composing, addresses that they have not sent any mail to in
> years (but probably were frequently mailed years ago) are appearing at the
> top of the auto-complete suggestion list, whereas addresses that have been
> mailed frequently and recently are appearing much farther down the list. Is
> it possible to make the algorithm take into account how recently the
> addresses have been emailed when ordering the list?

Comment 13 is unrelated to this bug as it confirms the call for "frecency algorithm" (Bug 382415, perhaps bug 1058583).

> For example, in addition to popularityIndex create lastMailed which stores the timestamp of the last
> messages sent to that address. This would allow you to show suggestions ordered on both the
> popularityIndex and lastMailed time.

That sounds like a sound and simple starting point on the way to "frecency algorithm" (lateron, we should also consider the relation between search input and picking certain results, as in FF awesome bar)!

Comment 19

[Thomas D. (:thomas8)]

My claim that "Collected Addresses" per se cannot safely be assumed to be less relevant than other addresses is further supported by the fact that we've stopped dumping addresses only used to "allow remote content" into Collected Addresses, so that's a legacy artefact issue which will go away over time and is not applicable for new users of TB.

Comment 20

[Thomas D. (:thomas8)]

Comment 0, as correctly predicted in my comment 5, and confirmed by reporter in comment 7, is NOT a specific nor carefully thought-out request to prefer PAB matches over other ABs, but actually seeks to address a regression that we have already fixed: Bug 970456.

(In reply to Humphrey P van Polanen Petel from comment #7)

> This is how I think strings should be matched:
> 
> First from the *beginning* (the default)
> then from anywhere.
> 
> The results should be presented with the matches from the beginning first
> followed by matches from anywhere, which can be overridden by using the
> wildcard '*'.

Per Magnus comment 8, that's exactly the current behaviour (after Bug 970456).
So reporter's issue is actually WFM.

I find it irritating how we spiral into confirming adventurous ideas that have not even been laid out properly, nor examined for applicability, nor actually requested by reporter, and are even starting out from wrong assumptions about current behaviour; and how my detailed caveats against such vague and unfounded propositions are not considered before confirming a bug which already had a wontfix tendency, confirmed by Wayne (both here and historically on the other bug).

If anyone really wants to pursue AB weighting (and further break our plans for superiour "frecency" design, tried and tested in FF awesome bar), I'd still suggest starting a new bug with a detailed description, which, if done right, would expose the design problems of that approach, as described in my comment 16. We really need to get away from trying random design that isn't based on well-founded analysis of pro's and con's, more so in the delicate area of recipient autocomplete where getting it wrong attracts a lot of regular frustration.

BTW FF awesome bar succeeds to get it right with "frecency" for potentially much larger data sets with arguably more distractors. "Autocomplete Frecency" Bug 382415 might really be worth trying (or Bug 1058583, or comment 13), to fix the current design failures of an ever-growing, never-shrinking "popularityIndex" that doesn't age as it should.

Comment 21

[Magnus Bae]

I find it very frustrating that this bug is being used to discuss some possible future when we/you are dealing with a seriously broken feature in Thunderbird. 

1. This is a bug (probably introduced in 31.4.0)
2. Leave politics about the future out of this and fix it (ie. it's not a "wontfix")
3. Figure out the future separately and test it better before releasing it to us users.

--

I'm experiencing the same problem as initially posted, running Windows 8.1 + TB 31.4.0, so it does not apply to only Windows XP. 

My autocomplete has become completely useless, it now suggests addresses added to collected AB due to newsletter receivals (of which I wanted to see the remote content) over my no. 1 used recipient which starts with "post@", instead I have to type out "post@k" to get a valid autocomplete. Not only that, but if I type out the address quickly after the autocomplete-suggestions appear it autoselects the first one from the autocomplete when I click enter, I'll be filing this as a separate bug. 

I don't think I'm the only one experiencing this bug, and the only reason I haven't written/reported sooner is because I've been to busy with work. This bug seriously affects my productivity and it is actually the second time that I've experienced this feature being broken in Thunderbird (https://bugzilla.mozilla.org/show_bug.cgi?id=497722).


Please fix this


Sincerely,

Magnus

Comment 22

[Magnus Bae]

Also would like to add that importance "Enhancement" on this issue is clearly wrong. This is at least "normal" if not even "major" (if I could choose).

Comment 23

[Thomas D. (:thomas8)]

(In reply to Magnus Bae from comment #21)
> I find it very frustrating that this bug is being used to discuss some
> possible future when we/you are dealing with a seriously broken feature in
> Thunderbird. 

Unless you're familiar with the technical internals and the current UX-design and how they apply to your particular dataset, I'd be more careful with conclusions like "seriously broken feature"; you might be wrong.


> 1. This is a bug (probably introduced in 31.4.0)

I'm afraid it's not.

> 2. Leave politics about the future out of this and fix it (ie. it's not a
> "wontfix")

What you call "politics about the future" is exactly to try and avoid problems like yours in the future.
For which we have to design the present in a way that doesn't prevent that better future.
More so because our manpower is limited, as Thunderbird is run almost exclusively by volunteers.

> 3. Figure out the future separately and test it better before releasing it
> to us users.

You're most welcome to join that work.

> 
> --
> 
> I'm experiencing the same problem as initially posted, running Windows 8.1 +
> TB 31.4.0, so it does not apply to only Windows XP. 
> 
> My autocomplete has become completely useless, it now suggests addresses
> added to collected AB due to newsletter receivals (of which I wanted to see
> the remote content) over my no. 1 used recipient which starts with "post@",
> instead I have to type out "post@k" to get a valid autocomplete.

Well, if you have dozens of entries in your collected AB which all start with "post@", how do you expect Thunderbird to guess the right one if you just search for non-unique search term "post"?
Oh well, that's where the future comes in: Indeed we could guess right if we implemented proper "frecency" algorithm. And if we really want to get that working in the future, fixing this bug by blanket prioritization of "Personal AB" (or blanket downgrading of "Collected Addresses") will be another obstacle, and we'll have other users complain that we ignore their "Collected Addresses" collected from writing to actual recipients. Hence my wontfix recommendation. As for the present, here's some information:

* As I already explained in previous comment, we have changed the UI and behaviour for remote content, again to avoid exactly your problem: We no longer force users to add addresses to any AB just for showing remote content. Instead, you can now add them to a separate list in your settings:
Tools > Options > Privacy > Mail content > Exceptions

* Obviously we have no way of telling which entries in your "Collected Addresses" had been added just for the sake of remote-content - so unfortunately you'll have to remove these manually. That's a legacy issue which we can do nothing about except advising you how to address it yourself by sorting out your "Collected Addresses".

* Somewhat contrary to your claims about your "no. 1 used recipient", those remote content contacts of yours which are getting in the way at the top are likely to actually have a higher (historical) popularityIndex (i.e. at some time in the past/ in absolute numbers, they might have been used more often than #1). If all of the involved contacts are matching only on their email addresses starting with "post@" (i.e. not matching on display names and such), then we use popularityIndex as next sort criterion, which should uplift your most-used contact provided all else is equal.

> Not only
> that, but if I type out the address quickly after the
> autocomplete-suggestions appear it autoselects the first one from the
> autocomplete when I click enter, I'll be filing this as a separate bug. 
> 
> I don't think I'm the only one experiencing this bug, and the only reason I
> haven't written/reported sooner is because I've been to busy with work. This
> bug seriously affects my productivity and it is actually the second time
> that I've experienced this feature being broken in Thunderbird
> (https://bugzilla.mozilla.org/show_bug.cgi?id=497722).

Again, you're most welcome to join the team so that we have more manpower to avoid such problems.

> Please fix this

We could consider adding an option to downgrade "Collected Addresses" for the legacy cases where users have lots of irrelevant remote-content entries in there, but as explained above, I'm not sure if that's a good idea or if we're just making it harder for ourselves to get it right in the future with cross-AB frecency, and same users might ultimately complain that their "Collected Addresses" from actual conversation are also downgraded which is undesirable.

Time permitting, we should also write up a support article explaining some of these things to the general public. Magnus Bae, perhaps you can help?
 
Solutions for your particular scenario:
> my no. 1 used recipient which starts with "post@
- pls clean up your collected Addresses and move out all remote-content addresses into the privacy exception list referenced above (that will most probably fix your problem already, without any coding)
- for that no1 contact, instead of searching for unspecific "post", why not add a unique Display name? We've made it so that beginnings of display names AND beginnings of mail addresses (your case) get priority.
- ultimate solution: For your no1 contact, open contact's properties, then add nickname in nickname field, e.g. Nickname: "ppp+" (without quotes). Then typing "pp+" in recipient autocomplete will ALWAYS reliably return only that contact (assuming you don't have any other contacts having that string in relevant fields, hence the triple p and the + sign to make it truly unique; you might get away with less.) For upcoming version of TB, we have fixed nickname functionality so that it will be enough for the nickname to be unique against other nicknames).

Comment 24

[Thomas D. (:thomas8)]

(In reply to Magnus Bae from comment #22)
> Also would like to add that importance "Enhancement" on this issue is
> clearly wrong. This is at least "normal" if not even "major" (if I could
> choose).

How can it be a bug not to prioritize matches in personal AB, while depending on use patterns, it's possible for users to collect (via composing) all their private and most frequently used contacts in "Collected Addresses"?

Magnus Bae, pls accept that while we're certainly not finished with fixing recipient autocomplete, this particular request is not a bug; and even as an enhancement, it is incompletely defined (vague ideas whose universal long-term consequences and implications for other necessary bug fixes have not been sufficiently explored). Otoh, the fact that our current implementation of "popularityIndex" (aka absolute, eternal frequency count which never goes down) does not reflect "recency" (aging), that's an actual design bug, and a bad one for that. So implementing some sort of "frecency" algorithm is not just a some fancy idea for the future, but an actual necessity for the present. This enhancement proposal is nowhere near that.

Comment 25

[Thomas D. (:thomas8)]

Introducing any inflexible criteria which weigh more than popularityIndex will de facto disable popularityIndex, which we deliberately introduced in Bug 276632 to fix this sort of never-ending discussions about the best algorithm, because there can never be a one-for-all algorithm based on fixed criteria except recency and {keyboard input / results picked correlation}. 

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

Bug 158728 (wontfix) - Autocomplete should list the Collected Address Book entries last
Bug 64662 (wontfix) - Recipient autocomplete results should be sorted (alphabetically?)
Bug 577119 (invalid/wontfix) - The "Private Addressbook" is searched last

All of these are similar/same to this bug have almost no votes, few CCs, few comments, between 1 and 3 dupes. For example, Bug 577119 requested essentially the same as this bug in 2010 and has never had any votes, comments, nor CCs since. And a wontfix comment from Wayne, consistent with his comment 10 and comment 12 here:

(In reply to Wayne Mery (:wsmwk) from Bug 577119 comment #1)
> giving the most recently used or most used
> addresses first, regardless of address book  (which is what I think it
> should be doing per spec, it should not be not ordered on address book)

So apparently so far this has never been a problem for users, probably because popularityIndex did the trick for them (because that's the main algorithm we've had for the last years, and users were quite happy with it, judging from the absence of complaints!). So it's a bit absurd to request here that we should further undermine popularityIndex by introducing even more inflexible criteria (while first comments are coming in that Bug 970456 might have done the wrong thing). If it's really becoming a problem again now, it's probably because we've shaken autocomplete search algorithm a bit, which corrects and in some cases expands the result set, so some old but popular(!) matches might be creeping out of their corners that users weren't seeing before.

The best way to approach this is to fix popularityIndex by implementing real "frecency" algorithm, especially if implemented with correlating the actual keyboard input with results picked. Which will make all of these problems go away, for everyone, forever:

Bug 382415 - Popularity index of recipient autocomplete doesn't honor timeline (implement frecency algorithm for searching email contacts: weigh how frequently AND recently-used contacts are)

Btw, users have been suggesting to add an element of "recency" to balance absolute "frequency" as early as March 2005, i.e. *before* we introduced popularityIndex towards the end of 2005:

(In reply to John McCormick from comment Bug 276632 #3)
> 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.