Bugzilla

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is completely unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data usage - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this is a little-used or little-needed feature as long as we we are not exposing it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data usage - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this is a little-used or little-needed feature as long as we we are not exposing it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this is a little-used or little-needed feature as long as we we are not exposing it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this (search prefs) is a little-used or little-needed feature as long as we we are not exposing it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this (search prefs) is a little-used or little-needed feature as long as we we are not exposing or documenting it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this (search prefs) is a little-used or little-needed feature as long as we we are not exposing nor documenting it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this (search prefs) is a little-used or little-needed feature as long as we we are not exposing nor documenting it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Imhow, supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that this (search prefs) is a little-used or little-needed feature as long as we we are not exposing nor documenting it in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Imho, supporting different users with different needs is key to maintain and expand our userbase.

(In reply to Magnus Melin [:mkmelin] from comment #3)
> Seems like there is very little to salvage from those prefs. The names do not match the data to that high of a degree anymore. We may want to just wontfix this. The number of users who had managed to find and edit such prefs are going to be very very few.

There's no way we could just wontfix this bug. It's not just about the prefs. It's also about a significant and covert UX fail where our default search algorithm is pretty unpredictable and inconsistent after the implementation was broken by the new address book (see comment 0 for details on ux-principles involved). It now depends on the order of email addresses in a contact whether direct searches for parts of an email address succeed or not. No rhyme or reason for that.

But apart from fixing the UX fail, as Aleca said in comment 4, we also want to continue supporting the pref because things like `Custom1-4` fields or Notes are totally useless if they cannot be searched, but which fields should be searched or not is really a matter of scenario and data structure - different users, different needs. Enterprise which keeps massive notes on a contact may want to exclude notes from search. Others may need to search exactly that data to find the needle in the haystack.

Again, arguing that the search prefs are a little-used or little-needed feature as long as we we are not exposing nor documenting them in any way is a self-fulfilling prophesy of little value. Counting users also has very limited value because if we remove/break every feature which is only used by a small percentage of users, we may lose a lot of users depending on how important those features are to them. Breaking potential enterprise use cases is worse, and we are not always seeing all of their users. Imho, supporting different users with different needs is key to maintain and expand our userbase.