Open Bug 607320 Opened 15 years ago Updated 3 years ago

Autocomplete address search using addresses stored in gloda for addresses not in address book

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: me, Unassigned)

References

Details

Attachments

(2 files)

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; nl; rv:1.9.2.10) Gecko/20100914 SUSE/3.6.10-0.3.1 Firefox/3.6.10 Build Identifier: 3.0.8 I often find myself looking for an address, that I know is not in my address book, while I do know that I once saw that address in a mail message, or in a CC line of a message mailed to me. "Global search" is somewhat helpful, but it would be extremely useful to have an "Address Search" function that goes through all the mail, especially "To" and "Cc" fields but also body, searching specifically for email addresses. Reproducible: Always
OS: Linux → All
Hardware: x86_64 → All
"searching specifically for email addresses" for what addresses? Addresses that are not in your address book? And then, what do you want to do with those results? Haro, it will help if you also describe how you want this feature to behave by providing a list of numbered steps of what you want to happen - as suggested in the bug creation form you used. Like 1. click xxx 2. do yyy 3. see zzz 4. ... ...
Hi Wayne, I'm sorry if my explanation was unclear. I meant something like this: 1) Suppose I want to write an email to John Smith. So I click "Compose", and in the "To:" bar, I type "John Smith". However, John is not in my address book, so I would need to know John's email address, and manually type it in. But suppose I don't know or don't remember John's email address. 2) There should be a button for me to click: "Find John Smith's email address". Assume that at some point in the past, somebody emailed me John's address. Or, somebody sent me an email, and CC'd it to John. Or, I got an email from John, but didn't bother to save his address. 3) When I click the button, the following happens: Thunderbird searches through all my emails, looking for "John Smith" (and "Smith, John", and "J. Smith" etc. etc.) in the "To:", "Cc:" and "From:" fields. Also, it searches email bodies for "John" and "Smith" anywhere near an email address, so it may also find strings like "write to John Smith on js21@domain.com". It then shows me a list of all of these findings, allowing me to recognise and select John's email address, and send my email. (John's address will be automatically saved in "Collected Addresses".) Hope this clarifies!
Component: Search → Message Compose Window
QA Contact: search → message-compose
Summary: Feature request: general address search → Autocomplete address search using addresses stored in gloda for addresses not in address book
This is an interesting suggestion for enhancement, although bug 170270 about searching all address books should certainly take precedence. When gloda global search was introduced, I remember using it to find email addresses that are not yet in my address book (or that autocomplete wouldn't find, due to it's hopeless search algorithm and lack of search fields), and while it was exciting to see how fast gloda would find the desired address, the frustration came when trying to copy that address from gloda search autocomplete, or even the first search results, both of which is not possible. So getting those addresses as an autocomplete suggestion during composition, as suggested by this bug, would help a lot to that end. Questions: - can we expect all users to want autocompletion for contacts that are not in their address book? - if not: How can we indicate that an autocomplete finding is not from the AB, and/or how can we provide an UI to choose which addresses should be searched?
Hi Thomas, good to hear from you. I understand your point about autocompletion. Personally I think autocompletion is already weak because many of us have address books with lots similar names, and many of our contacts will have multiple email addresses (e.g. work and private), so autocompletion already (in its current form) increases a risk of sending to the wrong address. Perhaps a more useful idea: as of the version of Thunderbird I currently use (3.1.10, not sure it's the latest!) there is a functionality to use the "global search" box in the top right corner of the main screen to find email addresses, using a drop-down box: see screenshot attached (screen4.png). This is very useful, but does not allow copying the address into an email. Would it be possible to have a similar drop-down function in the "Compose" window? See screenshot demo screen5.png (n.b. this is obviously a mock-up). Now I'm not a developer, but it seems to me that this can probably be done without writing too much new code...? And may even partially address the issues raised in bug 170270. Hope this helps!
Kalenz, thanks for providing the screenshots. Personally, I don't see the benefit of two lines for one result. But that's more of a presentational issue, which is actually not very important for this bug. It's more important to analyse and define the behaviour/ui/customization and potential problems of this bug. To that end, could you please answer the two questions below? (Both of them are not answered by your screenshots). (In reply to Thomas D. from comment #3) > This is an interesting suggestion for enhancement, although bug 170270 about > searching all address books should certainly take precedence. > Questions: > 1) can we expect all users to want autocompletion for contacts that are not > in their address book? > 2) if not: How can we indicate that an autocomplete finding is not from the > AB, and/or how can we provide an UI to choose which addresses (ABs only vs. > ABs + addresses found on messages via Gloda) should be searched? I'm trying to say that when we add gloda results to the autocomplete dropdown results list, it can be confusing to mix confirmed addresses (saved in your address book) with unconfirmed addresses (any address found on your messages via gloda). Benefits have been mentioned, but we also need to understand how this can (negatively) affect the the result set usability. From there, we probably need some sort of visual indication which addresses are from user's ABs and which addresses are gloda-only but not yet confirmed in ABs, perhaps an overlay icon in the result list entry.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: