804402 - Contacts with Company name but no first or last name are sorted by phone number, not Company name

Status: VERIFIED FIXED

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

Description

[Chris Peterson [:cpeterson]]

STR:
1. Add a contact with a Company name but no first or last name. This could be a common use case when people add a business' phone number, such as your favorite pizza delivery service.
2. Return to the Contacts list screen.

ACTUAL RESULT:
The new contact is listed by its phone number at the bottom of the contacts list.

EXPECTED RESULT:
The new contact would be listed alphabetically by its company name.

Comment 1

[alberto.pastor]

cc @ayman to confirm

Comment 2

[ayman maat :maat]

I am looking into this. will come back later with response

Comment 3

[ayman maat :maat]

OK

Steps as follows:
1. Add a contact with a Company name but no first or last name. 
2. Return to the Contacts list screen.

Result must be:
The new contact is listed alphabetically by its company name.

Let me know if you require further clarification.

Comment 4

[Gregor Wagner [:gwagner]]

We currently don't support this in the backend. It is an easy fix but we reduced the sorting to given and family name for v1 afaik.
Do we have a spec that describes the wanted sorting behavior?

We have to adapt the API call in Gaia, change the sortfunction in dom/contacts/fallback/ContactService.jsm and write proper tests for it.

James, can someone in Taipei take this?

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

Hi Josh, is this within the v1 scope to sort by company?

Comment 6

[ayman maat :maat]

Hi Joe. 

Yes it should be in V1 scope as the results returned within the contact list make no sense in the use case outlined above without it.

Comment 7

[David Scravaglieri [:scravag]]

Josh could you renominate if you think it's a blocker ?

Comment 8

[Josh Carpenter [:jcarpenter]]

Renoming. Per Ayman, the result should be:

> 1. Add a contact with a Company name but no first or last name. 
> 2. The new contact is listed alphabetically by its company name.

It is common for users to have business contacts. Displaying them as unnamed phone numbers stuck at the bottom of the list would be useless (and infuriating).

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

BB-, user can workaround by inputing the company in first/last name.

Comment 10

[Joe Cheng [:jcheng] (please needinfo)]

Hi Josh, please renominate if the workaround is unacceptable user experience. Thanks

Comment 11

[ayman maat :maat]

(In reply to Joe Cheng from comment #9)
> BB-, user can workaround by inputing the company in first/last name.

Hi Joe. Sorry, that is not an acceptable solution for two reasons: 

1) Importing from SIM. 

     If the user has some contacts set up on their SIM card using just the company field, they would have to go through their contacts and reformat them.

2) Adding a new contact

     The affordance of having an open field named 'company' overrides the users path to use the first/last name fields in the primary usage phase. 

In both these scenarios the end user would have to:
 
a) experience the dissatisfaction of this bug (that a contact with no first name or last name but a company name is listed by its phone number at the bottom of the contacts list), 
b) define for themselves what the problem is (because if they imported from SIM the list would have worked for them on their last phone)
c) define for themselves a solution to the bug (which would be to use the first/last name fields)

This all undermines the integrity and perceived value of our product because in comparison to the previous phone the end user has migrated from we are delivering a lower quality experience. Therefore i cannot support this proposed solution, even as an interim one.

Comment 12

[ayman maat :maat]

request to josh to renom

Comment 13

[Gregor Wagner [:gwagner]]

(In reply to ayman maat :maat from comment #11)
> (In reply to Joe Cheng from comment #9)
> > BB-, user can workaround by inputing the company in first/last name.
> 
> Hi Joe. Sorry, that is not an acceptable solution for two reasons: 
> 
> 1) Importing from SIM. 
> 
>      If the user has some contacts set up on their SIM card using just the
> company field, they would have to go through their contacts and reformat
> them.

We don't import company names from sim cards with the format we support for v1.

I don't think this should block.

Comment 14

[ayman maat :maat]

(In reply to Gregor Wagner [:gwagner] from comment #13)
> (In reply to ayman maat :maat from comment #11)
> > (In reply to Joe Cheng from comment #9)
> > > BB-, user can workaround by inputing the company in first/last name.
> > 
> > Hi Joe. Sorry, that is not an acceptable solution for two reasons: 
> > 
> > 1) Importing from SIM. 
> > 
> >      If the user has some contacts set up on their SIM card using just the
> > company field, they would have to go through their contacts and reformat
> > them.
> 
> We don't import company names from sim cards with the format we support for
> v1.
> 
> I don't think this should block.

OK, i did not know that. That's very much a shame and quite a concern. Could i ask what other contact information we do not import for V1.

Nevertheless the rest of what i have written in comment 11 holds true. Remember the whole point of this device is to facilitate communication. The user's contact list sits at the very core of their act of communication for reasons that i think are obvious. Therefore any unexpected behavior within the contact list that reduces the end users experience of using it and forces them into an unorthodox workaround (like having to use the first/last name field for company name when there is a companies field presented) undermines the integrity and perceived value of our product. Like i say this is particularly true when the end user reflects on the experience they had on the device they migrated from. They should perceive an advancement in experience, not a regression.

I know this bug should block.

Comment 15

[Gregor Wagner [:gwagner]]

(In reply to ayman maat :maat from comment #14)
> (In reply to Gregor Wagner [:gwagner] from comment #13)
> > (In reply to ayman maat :maat from comment #11)
> > > (In reply to Joe Cheng from comment #9)
> > > > BB-, user can workaround by inputing the company in first/last name.
> > > 
> > > Hi Joe. Sorry, that is not an acceptable solution for two reasons: 
> > > 
> > > 1) Importing from SIM. 
> > > 
> > >      If the user has some contacts set up on their SIM card using just the
> > > company field, they would have to go through their contacts and reformat
> > > them.
> > 
> > We don't import company names from sim cards with the format we support for
> > v1.
> > 
> > I don't think this should block.
> 
> OK, i did not know that. That's very much a shame and quite a concern. Could
> i ask what other contact information we do not import for V1.

We only get a single alphanumeric string and the number off the sim card.
So we don't even have a concept of given and last name (as I also described in bug 815580)

I am not arguing that this is an unimportant bug but when it comes to the question if we can ship the phone without fixing it I would say yes.

Comment 16

[Josh Carpenter [:jcarpenter]]

Upgrading the UX-P2 and renominating, per consultation with TEF and Moz UX teams, for the reasons cited in comment #11 and #14. 

LOE and risk also seems relatively low. If first name and last name are blank, display company name. If company name also blank, display phone number. We already have most of the logic written. Theoretically this is just one more switch case.

Comment 17

[Dylan Oliver [:doliver]]

blocking+ for UX-P2

Comment 18

[Anthony Ricaud (:rik)]

Attachment: Proposed patch

Comment 19

[alberto.pastor]

Hey Anthony, thanks for taking this. Could you please point to a Github Pull Request? THanks!

Comment 20

[Anthony Ricaud (:rik)]

Attachment: Proposed patch

Comment 21

[Dietrich Ayala (:dietrich)]

Driver retriage: Not a functional blocker and not critical enough to hold the whole release for.

Once all the higher priority blockers are fixed, would take this patch on approval.

Comment 22

[Anthony Ricaud (:rik)]

Comment on attachment 692926 [details] [diff] [review]
Proposed patch

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: 
Testing completed: 
Risk to taking this patch (and alternatives if risky):

Comment 23

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 692926 [details] [diff] [review]
Proposed patch

I don't think you want to remove <script defer type="text/javascript" src="/shared/js/mouse_event_shim.js"></script>

Could be a rebasing issue? If yes please re-request approval when it is fixed.

Comment 24

[Anthony Ricaud (:rik)]

Comment on attachment 692926 [details] [diff] [review]
Proposed patch

Yes, that was a rebasing issue. Fixed!

Comment 25

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

https://github.com/mozilla-b2g/gaia/commit/404df0184559ac532960e7f9b4a48208f0d4c9c0

Comment 26

[Matthew N. [:MattN]]

Verified on unagi with build 20130116230203