875836 - [Messages] Display individual senders in a group mms conversation

Status: RESOLVED WONTFIX

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

Description

[Rick Waldron [:rwaldron]]

Attachment: current display

I can't find anything in HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 that describes displaying the sender name with a message in group message threads. 

As you can see in the attachment, there are 8 people in this mms group thread, but I have no way of knowing who sent which message.

Comment 1

[ayman maat :maat]

nop indeed it is not. This is because group conversation, which is what your illustrating here with multiple incoming messaging into a single thread, was  never supposed to be part of V1.1 and so was never specified.

I think we can handle this particular case directly in visual design.  

Victoria if you need assistance with this, ping me over skype.

Comment 2

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #1)
> nop indeed it is not. This is because group conversation, which is what your
> illustrating here with multiple incoming messaging into a single thread, was
> never supposed to be part of V1.1 and so was never specified.

This is strange to me—what was expected to happen if a user wanted to send a photo to several people? MMS is multi-recipient-in-single-thread by default. Even if an MMS thread has a single recipient, they are still considered one of multiple recipients.

Comment 3

[ayman maat :maat]

(In reply to Rick Waldron from comment #2)
> (In reply to ayman maat :maat from comment #1)
> > nop indeed it is not. This is because group conversation, which is what your
> > illustrating here with multiple incoming messaging into a single thread, was
> > never supposed to be part of V1.1 and so was never specified.
> 
> This is strange to me—what was expected to happen if a user wanted to send a
> photo to several people? MMS is multi-recipient-in-single-thread by default.
> Even if an MMS thread has a single recipient, they are still considered one
> of multiple recipients.

There is a clear case for the user sending a single message to several recipients be it MMS (with attachment) or SMS. However in the MMS path there is ambiguity due to requirement constraints about how recipients who receive a group MMS will reply to the group (this is what i mean by group conversation). The core of the problem is a requirement whereby reply using MMS cannot be default, which means group conversation cannot be default behavior. My understanding is that we cannot have MMS as the default mode of reply due to user cost implications (it costs way more to send an MMS than an SMS). So currently a user receiving what is clearly a group message via MMS (SMS is always 1 to 1 correspondence even if the user sends out the initial message en bulk) will have to either add an attachment or write over 1530 characters in order to reply to the group (perpetuating the group conversation) otherwise they send back an SMS which is 1 to 1 correspondence. Thats so obviously not a great or useful UX for two reasons:

1) due to the need to write over 1530 char (text messages are rarely essays) or add an attachment to trigger a group reply
2) (and this is more important) for the end user after sending out 1:1 replies because they have not fulfilled any of the MMS trigger criteria, its going to be very disorientating to suddenly find themselves 'replying to all' because they happened to attach a file in reply to an incoming  group MMS. Huge UX risk.

This is the reason why, after rounds and rounds of discussion with product, group conversation was originally shelved for v1.1. It needed more time than we had in terms of design and development on 8th May when the decision was made, to define a pragmatic and useful experience. However for whatever reason the decision to defer group conversation  for V1.1 was overridden and it is present now. But none of the design constrains i have outlined here, as far as i know, have been alleviated. To compound things the proposition to have a switch which allows the user to define if a reply to an incoming group MMS message will be by default an MMS or not (thus facilitating group conversation - or not) has been vetoed. So from a design perspective, my friend, I am in checkmate when it comes to offering a solution to the design problem that from my understanding we now have regarding how replying to a group MMS will pragmatically work….

Comment 4

[Victoria Gerchinhoren [:vicky]]

Find attached the design and specifications for the Multi User messaging. 
. The user name should be placed next to the time stamp divided by an orange "|". 
. Long names will be truncated on the last name's first letter (unless we have 2 contacts with the same surname, in wich case will be truncated after the first different letter of each)
. Time stamp will display the message time, but every new date will be shown in the first time stamp of that date, so the next messages sent after that one will only contain the hour and minutes.

If you have further questions please "need info" me-

Thanks!

Comment 5

[Victoria Gerchinhoren [:vicky]]

Attachment: visual design and specs for multirecipients names in thread

Comment 6

[Corey Frang [:gnarf]]

So, can someone please describe the logic that we have in place right now to generate message headers - I've read over the code a few times, and would like to understand the choices here, they seem pretty arbitrary.

Once we add the idea of having to add a header before each message in the multi recipient threads, this logic is going to get really complex, and I want to make sure I understand it as is.  I'm going to keep trying to figure out what the desired behavior is here, while I work on this.

ni? borja because most of the code in getMessageContainer blames to you.

Comment 7

[Borja Salguero [:borjasalguero]]

Hi Corey,
This is a completely new feature (it's related with group messaging), so it's not related with the code made before. If you have any doubt you should check with Ayman if it's related with Interaction or Victoria if it's visual issue.

In the past we were adding this 'header' when receiving a new message and there was no previous header in the last 10 minutes, but there was no 'name' or similar because the grouping.

Comment 8

[Rick Waldron [:rwaldron]]

Attachment: Draft for 875836

This just an early draft so you can get an idea of the approach so far

Comment 9

[Corey Frang [:gnarf]]

Comment on attachment 759415 [details] [review]
Draft for 875836

Looking good so far, please request review flag again when you're ready to try and land this.  Just removing it for now to clean up my dashboard :)

Comment 10

[Rick Waldron [:rwaldron]]

Attachment: Github Pull Request https://github.com/mozilla-b2g/gaia/pull/10254

Comment 11

[Dietrich Ayala (:dietrich)]

Per triage decision, all groupmms moving to koi? as the feature is no longer in leo.

Comment 12

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Julien, do you think this bug is still there

Comment 13

[Julien Wajsberg [:julienw]]

Yep.

The whole Group MMS feature needs work, I have an item in my todo list since forever to sort the bugs and make them more sensible.

Comment 14

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(

Comment 15

[Julien Wajsberg [:julienw]]

Mass closing of Gaia::SMS bugs. End of an era :(