827256 - [Contacts] User can't search the contact by phone number

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Contacts, defect)

Description

[Leo]

1. Title : User can't search the contact by phone number
2. Precondition : Run contacts
3. Tester's Action : Input phone number in search field
4. Detailed Symptom (ENG.) : when user input phone number in search field, doesn't show search result
5. Detailed Symptom (KOR.) : 
6. Expected : Can search people by phone number
7.Reproducibility: Y
1)Frequency Rate : 100%
8.Comparison Results : 
1)Model Comparing : 
9. Attached files: 
1)Log : 
2)Test Contents : 
3)Video file :

Comment 1

[David Scravaglieri [:scravag]]

This is a new feature that we would really have but it's not scheduleded for V1

Comment 2

[Jose Manuel Cantera]

I agree and it can make the current search process to perform even worse.

Comment 3

[alberto.pastor]

(In reply to Jose M. Cantera from comment #2)
> I agree and it can make the current search process to perform even worse.

We just would need to add the phone to the data-search attribute, isn't it?

Comment 4

[ayman maat :maat]

We can search by phone number in the contact list that is accessed through the SMS app:

1) open SMS app
2) select compose new SMS icon
3) in the 'to' field start to type a phone number

...however, to achieve search by phone number directly in the contact list app itself would require not only a change of code but also a change of visual design as the search here currently looks at:

Comment 5

[ayman maat :maat]

This is not as simple as adjusting the code for searching the contact list app.

Currently we search the phone number of the contact list accessed through the SMS app:

1) launch SMS app
2) select compose new SMS icon
3) start to type a number in the 'to' field

result: phone numbers are search

...however, to achieve search by phone number in the contact list app itself would require not only a change of code but also a change of visual design. This is because the search in the contact list app queries the following fields:

- Firstname
- Secondname
- company

So in Visual Design we would need to add the phone number to the search stings returned. The contact list in the SMS app does not search the company field.

We need to standardise the search behavior of the contact list when accessed via the different apps

Comment 6

[ayman maat :maat]

...comment 4 was submitted in error by the way but i cannot remove it. Comment 5 is what should be read.

Comment 7

[alberto.pastor]

iOS allows you to search by phone number in Contacts app without showing the phone number in the result list. I don't think adding that visual change is a must. In my opinion, if you are searching by phone, and it returns a list of contacts, you understand what's happening even if the phone is not shown in the list.

Comment 8

[ayman maat :maat]

(In reply to Alberto Pastor from comment #7)
> iOS allows you to search by phone number in Contacts app without showing the
> phone number in the result list. I don't think adding that visual change is
> a must. In my opinion, if you are searching by phone, and it returns a list
> of contacts, you understand what's happening even if the phone is not shown
> in the list.

Maybe on this instance the iOS approach is sub optimal.

Two points:

1) if the user cannot see the phone number that is being returned in by the search, they cannot make a decision to select a contact from the results returned until they have added sufficient numbers to reduce the list down to a single contact. Which defeats the object of auto search. The idea behind auto search is that it provides an accelerator to the end user finding what they are looking for based on a correlation between the string they have input and a section of the string search. If the end user cannot see the result (section of string that correlates) AND the rest of the string they cannot make a decision.

2) How do you propose to handle situations whereby an end user enters a phone number in the firstname, secondname or company field for a contact? (this happens)

In this instance we would generate results with the phone number in the above listed fields highlighted but also have mixed in with those results results that have nothing highlighted AND no indication of why they have been returned.

both these instances provide suboptimal UX. Therefore i would disagree and say that we do indeed need Visual Design in order to facilitate the addition of this code.

Comment 9

[Jose Manuel Cantera]

If Ayman is right then I think this should be moved to V2 or something like that. But that's only my opinion.

Comment 10

[ayman maat :maat]

(In reply to Jose M. Cantera from comment #9)
> If Ayman is right then I think this should be moved to V2 or something like
> that. But that's only my opinion.

To be honest with you Jose, given the phase we are in i am inclined to agree. 

Just further to this: searching by phone number was removed from the specs for the contact app quite some time ago, the argument being that if the user was entering a phone number to find a contact to contact them they would just enter the phone number directly into the dialer. My counter argument was that the user might be searching for a phone number in the contact list *not* to contact a contact but to verify whether or not a phone number they have (received by other means/though another device) but do not recognize belongs to a contact in their contact list. But i was overruled. I still hold that this counter argument (use case) is valid and i would encourage functionality to search by phone number to be incorporated into searching the contacts app... but like i say, given the phase we are in, i am inclined to agree that this function could be moved to V2. 

What does the rest of the world think?

Comment 12

[Rob MacDonald [:robmac]]

I talked it over with Casey and we agree with Ayman that this feature could be moved to V2.

Perhaps Peter can provide us with some information on why this was deemed priority and whether it's something we can defer until V2.

Comment 13

[Daniel Coloma:dcoloma]

Peter is busy in MWC :) but I've just talked to him. This is is V1.1 and P1 as per partner request. We have also agreed that something similar to what iPhone implements in this regard would be enough given 1.1 timeframe.

Comment 14

[alberto.pastor]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8364

Pointer to Github pull-request

Comment 15

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 719010 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/8364

Simple change, working perfectly on the phone.

Thanks Alberto.

Comment 16

[Dylan Oliver [:doliver]]

Can this be resolved/fixed?

Comment 17

[alberto.pastor]

https://github.com/mozilla-b2g/gaia/commit/32d7f344430ad72c11d54737eef589ba4dbea4d4

Comment 18

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted commit 32d7f344430ad72c11d54737eef589ba4dbea4d4 as:
v1-train: d98c68e188389ad33098adb068c313fb6b6f88f9

Comment 19

[Jason Smith [:jsmith]]

I believe TEF owns testing of this.

Isabel - Are you working on adding coverage here?

Comment 20

[Maria Angeles Oteo (:oteo)]

The testing of this US owns to TEF team, they are preparing the test plan for it

Comment 21

[isabelrios]

(In reply to Jason Smith [:jsmith] from comment #19)
> I believe TEF owns testing of this.
> 
> Isabel - Are you working on adding coverage here?

Jason, yes, we have several test cases already defined. Will be shared as soon as they are ready so that can be imported into Moztrap

Comment 22

[Walter Chen[:ypwalter][:wachen]]

This test case tries to insert numbers without really looking into the search result. In this case, I think this is in-moztrap-
https://moztrap.mozilla.org/manage/case/7046/

I am creating 2 test cases for this.

Comment 23

[Walter Chen[:ypwalter][:wachen]]

Sorry,
I did a bad filter :P

There are 
https://moztrap.mozilla.org/manage/case/7027/
https://moztrap.mozilla.org/manage/case/7037/
https://moztrap.mozilla.org/manage/case/7036/
https://moztrap.mozilla.org/manage/case/7029/
...
Around 6~7 cases handling this already.

Also, verified fixed in 20130604 Unagi Master PVT build.