298438 - Address book quick search should search in whole/entire address card / all contact fields

Status: NEW

(MailNews Core :: Address Book, enhancement)

Description

[Markus Faßbender]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

The quick search field of the address book should get a new item for example
"complete address card" where it searchs in all fields of the address card. 

This might be slower than the other searches but sometimes you don't know where
you will find you information. For example if you search for a phonenumber. Is
it work, home or fax ? 

Also you where able to search for other fields like name or email.

Reproducible: Always

Steps to Reproduce:
1. open address book
2. goto the quick search field
3.

Actual Results:  
You could only search for name or email.

Expected Results:  
You should be able to search the whole address card.

Comment 1

[Adam Guthrie]

Related to/duplicate of bug 117320 or bug 118624?

Comment 2

[Markus Faßbender]

I also found bug 118624, but it only relates to nickname.

The other bug is won't fix. But I don't agree with the argumentation. Quick
search is a great feature and in mails you can use it very good, but in the
addressbook you are only able to search for name and email. 

There should be some more options. I would prefer a search over all fields.

Comment 3

[philiptdotcom]

...in particular, when typing an address (e.g., to:, cc:, etc.), NICKNAMES that
match what's typed should be matched (e.g., typing "laurief" should pick up last
name "Furumoto", first name "Laurie", nickname "lauriefurumoto"--it doesn't now).

Possibly(?) also related to bug #s 295428, 224863, 298438

Comment 4

[philiptdotcom]

oops, forgot to add:

using Thunderbird version 1.0.6 (20050716) on WinXP Pro

Comment 5

[Mark Banner (:standard8)]

SeaMonkey & Thunderbird related devs have spoken about this on irc and we've agreed that this could be implemented as an enhancement - the recommended way would be to re-use something like the drop down selection that Thunderbird has on its thread pane and allow a similar selection for address book. That way not everyone is forced to search through every field of the address book.

Confirming & moving to core/address book

Comment 6

[Mark Banner (:standard8)]

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

Comment 7

[Wayne Mery (:wsmwk)]

normally I just cc: - but gotta comment, WOW, this one would be nice :)

Comment 10

[KingFisher64]

(In reply to comment #5)
> SeaMonkey & Thunderbird related devs have spoken about this on irc and we've
> agreed that this could be implemented as an enhancement - the recommended way
> would be to re-use something like the drop down selection that Thunderbird has
> on its thread pane and allow a similar selection for address book. That way not
> everyone is forced to search through every field of the address book.
> 
> Confirming & moving to core/address book

I cannot agree with the idea of giving a user choice where to look for. Its just pointless and obsolete. Natural thing is that when user is searching address book he expects to search ALL data. No drop down selection is needed here. Software has to be made as simple as possible (Aza Raskin, JoelOnSoftware.com etc). 

Plus notice that looking in all fields solves many problems and gives many possibilites to a user!. Some people want to tag contact cards - with good search tool it would be enough to put some words into "other" and you can quickly search for them - no need to make any tags!

Comment 11

[Rolf Gloor]

(In reply to comment #10)
> I cannot agree with the idea of giving a user choice where to look for. Its
> just pointless and obsolete. Natural thing is that when user is searching
> address book he expects to search ALL data. No drop down selection is needed
> here. Software has to be made as simple as possible (Aza Raskin,
> JoelOnSoftware.com etc). 

I agree to this part.

(In reply to comment #10)
> Plus notice that looking in all fields solves many problems and gives many
> possibilites to a user!. Some people want to tag contact cards - with good
> search tool it would be enough to put some words into "other" and you can
> quickly search for them - no need to make any tags!

I do NOT agree with you on that.
Either tags or multiple categories per contact are great for structuring data. eg. some people may belong to several categories/tags like: friends, sport club members, and clients.

Comment 12

[Charles]

(In reply to comment #11)
> (In reply to comment #10)
>> I cannot agree with the idea of giving a user choice where to look for. Its
>> just pointless and obsolete. Natural thing is that when user is searching
>> address book he expects to search ALL data. No drop down selection is needed
>> here. Software has to be made as simple as possible (Aza Raskin,
>> JoelOnSoftware.com etc). 

> I agree to this part.

> (In reply to comment #10)
>> Plus notice that looking in all fields solves many problems and gives many
>> possibilites to a user!. Some people want to tag contact cards - with good
>> search tool it would be enough to put some words into "other" and you can
>> quickly search for them - no need to make any tags!

> I do NOT agree with you on that.
> Either tags or multiple categories per contact are great for structuring
> data. eg. some people may belong to several categories/tags like: friends,
> sport club members, and clients.

I agree with both of these comments...

Usually choice is a good thing - in this case, I think it just overly complicates... and yes, Tags/Categories are a good thing and allow for all the custom grouping/searching necessary for an Address book.

Comment 13

[Piotr Dobrogost]

(In reply to comment #11)
> (In reply to comment #10)
> > Plus notice that looking in all fields solves many problems and gives many
> > possibilites to a user!. Some people want to tag contact cards - with good
> > search tool it would be enough to put some words into "other" and you can
> > quickly search for them - no need to make any tags!
> 
> I do NOT agree with you on that.
> Either tags or multiple categories per contact are great for structuring data.
> eg. some people may belong to several categories/tags like: friends, sport club
> members, and clients.

What you described is possible with whole text search as well. These are not reasons tags are better.
Features that make tags somehow better at categorizing things are:
- you have a list of all tags in one place
- when you change a tag it changes in all places it's used automatically
- you have an option to quickly add some tag based on existing tags (if it's supported by tag system)

Having said that I have to stress that practice shows that people are neither good at structuring data nor they are willing to use such a structure when they are looking for a data. That's why Google's interface for searching is a text field.

Beacuse you can't categorize the world, because you can't categorize even your own contacts... :)

Comment 14

[Dominique]

When you write an email and want add an other correspondent, you search it by a tag different that name or email.
It will be important to retrieve an correspondent by another item like society or another item from vCard.

Comment 16

[Thomas D. (:thomas8)]

Potential questions for this bug:

1) does it really work out well for *all* fields to be searched by default? (in terms of resultset)
2) how does "search all fields" perform?
3) depending on 1) and 2), do we need some primary UI for selecting fields to search? (customization, post-facets a la quick filter in msg list, etc.)

Also note that there's advanced AB search which lets you search most, but not all of the other fields (Bug 184483), but also no option there yet for "whole card" aka "Any field" (Bug 328199).

Comment 17

[KingFisher64]

1) I've talked about it. Don't make things hard. Don't force user to remeber in which field he put a particualar phone number for example. Just search EVERYTHING. Usually user will put enough data to make results search small enough. It will be a name, email, or telephone number. Hardly ever this will generate a lot of results to go though.

One problem is that if you put two phrases in they are treated as "x y" and not as "x" and "y".
This should also be changed.

2)

In my case very well (though I only search 183 contacts). I have just changed default values in config. Nothing more is required from developing team! 

below you have a list of variables to change (as default they are set to false):

contactssidebar.search_home;true
contactssidebar.search_internet;true
contactssidebar.search_name;true
contactssidebar.search_other;true
contactssidebar.search_phones;true
contactssidebar.search_work;true

3) it is really annoying when someone asks the same questions again. Please read disscussion above.

Comment 18

[Thomas D. (:thomas8)]

(In reply to wojciech64 from comment #17)

wojciech, thank you for rapid feedback :)

> 1) I've talked about it. Don't make things hard. Don't force user to remeber
> in which field he put a particualar phone number for example. Just search
> EVERYTHING. Usually user will put enough data to make results search small
> enough. It will be a name, email, or telephone number. Hardly ever this will
> generate a lot of results to go though.

That makes sense. due to the unique nature of most data in most fields (addresses, phone numbers, chat names, web pages...), false positives should be rather unlikely. I'm still wondering though if all users want fields like "Notes" to be searched always?

> One problem is that if you put two phrases in they are treated as "x y" and
> not as "x" and "y".
> This should also be changed.

Indeed, and not so coincidentally I have been fighting tooth and nail to get this changed in bug 558931. :) Good news is, we're finally working on it and Suyash has provided first patches so we can expect that highly valuable change to land soon on Trunk (and bubble up from there, later, to release channel: TB31).

> 2) In my case very well (though I only search 183 contacts).

Thank you for that user story as a first tentative data point.
Did you actually enable searching *all* fields on *all* the tabs of the contact card?

> I have just changed default values in config. Nothing more is required from developing
> team!

Sorry Sir, but that's a wrong assumption. The prefs you changed (contactssidebar.search_*) must be part of an addon. But yeah, in this case it's actually not very hard to change the fields searched.
So it seems to be a problem of agreement and determination to fix this; perhaps the usefulness is not yet clear to everybody, or there are performance concerns. That's why I am asking questions to move this forward. I'm actually on your side :)

> 3) it is really annoying when someone asks the same questions again. Please
> read disscussion above.

No. Wrong tone, and wrong content. I had read the discussion, and I ask these questions for a reason. More specifically, focused questions are essential to move this forward. Question 3 (need for customization options or such) depends on Question 1 and 2 (ux and performance analysis). Question 2 had barely been mentioned before my comment. Without clear answer to question 1 and 2, there can be no conclusive answer to question 3. Convincing and generally agreed answers to all questions are absolutely crucial to get any traction on this. Convincing me might also be helpful, as I'm one of the very few people who still triage the 10000+ TB and mailnews bugs that are on record (confirmed and unconfirmed), so I come with some perspective (touched almost 2000 TB & mailnews bugs, cc'ed on many more...). I'm also known for moving bugs that have come to my attention and are convincing and achievable under the current circumstances of volunteer maintenance, as seen in related bug 558931 and bug 529584 ;)

Comment 19

[Thomas D. (:thomas8)]

Fwiw, wrt performance, look at Bug 705837 about AB autocomplete performance (similar to AB quicksearch), and real-world scenario there where 40000 contacts are searched...

Comment 20

[Thomas D. (:thomas8)]

These are the card properties that we currently search in AB quicksearch:

PrimaryEmail, DisplayName, FirstName, LastName

And this is the full list of properties which we might search (this bug):

292 // A nice list of properties for the benefit of C++ clients
293 #define kFirstNameProperty          "FirstName"
294 #define kLastNameProperty           "LastName"
295 #define kDisplayNameProperty        "DisplayName"
296 #define kNicknameProperty           "NickName"
297 #define kPriEmailProperty           "PrimaryEmail"
298 #define kPreferMailFormatProperty   "PreferMailFormat"
299 #define kLastModifiedDateProperty   "LastModifiedDate"
300 #define kPopularityIndexProperty    "PopularityIndex"
301 #define kAllowRemoteContentProperty "AllowRemoteContent"
302 
303 #define kPhoneticFirstNameProperty  "PhoneticFirstName"
304 #define kPhoneticLastNameProperty   "PhoneticLastName"
305 #define kSpouseNameProperty         "SpouseName"
306 #define kFamilyNameProperty         "FamilyName"
307 #define k2ndEmailProperty           "SecondEmail"
308 
309 #define kHomeAddressProperty        "HomeAddress"
310 #define kHomeAddress2Property       "HomeAddress2"
311 #define kHomeCityProperty           "HomeCity"
312 #define kHomeStateProperty          "HomeState"
313 #define kHomeZipCodeProperty        "HomeZipCode"
314 #define kHomeCountryProperty        "HomeCountry"
315 #define kHomeWebPageProperty        "WebPage2"
316 
317 #define kWorkAddressProperty        "WorkAddress"
318 #define kWorkAddress2Property       "WorkAddress2"
319 #define kWorkCityProperty           "WorkCity"
320 #define kWorkStateProperty          "WorkState"
321 #define kWorkZipCodeProperty        "WorkZipCode"
322 #define kWorkCountryProperty        "WorkCountry"
323 #define kWorkWebPageProperty        "WebPage1"
324 
325 #define kHomePhoneProperty          "HomePhone"
326 #define kHomePhoneTypeProperty      "HomePhoneType"
327 #define kWorkPhoneProperty          "WorkPhone"
328 #define kWorkPhoneTypeProperty      "WorkPhoneType"
329 #define kFaxProperty                "FaxNumber"
330 #define kFaxTypeProperty            "FaxNumberType"
331 #define kPagerTypeProperty          "PagerNumberType"
332 #define kPagerProperty              "PagerNumber"
333 #define kCellularProperty           "CellularNumber"
334 #define kCellularTypeProperty       "CellularNumberType"
335 
336 #define kJobTitleProperty           "JobTitle"
337 #define kDepartmentProperty         "Department"
338 #define kCompanyProperty            "Company"
339 #define kScreenNameProperty         "_AimScreenName"
340 #define kCustom1Property            "Custom1"
341 #define kCustom2Property            "Custom2"
342 #define kCustom3Property            "Custom3"
343 #define kCustom4Property            "Custom4"
344 #define kNotesProperty              "Notes"
345 
346 #define kGtalkProperty              "_GoogleTalk"
347 #define kAIMProperty                "_AimScreenName"
348 #define kYahooProperty              "_Yahoo"
349 #define kSkypeProperty              "_Skype"
350 #define kQQProperty                 "_QQ"
351 #define kMSNProperty                "_MSN"
352 #define kICQProperty                "_ICQ"
353 #define kXMPPProperty               "_JabberId"
354 #define kIRCProperty                "_IRC"
355 
356 #define kAnniversaryYearProperty    "AnniversaryYear"
357 #define kAnniversaryMonthProperty   "AnniversaryMonth"
358 #define kAnniversaryDayProperty     "AnniversaryDay"
359 #define kBirthYearProperty          "BirthYear"
360 #define kBirthMonthProperty         "BirthMonth"
361 #define kBirthDayProperty           "BirthDay"

Comment 21

[Thomas D. (:thomas8)]

Full list of AB contact properties (see comment 20) is found here:

http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/public/nsIAbCard.idl#292

Comment 22

[Thomas D. (:thomas8)]

(In reply to wojciech64 from comment #17)

> contactssidebar.search_home;true
> contactssidebar.search_internet;true

wojciech64, could you please mention the name of the addon which you are using and which creates these prefs?

Comment 23

[Charles]

Pretty sure it is the apparently abandoned Contacts Sidebar:

https://addons.mozilla.org/en-us/thunderbird/addon/contacts-sidebar/

Addon homepage:

http://extensions.sanjer.nl/?page=tb_cs

We used to use it, but support for it ceased long ago.

Comment 24

[Thomas D. (:thomas8)]

(In reply to wojciech64 from comment #17)
> 1) I've talked about it. Don't make things hard. Don't force user to remeber
> in which field he put a particualar phone number for example. Just search
> EVERYTHING.

a) I agree that for *most of the fields* listed in comment 20, this could work, because of the unique nature of their data, and the shortness of entries.

b) For *Custom1 to Custom4* fields, we are in unknown territory as we don't know what kind of and how much data users might have in these fields.
- someone should check what's the longest possible entry there (number of characters)?

We could possibly include them on the somewhat vague but not unreasonable assumption that due to the small size of these fields in UI, their content is probably also limited in size; furthermore, these are likely to be fields of a systematic nature with a tendency towards clearly defined tags, which might justify searching them always; but depending on content, this might create problems for some users already. E.g. if user uses custom1 field to store "workmates" with values like "Peter A, Paul B, etc.", and the workmates might also be in the AB with their own card (Peter A, Paul B, etc), then when user searches for "Peter A", he will find both "Peter A"'s contact PLUS all the cards which have "Peter A" as workmate. Depending on scenario, that might be desired; in other scenarios, it might make it very hard to find "Peter A" between all the other results ("false positives") of his workmates that have his name in "Custom1".

c) For *Notes* field, that's entirely freeform and designed for more data, so we have no idea how such data will change the result set for users depending on their use patterns of *Notes*.
Same problem as in b), it's easy to get unwanted false positives depending on usage and scenarios if there are too many intersections with regular data in main fields.
In Peter A's card, there could be notes about relationship of "Peter A" with Paul B, James D, and Francis E, but we don't know if that implies that when searching for any of "Paul B", "James D", and "Francis E", each of them should also list "Peter A" in the result set. There could be phone numbers of whoever in Peter A's note fields, but that doesn't mean they should always be searched and found like the main phone numbers from other contacts. Depending on data structure in Notes field, this might make the entire search useless with too many false positives.

Comment 25

[Thomas D. (:thomas8)]

(In reply to Charles from comment #23)
> Pretty sure it is the apparently abandoned Contacts Sidebar:
> https://addons.mozilla.org/en-us/thunderbird/addon/contacts-sidebar/
> http://extensions.sanjer.nl/?page=tb_cs

Thank you Charles, addons can sometimes be helpful as a starting point or model how to code up a fix for a related bug.

Comment 26

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #16)
> Potential questions for this bug:
> 
> 1) does it really work out well for *all* fields to be searched by default?
> (in terms of resultset)

From analysis of my comment 24, I conclude that we *cannot* simply search all fields by default for reasons of ux-efficiency (too many potential false positives might spoil the search experience).

> 2) how does "search all fields" perform?

Performance is still mostly unknown, but most private users will usually have smaller ABs, and most corporate users will probably have an admin to tweak included search fields for them (which will always be possible even after we fix this bug).

> 3) depending on 1) and 2), do we need some primary UI for selecting fields
> to search? (customization, post-facets a la quick filter in msg list, etc.)

Again from my comment 24, I think we *will* need some sort of customization or facets IF we include freeform fields "Custom1" to "Custom4" and "Notes" into the default search.

Next steps for this bug:

Otoh, as a minimal fix for this bug before going into more complexity of customization and facets, we could agree on a reduced set of AB card properties (from the list in comment 20) that we consider safe enough to be always included in default search.

Comment 27

[KingFisher64]

(In reply to Charles from comment #23)
> Pretty sure it is the apparently abandoned Contacts Sidebar:
> 
> https://addons.mozilla.org/en-us/thunderbird/addon/contacts-sidebar/
> 
> Addon homepage:
> 
> http://extensions.sanjer.nl/?page=tb_cs
> 
> We used to use it, but support for it ceased long ago.

Yes, Charles you are right. Its contacts sidebard plugin. Which is now disabled as its not supported yet those prefs still work perferclty fine!

Comment 28

[KingFisher64]

(In reply to Thomas D. from comment #26)
> (In reply to Thomas D. from comment #16)
> > Potential questions for this bug:
> > 
> > 1) does it really work out well for *all* fields to be searched by default?
> > (in terms of resultset)
> 
> From analysis of my comment 24, I conclude that we *cannot* simply search
> all fields by default for reasons of ux-efficiency (too many potential false
> positives might spoil the search experience).
> 
> > 2) how does "search all fields" perform?
> 
> Performance is still mostly unknown, but most private users will usually
> have smaller ABs, and most corporate users will probably have an admin to
> tweak included search fields for them (which will always be possible even
> after we fix this bug).
> 
> > 3) depending on 1) and 2), do we need some primary UI for selecting fields
> > to search? (customization, post-facets a la quick filter in msg list, etc.)
> 
> Again from my comment 24, I think we *will* need some sort of customization
> or facets IF we include freeform fields "Custom1" to "Custom4" and "Notes"
> into the default search.
> 
> Next steps for this bug:
> 
> Otoh, as a minimal fix for this bug before going into more complexity of
> customization and facets, we could agree on a reduced set of AB card
> properties (from the list in comment 20) that we consider safe enough to be
> always included in default search.

Thomas you make things way too complicated. We discuss a simple improvment for too long. Thunderbird is dead for a long time. I hope its not due to such fruitless disscusions.

You look for solutions to problems in a wrong place. I said that if you are afraid of too many results just add "and" to all search terms. Users are used to this from google and they will adjust searching terms accordingly.

This is simple, intuitive (beacuse its known for a user from many other applications) and DOES NOT require any additional customization.

Again I completely don't agree with limiting search to some fields and customizing for others. 

It is you who want to decide for a user where he wants to put data in?? Very bad habit imho.
You start playing a game with a user - if you put it here Sir it will be searched, but if you put it there you need to mark some silly checkbox so that you can find it...

Plus I will repeat myself - you force user to think - where did I note this... 
Also many users can be incosistent. One time they will note something in a particular field but next time in a different place. They will quickly get lost in your complex system what is and what is not searched.

I think I have said enough. I cannot support my case further and therefore I'm not planning on carring on this disscusion, sorry.

Side note: this shows limitations of open source software feature implementation procedure. If there was a clear leader with enough knowledge he would quickly make a good decision and in a few days/weeks thousands of users would start to enjoy a new feature. Like it is now we will be disscussing stuff endlessly.

Comment 29

[KingFisher64]

Hi guys,
some time has passed, what is the current status regarding this issue?

I've been looking for info online, because I myself forgot hot to change settings to search all fields.
And the only result my search on duckduckgo produced is our veeery old conversation.

I quickly checked TB ver. 78.7.0 (32bit) and I can see that if I put anything in "other" field - its not searched.

Comment 30

[Stan]

@Szpak, same here, really annoying not to be able to search the contents of address cards. But I found an extension that does it: https://addons.thunderbird.net/en-US/thunderbird/addon/cardbook/
I just installed, imported my address books, and found the address I was looking for immediately.

Comment 31

[KingFisher64]

@Stan, I changed my nick from Szpak to KingFisher64.

Thanks a lot for the link to this extension!
I checked quickly. It adds tons of features, but in a separate layer.

It seems it does not affect how native address book search works.

Anyway this tool is very good and search there is much better!
I will be exploring it and maybe will adopt this as main interface for contacts in TB.