See wireframes v8, page 13, 01: upon tap opens multiple recipient overlay (refer to wireframe ‘Multi-recipient : group participants’) See attachment

This is pending approval from the UX team - there's a chance 1.1 will group send a message, treat that as a bulk-send (creating independent threads) and redirect to the thread list. Thus, tapping on the header to show the recip list would never even be possible, let alone necessary.

We will wait until we can actually do some group mms based testing, then ayman will look at the state and let us know if it works.

It's now agreed upon that v1.1 will not have support for group-messaging, only mass-messaging. Thus, this need for this panel of showing thread participants is negated. v9.0 of the wireframes will reflect this as well.

Removing from QE2 -- this will be milestoned as appropriate when decision is made by MMS team.

After completing the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=874358, the experience of "nothing" when tapping on the header of a multi-participant mms thread was enough to convince me that this need to be completed. Here is a visual walk through: https://www.dropbox.com/sh/bcwe0z671t70c6k/JMQ8SxSJ4l Keep in mind that the CSS for the "overlay/prompt" needs help, but I don't understand the shared/BB CSS enough to make those kinds of changes.

(In reply to Rick Waldron from comment #5) > Created attachment 753383 [details] > Fix for 870069 > > After completing the fix for > https://bugzilla.mozilla.org/show_bug.cgi?id=874358, the experience of > "nothing" when tapping on the header of a multi-participant mms thread was > enough to convince me that this need to be completed. > > Here is a visual walk through: > https://www.dropbox.com/sh/bcwe0z671t70c6k/JMQ8SxSJ4l > > Keep in mind that the CSS for the "overlay/prompt" needs help, but I don't > understand the shared/BB CSS enough to make those kinds of changes. Hi Rick I can say that: 1) in the second screen where you show the list of participants, there should be no 'edit mode' CTA in the top right hand corner as the user cannot edit the list 2) in the final screen in the layer that details the options for an individual recipient there should be an option to 'send message as well'. If the recipient is not in the contact list there should also be two more options presented: 'Create new contact' and 'Add to existing contact' Appart from that is there anything more specific that you want me to comment on?

(In reply to ayman maat :maat from comment #6) > (In reply to Rick Waldron from comment #5) > > Created attachment 753383 [details] > > Fix for 870069 > > > > After completing the fix for > > https://bugzilla.mozilla.org/show_bug.cgi?id=874358, the experience of > > "nothing" when tapping on the header of a multi-participant mms thread was > > enough to convince me that this need to be completed. > > > > Here is a visual walk through: > > https://www.dropbox.com/sh/bcwe0z671t70c6k/JMQ8SxSJ4l > > > > Keep in mind that the CSS for the "overlay/prompt" needs help, but I don't > > understand the shared/BB CSS enough to make those kinds of changes. > > Hi Rick > > I can say that: > > 1) in the second screen where you show the list of participants, there > should be no 'edit mode' CTA in the top right hand corner as the user cannot > edit the list Fixed in new commit. > > 2) in the final screen in the layer that details the options for an > individual recipient there should be an option to 'send message as well'. Fixed in new commit. > If > the recipient is not in the contact list there should also be two more > options presented: 'Create new contact' and 'Add to existing contact' Yes, this complete. I should've included a screen cap, sorry about that. > > Appart from that is there anything more specific that you want me to comment > on? Nope, this exactly what I was looking for! I've just pushed the changes to the PR and will post screen shots as well

Comment on attachment 753383 [details] Fix for 870069 Not entirely comfortable with the chunk of code this pull is changing, but all the code looks pretty solid to me and some quick testing seems good on the device. Going to let julien look this one over.

I think we need the panel slide, as we have between the thread list view and the thread view. I agree this could be made in another bug if that's too much to do here.

Also, the thread flickers when we come back.

reviewed on github

Comment on attachment 753383 [details] Fix for 870069 All review notes addressed

Ayman, on the wireframe, starting page 14, it's said that when we're in the multi recipient group participants panel, any action (create contact, call, etc, and even cancel) makes the user go back to the thread view after the action. That's what Rick implemented but when I try it, it feels wrong. I'd rather let the user stay on that panel until he chooses to go back. Therefore I'd like to know if you're still keeping the previous opinion. Thanks !

did a new review on github.

Victoria, the current code from Rick doesn't use the "slide" effect to display the new panel. Do you think it will be necessary ? Maybe we won't do it now, but the current code will need to take this into account if we eventually need it. Thanks !

(In reply to Julien Wajsberg [:julienw] from comment #13) > Ayman, on the wireframe, starting page 14, it's said that when we're in the > multi recipient group participants panel, any action (create contact, call, > etc, and even cancel) makes the user go back to the thread view after the > action. That's what Rick implemented but when I try it, it feels wrong. I'd > rather let the user stay on that panel until he chooses to go back. > > Therefore I'd like to know if you're still keeping the previous opinion. > > Thanks ! Hey Julien. Thats a very good catch its an oversight by me there. Yeh, on page 15 or 16 the completion of any action or the selection of the Cancel CTA should take the user back to the list of group participants detailed on page 14, not to the SMS thread view screen on page 13. Thanks for flagging. Do you want to open a bug to correct it. I will update the wireframes

Actually Julien I need to clarify. we have two instances from where the screens detailed in page 15 and 16 can be triggered: 1) when a phone number is selected from within a message bubble within the message thread itself 2) when a phone number is selected from the listing of numbers on page 13 what i have detailed in Comment 16 is true for when the screens detailed in page 15 and 16 are accessed from page 13. However we will return the user directly to the message thread if pages 15 and 16 are accessed from a phone number within a message bubble as detailed in point 1) above.

Generally enough, we can say we need to go back to where we were before the action. Which makes sense no matter what. Anyway this bug is not about your point 1), I don't exactly know if is already implemented either ;) Thanks for your precisions !

(In reply to Julien Wajsberg [:julienw] from comment #15) > Victoria, the current code from Rick doesn't use the "slide" effect to > display the new panel. Do you think it will be necessary ? Maybe we won't do > it now, but the current code will need to take this into account if we > eventually need it. > > Thanks ! Hi Julien, You mean the "going deeper" transition to go from one screen to a deeper level of information? If that's what you're asking, the answer is yes. We need to help the user understand how's he navigating the information, and we do it by this set of transitions. Thanks!

Thanks Victoria ! So, Rick, that means we'll have to do a new panel now, otherwise we'll have to do it again afterwards...

(In reply to Julien Wajsberg [:julienw] from comment #18) > Generally enough, we can say we need to go back to where we were before the > action. Which makes sense no matter what. > yeh, I have specified that the user is returned to wherever the screens detailed on pages 15 and 16 were launched from. will attach a pull out of the wireframes here for clarity.

reference comment 21

Comment on attachment 753383 [details] Fix for 870069 redirecting to Corey because I won't be able to review this until I come back from holiday. Corey, this needs some more work, so don't bother reviewing now, but you can read the history if you want, and ask me questions before I leave.

The issue of adding a transition is moving to bug 879851 - I am [NO_UPLIFT]ing this until we solve that.

Comment on attachment 753383 [details] Fix for 870069 This needs to land so we can move onto other problems that need the code in this patch. r=me If there are any problems we discover on master we can fix them quickly, please CC rick or myself on anything related.

master: https://github.com/mozilla-b2g/gaia/commit/5d808ed57f6a52ea4c976c55a409b8c4b65ae14f

Please CC me on any follow up bugs. Thanks

uplifted master: 5d808ed57f6a52ea4c976c55a409b8c4b65ae14f to v1-train: ea27422630692d94def4af9332c0261b64526967 needed this to get audio/video attachments merged clean, can't wait for transitions