881653 - [MMS] Multi-recipient. Creating a group with contacts with same number is not managed fine

Status: RESOLVED WONTFIX

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

Description

[isabelrios]

Unagi 06/11 build:
Gecko-68ad212
Gaia-ea18de8

PROCEDURE
1. On Unagi device, create two contacts with the same number, ie.: A=1234, B=1234 and another one with a different number, ie.: C=5678
2. Open Messgaing app and create a new message
3. Tap into 'To' field, type 'A' and select that contact
4. Tap again into 'To' field and type 'C' to select that contact.
5. Send the MMS

EXPECTED
The group message is created correctly. The header should show: 'A and 1o other (+1)'
As it was defined previously when dealing with two contacts with the same nunber

ACTUAL
On step 3, when tapping on A, B is added into the 'To' field instead.
The header of the group message shows 'B (+1)'.
It seems that the functionality to show to contacts with same number ('Contact name and one other') is totally broken.

Comment 1

[Borja Salguero [:borjasalguero]]

This is a regression created here https://github.com/mozilla-b2g/gaia/commit/d62a67210206c48640a73cba8965c65cb3413c85#apps/sms/locales/sms.en-US.properties plus the need of adding a better management of the text when MMS Grouping + Several contacts with same phone number.

Ayman, If we have 3 contacts with same phone number, and the fist one is 'Manolo Stevenson', and we receive a Group MMS from Manolo sent to me and 3 more people, I will have:
Manolo Stevenson and 2 others (+3)

This text will not fit in the available space, How could we handle this scenario in the thread-list and in the header of a thread? Thanks!

Comment 2

[Rick Waldron [:rwaldron]]

(In reply to Isabel Rios [:isabel_rios] from comment #0)
> Unagi 06/11 build:
> Gecko-68ad212
> Gaia-ea18de8
> 
> PROCEDURE
> 1. On Unagi device, create two contacts with the same number, ie.: A=1234,
> B=1234 and another one with a different number, ie.: C=5678
> 2. Open Messgaing app and create a new message
> 3. Tap into 'To' field, type 'A' and select that contact
> 4. Tap again into 'To' field and type 'C' to select that contact.
> 5. Send the MMS
> 
> EXPECTED
> The group message is created correctly. The header should show: 'A and 1o
> other (+1)'
> As it was defined previously when dealing with two contacts with the same
> nunber

How is this possible? There wasn't _any_ handling for more then one contact, so how could there have been handling for more then one contact with the same number?


> 
> ACTUAL
> On step 3, when tapping on A, B is added into the 'To' field instead.
> The header of the group message shows 'B (+1)'.
> It seems that the functionality to show to contacts with same number
> ('Contact name and one other') is totally broken.

"'Contact name and one other'" is not what is shown in the wireframes.

Comment 3

[Rick Waldron [:rwaldron]]

Attachment: multi-recipient header as shown in wireframes

(In reply to Borja Salguero [:borjasalguero] from comment #1)
> This is a regression created here
> https://github.com/mozilla-b2g/gaia/commit/
> d62a67210206c48640a73cba8965c65cb3413c85#apps/sms/locales/sms.en-US.
> properties plus the need of adding a better management of the text when MMS
> Grouping + Several contacts with same phone number.
> 

This is a strange thing to call a "regression", considering it was fully reviewed and included tests that supported the wireframe expectations.

Comment 4

[ayman maat :maat]

(In reply to Rick Waldron from comment #2)
> (In reply to Isabel Rios [:isabel_rios] from comment #0)
> > Unagi 06/11 build:
> > Gecko-68ad212
> > Gaia-ea18de8
> > 
> > PROCEDURE
> > 1. On Unagi device, create two contacts with the same number, ie.: A=1234,
> > B=1234 and another one with a different number, ie.: C=5678
> > 2. Open Messgaing app and create a new message
> > 3. Tap into 'To' field, type 'A' and select that contact
> > 4. Tap again into 'To' field and type 'C' to select that contact.
> > 5. Send the MMS
> > 
> > EXPECTED
> > The group message is created correctly. The header should show: 'A and 1o
> > other (+1)'
> > As it was defined previously when dealing with two contacts with the same
> > nunber
> 
> How is this possible? There wasn't _any_ handling for more then one contact,
> so how could there have been handling for more then one contact with the
> same number?

Hey Rick,

Can i ask why we are not handling more than one contact with the same number? It is stated in the wireframe pack HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 that we need to handle a situation whereby the user adds exactly the same contact twice to the 'to' field. Design direction is given on how we should resolve this without sending more than one message to the same contact.

Comment 5

[ayman maat :maat]

(In reply to Borja Salguero [:borjasalguero] from comment #1)
> This is a regression created here
> https://github.com/mozilla-b2g/gaia/commit/
> d62a67210206c48640a73cba8965c65cb3413c85#apps/sms/locales/sms.en-US.
> properties plus the need of adding a better management of the text when MMS
> Grouping + Several contacts with same phone number.
> 
> Ayman, If we have 3 contacts with same phone number, and the fist one is
> 'Manolo Stevenson', and we receive a Group MMS from Manolo sent to me and 3
> more people, I will have:
> Manolo Stevenson and 2 others (+3)
> 
> This text will not fit in the available space, How could we handle this
> scenario in the thread-list and in the header of a thread? Thanks!

Lets say you have the following contacts with numbers associated to them in your phone:

Contact A: 123
Contact B: 123
Contact C: 345

***Composing***

1) The user should be able to add contact A, B and C to the 'to' field. 
2) user selects send and message is only send to A and C
So the header should read
	Contact A (+1)


***Receiving 1***

1)  The user receives a message from A which includes C in the thread
2) As A and B have the same phone number the system should only select the first instance of the phone number in the users contact list. 
So the header should read:
	Contact A (+1)

***Receiving 2***

1)  The user receives a message from E which includes A, B and C in the thread
2) As A and B have the same phone number the system should only select the first instance of the phone number in the users contact list. 
So the header should read:
	Contact E (+2)

Comment 6

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #4)
> (In reply to Rick Waldron from comment #2)
> > (In reply to Isabel Rios [:isabel_rios] from comment #0)
> > > Unagi 06/11 build:
> > > Gecko-68ad212
> > > Gaia-ea18de8
> > > 
> > > PROCEDURE
> > > 1. On Unagi device, create two contacts with the same number, ie.: A=1234,
> > > B=1234 and another one with a different number, ie.: C=5678
> > > 2. Open Messgaing app and create a new message
> > > 3. Tap into 'To' field, type 'A' and select that contact
> > > 4. Tap again into 'To' field and type 'C' to select that contact.
> > > 5. Send the MMS
> > > 
> > > EXPECTED
> > > The group message is created correctly. The header should show: 'A and 1o
> > > other (+1)'
> > > As it was defined previously when dealing with two contacts with the same
> > > nunber
> > 
> > How is this possible? There wasn't _any_ handling for more then one contact,
> > so how could there have been handling for more then one contact with the
> > same number?
> 
> Hey Rick,
> 
> Can i ask why we are not handling more than one contact with the same
> number? It is stated in the wireframe pack
> HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 that we need to handle a
> situation whereby the user adds exactly the same contact twice to the 'to'
> field. Design direction is given on how we should resolve this without
> sending more than one message to the same contact.

This is the second place that you've referred to the design doc about this issue but have not included a page number or any information about where I might read this specified behaviour.

Comment 7

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #5)
> (In reply to Borja Salguero [:borjasalguero] from comment #1)
> > This is a regression created here
> > https://github.com/mozilla-b2g/gaia/commit/
> > d62a67210206c48640a73cba8965c65cb3413c85#apps/sms/locales/sms.en-US.
> > properties plus the need of adding a better management of the text when MMS
> > Grouping + Several contacts with same phone number.
> > 
> > Ayman, If we have 3 contacts with same phone number, and the fist one is
> > 'Manolo Stevenson', and we receive a Group MMS from Manolo sent to me and 3
> > more people, I will have:
> > Manolo Stevenson and 2 others (+3)
> > 
> > This text will not fit in the available space, How could we handle this
> > scenario in the thread-list and in the header of a thread? Thanks!
> 
> Lets say you have the following contacts with numbers associated to them in
> your phone:
> 
> Contact A: 123
> Contact B: 123
> Contact C: 345
> 
> ***Composing***
> 
> 1) The user should be able to add contact A, B and C to the 'to' field. 
> 2) user selects send and message is only send to A and C
> So the header should read
> 	Contact A (+1)

B will not be accepted into the recipient list if it has the same number as A.


> 
> 
> ***Receiving 1***
> 
> 1)  The user receives a message from A which includes C in the thread
> 2) As A and B have the same phone number the system should only select the
> first instance of the phone number in the users contact list. 
> So the header should read:
> 	Contact A (+1)

This is exactly how it works now, because B was never added to the list.

> 
> ***Receiving 2***
> 
> 1)  The user receives a message from E which includes A, B and C in the
> thread
> 2) As A and B have the same phone number the system should only select the
> first instance of the phone number in the users contact list. 
> So the header should read:
> 	Contact E (+2)




No platform let's you address a message to the same number twice. iOS and Android will let you make a contact that has the same number as another contact, but will prevent you from adding both contacts as recipients of a new message.

Both iOS and Android do exactly the same thing FFOS currently does: if user tries to add a contact or type a number that already exists as a recipient, the number is "magically combined" (or disappears, however you look at it)

Comment 8

[ayman maat :maat]

(In reply to Rick Waldron from comment #7)
> (In reply to ayman maat :maat from comment #5)
> > (In reply to Borja Salguero [:borjasalguero] from comment #1)
> > > This is a regression created here
> > > https://github.com/mozilla-b2g/gaia/commit/
> > > d62a67210206c48640a73cba8965c65cb3413c85#apps/sms/locales/sms.en-US.
> > > properties plus the need of adding a better management of the text when MMS
> > > Grouping + Several contacts with same phone number.
> > > 
> > > Ayman, If we have 3 contacts with same phone number, and the fist one is
> > > 'Manolo Stevenson', and we receive a Group MMS from Manolo sent to me and 3
> > > more people, I will have:
> > > Manolo Stevenson and 2 others (+3)
> > > 
> > > This text will not fit in the available space, How could we handle this
> > > scenario in the thread-list and in the header of a thread? Thanks!
> > 
> > Lets say you have the following contacts with numbers associated to them in
> > your phone:
> > 
> > Contact A: 123
> > Contact B: 123
> > Contact C: 345
> > 
> > ***Composing***
> > 
> > 1) The user should be able to add contact A, B and C to the 'to' field. 
> > 2) user selects send and message is only send to A and C
> > So the header should read
> > 	Contact A (+1)
> 
> B will not be accepted into the recipient list if it has the same number as
> A.

Then you have deviated form the specification. 

guidance on the addition of multiple instances of the same contact can be found on page 07: 

"
Selection of same result
A user selects a contact with a given channel of communication (say telephone number) from the auto suggestions in order to add them to the ‘to’ field. If they then proceed to generate the same list of auto suggestions a second time the number already selected will still be presented. If the user then selects the same contact with the same channel of communication from the suggestions a second time in order to add to the ‘to’, the ‘to’ field will contain two individual entries for the same contact with same channel of communication. However when the user presses ‘send’ only one message should be sent to the contact.
"

Though this is talking about auto suggestions by extrapolation the principle should be implemented for any other method that a user can enter a contact into the 'to' field. 


> 
> 
> > 
> > 
> > ***Receiving 1***
> > 
> > 1)  The user receives a message from A which includes C in the thread
> > 2) As A and B have the same phone number the system should only select the
> > first instance of the phone number in the users contact list. 
> > So the header should read:
> > 	Contact A (+1)
> 
> This is exactly how it works now, because B was never added to the list.
> 
> > 
> > ***Receiving 2***
> > 
> > 1)  The user receives a message from E which includes A, B and C in the
> > thread
> > 2) As A and B have the same phone number the system should only select the
> > first instance of the phone number in the users contact list. 
> > So the header should read:
> > 	Contact E (+2)
> 
> 
> No platform let's you address a message to the same number twice. 

Is an incorrect statement.

> iOS and
> Android will let you make a contact that has the same number as another
> contact, but will prevent you from adding both contacts as recipients of a
> new message.

Also an incorrect statement

> 
> Both iOS and Android do exactly the same thing FFOS currently does: if user
> tries to add a contact or type a number that already exists as a recipient,
> the number is "magically combined" (or disappears, however you look at it)


At this point I think it is important to clarify a couple of things:

Firstly we are not designing or developing any other OS other than FirefoxOS
Secondly no other mobile OS exists as a UX specification for the design and development of FirefoxOS. The only UX specifications that you should be following or using for guidance are the ones that are made available specifically for this project. If the solution in the specifications that are delivered to you is ambiguous, conflicting, deficient, unachievable or in your professional opinion suboptimal you should be contacting the published of this specifications directly though any of the available communication channels, looping in whoever else need to be in on the conversation, and raising your concerns and then working with them to define a solution. It is not acceptable to simply refer to another OS for a solution and copy the observed behavior.
Thirdly, regarding what you have implemented: The unexpected and unnotified deletion of content the user has just input into the system is extremely bad UX and deviates from the behavior that was specified in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 and therefore needs correcting. 

If you need any further clarification please do not hesitate to contact me

Comment 9

[Alex Keybl [:akeybl]]

May be something we want to fix in the future, but not a blocker.

Comment 10

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #8)
> (In reply to Rick Waldron from comment #7)
> 
> > iOS and
> > Android will let you make a contact that has the same number as another
> > contact, but will prevent you from adding both contacts as recipients of a
> > new message.
> 
> Also an incorrect statement

This is _absolutely_ not an incorrect statement, I manually confirmed both before posting this response. If you'd like me to provide video demonstrating, I will gladly do so—just let me know.

Comment 11

[Rick Waldron [:rwaldron]]

http://jsfiddle.net/rwaldron/aV95z/show/light/


(does not demonstrate the contact addition step, only the duplicate recipient rejection)

I can also provide Android video if necessary.

Comment 12

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

So, what's the core problem here ?

The reported problem is that the user chose "A", but got "B" instead, even if that's the same number and won't be a problem once the user send the message.

I'm not sure that this is so easy to fix though. When we display a thread, we only have the participants, that is, the numbers. Therefore we can only search though the contacts API with this information.

If we _really_ want to persist which specific contact we added, we'll need a in-app database. I'm absolutely not sure this is worth it, and I'm tempting to close this WONTFIX given the value/complexity ratio.

Ayman, what's your stance on this ? Rick, am I missing something after you ?

Comment 13

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

(sorry, it was leo-, changed this by mistake)

Comment 14

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #12)
> So, what's the core problem here ?
> 
> The reported problem is that the user chose "A", but got "B" instead, even
> if that's the same number and won't be a problem once the user send the
> message.
> 
> I'm not sure that this is so easy to fix though. When we display a thread,
> we only have the participants, that is, the numbers. Therefore we can only
> search though the contacts API with this information.
> 
> If we _really_ want to persist which specific contact we added, we'll need a
> in-app database. I'm absolutely not sure this is worth it, and I'm tempting
> to close this WONTFIX given the value/complexity ratio.
> 
> Ayman, what's your stance on this ? Rick, am I missing something after you ?


Having the user select contact A but see contact B appear in the to field is not an acceptable UX. We as the technically knowledgeable know why its happening, but there is no way Mrs NotTechnicallyKnowledgable will understand. She will just be confused. Again avoiding such scenarios is basic UX knowledge/design practice.

In an ideal world we would be evolving the functionality of the Contacts app in order to make it proactive in identifying and resolving situations where more than one contact has exactly the same phone number. But thats not happening yet so we have to error handle elsewhere. 

I am not certain we need an in app Db as this point. From my PoV the simple fix that we can achieve within the messages app is to allow the user to add more than one contact from the contact list who shares exactly the same phone number to the 'to field'. Upon selecting send we only send the message to one instance of the number. This is what was designed, peer-reviewed, validated and therefore specified in the Wireframes… and it has already been coded at some point back in time. 

We aslo have présidence for such behavior in other mobile OS's such as Windows, Android 4.2.1 and iOS earlier than 6. 

From the strategic side of evolving the design of the message app implementing such behavior as specified allows us in the next iteration to implement some sort of 'upfront validation' (pre send) within the Messages App. This would mean that as contacts are added we would flag that there are two contacts present with the same number (we could also extend this out to 'upfront validation' of invalid phone numbers as well - which we have discussed briefly on other bugs). I could not specify any of this in V1.1 as i did not have the necessary building blocks available to me and the remit was that time was tight and therefore to keep things as simple as possible, whilst maintaining an understandable UX. So no new building blocks.

…So its no necessarily about where we are at, but more about maintaining an understandable UX and where we can go with evolving the design. And this is why it is important to deliver inline with the specifications.

Comment 15

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Ayman, I think the conversation deviated over time.

The first STR was not about adding 2 contacts with the same number, but about adding 1 contact, and seeing the other displayed in the header once you send the SMS.

While it's probably possible to do what's expected in the view that is displayed immediately after the user presses send (althought not easy with the current code structure because we're always doing a mozContacts call), I think it's not possible to do it once the user goes back to the thread list and selects it again, or if the app is killed and restarted, without an in-app database.

The use case of adding 2 contacts with the same number is imho another story, and it is Bug 880628 (where a patch is waiting for my review btw). So let's not mix bugs please :)

Comment 16

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #15)
> Ayman, I think the conversation deviated over time.
> 
> The first STR was not about adding 2 contacts with the same number, but
> about adding 1 contact, and seeing the other displayed in the header once
> you send the SMS.
> 
> While it's probably possible to do what's expected in the view that is
> displayed immediately after the user presses send (althought not easy with
> the current code structure because we're always doing a mozContacts call), I
> think it's not possible to do it once the user goes back to the thread list
> and selects it again, or if the app is killed and restarted, without an
> in-app database.
> 
> The use case of adding 2 contacts with the same number is imho another
> story, and it is Bug 880628 (where a patch is waiting for my review btw). So
> let's not mix bugs please :)

Hi Julien

Yep you are absolutely right, the conversation has slightly deviated from comment 0 question. Nevertheless 881653 and 880628 are actually directly related. If the behavior detailed in comment 0 of 881653 is true, then by definition it is not possible to add to contacts to the 'to field' that have the same phone number as one contact title will always default to another contact title.  

From a UX PoV we should always strive to give the user what they select. So if we have the following contacts and numbers in the contact list:

	Contact 1: 1234
	Contact 2: 3456
	Contact 3: 1234

If the user selects Contact 3 to send a message to, the orthodox UX path would be that we should always output Contact 3 in the header and maintain Contact 3 when as the header when the message is sent.

However I believe we have a wider UX problem here as incoming responses to the message sent to Contact 3's phone number will always register as coming from Contact 1. Why? because alphabetically A-Z is the way we are reading the Contact list and we are assigning the incoming number to the first instance of that number in the Contact list. Therefore If we persist with Contact 3 we will have quite a disconnect between the initial outgoing and incoming messages. Not only different threads being created, but different names in the headers of those threads. 

In view of this if the user selects Contact 3, we will have to output Contact 1 in the header of the outgoing message when the message is sent. To make the alteration of destination titles (name of contact is what i mean by that) understandable between the compose and the send view we could do with a temporary message informing the user what is going on at the point of send.

Comment 17

[Rick Waldron [:rwaldron]]

FWIW, None of this is an issue at all if the app simply rejects duplicates. I don't have refutable evidence, but subjectively I believe that this level of complication is what lead the other platforms to converge on duplicate rejection.

Comment 18

[ayman maat :maat]

(In reply to Rick Waldron from comment #17)
> FWIW, None of this is an issue at all if the app simply rejects duplicates.
> I don't have refutable evidence, but subjectively I believe that this level
> of complication is what lead the other platforms to converge on duplicate
> rejection.

I hear what your saying Rick, but like i keep telling you the example your promoting breaks one of the core UX / IxD rules: 'that the system should always keep users informed about what is going on, through appropriate feedback within reasonable time'… Any UX practitioner worth their salt would tell you that straight off the bat. Nevertheless if you user test the example your promoting, which by the way i have, you will see that statistically significant number of end users (we are over the 95th percentile, which is a catastrophic fail) have *absolutely* no idea what is going on:

case 1) When the respondent selects a contact that is offered to them (be it via auto suggestion or contact list) but that also happens to share the same phone number with a contact that is already in the 'to filed'  they have no idea why the system responds but the selected contact simply does not appear in the 'to field'

case 2)  When the respondent types a phone number that also happens to be the same as phone number in the 'to field' (the case for this is where the existing phone number in the 'to field' has scrolled off screen and therefore the users cognitive load is increased) they have no idea why, upon completion of input, the newly input number just vanishes.

In both cases respondents are frustrated. A significant number of them attribute the behavior to a fault in the system, not to a fault in their own system management (a fault in system management being the conflict in the management of their own contact list or manual input). When the reason for the observed behavior is explained out to them, they continue to blame the system for not handling / communicating the problem and therefore still perceive a system fault.

Now I understand that it is easier for you as a developer to code the example you want. But from a UX / IxD PoV it breaks a core design principle leading to a degradation in the end users perception of the integrity of the system. I therefore cannot underwrite it.

Comment 19

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

Just a thought: would it be possible to visually explain to the user why it vanishes ? Eg I can think that we add first the recipient, but then, with an animation, the new recipient would "merge" with the old (same) recipient ?

Another thought for case 1: we could have a single recipient box, but containing all names (still entered by the user) for the same number, separated with a comma.

Comment 20

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #19)
> Just a thought: would it be possible to visually explain to the user why it
> vanishes ? 

Yes there is a solution i am working on that would evolve the current specified behavior whereby we flag duplicates to the user using the banner at the time of addition and give the duplicate contact module a different treatment. 

> Eg I can think that we add first the recipient, but then, with an
> animation, the new recipient would "merge" with the old (same) recipient ?

merging animations are difficult because of the case where the existing phone number in the 'to field' has scrolled off screen at the time when the second phone number is added

Comment 21

[Rick Waldron [:rwaldron]]

(just making this searchable with the rest of the tickets that include "multi-recipient")

Comment 22

[ankit93040]

I think this is the Duplicate of 971386?

Comment 23

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

No it's not.

Here we're dealing with MMS group recipients.

Comment 24

[Julien Wajsberg [:julienw] (PTO -> Aug 24)]

As explained earlier, let's wontfix this. This is an edge case, and I'm not even sure it's a valid one. Displaying "B" instead of "A" is as good as it gets: it relates to the same number, even if it's not the contact the user chose initially.

Let's see if someone complains in the future. So far nobody did.