870069 - [SMS][MMS] Multi-Recipient: Group Participants view

Status: RESOLVED FIXED

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

Description

[Rick Waldron [:rwaldron]]

Attachment: wireframes

See wireframes v8, page 13, 01:

upon tap
opens multiple recipient overlay (refer to wireframe ‘Multi-recipient : group participants’)

See attachment

Comment 1

[Dan Heberden]

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.

Comment 2

[Corey Frang [:gnarf]]

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.

Comment 3

[Dan Heberden]

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.

Comment 4

[Dylan Oliver [:doliver]]

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

Comment 5

[Rick Waldron [:rwaldron]]

Attachment: 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.

Comment 6

[ayman maat :maat]

(In reply to Rick Waldron from comment #5)
> Created attachment 753383 [details] [review]
> 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?

Comment 7

[Rick Waldron [:rwaldron]]

(In reply to ayman maat :maat from comment #6)
> (In reply to Rick Waldron from comment #5)
> > Created attachment 753383 [details] [review]
> > 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 8

[Corey Frang [:gnarf]]

Comment on attachment 753383 [details] [review]
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.

Comment 9

[Julien Wajsberg [:julienw]]

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.

Comment 10

[Julien Wajsberg [:julienw]]

Also, the thread flickers when we come back.

Comment 11

[Julien Wajsberg [:julienw]]

reviewed on github

Comment 12

[Rick Waldron [:rwaldron]]

Comment on attachment 753383 [details] [review]
Fix for 870069

All review notes addressed

Comment 13

[Julien Wajsberg [:julienw]]

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 !

Comment 14

[Julien Wajsberg [:julienw]]

did a new review on github.

Comment 15

[Julien Wajsberg [:julienw]]

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 !

Comment 16

[ayman maat :maat]

(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

Comment 17

[ayman maat :maat]

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.

Comment 18

[Julien Wajsberg [:julienw]]

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 !

Comment 19

[Victoria Gerchinhoren [:vicky]]

(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!

Comment 20

[Julien Wajsberg [:julienw]]

Thanks Victoria !

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

Comment 21

[ayman maat :maat]

(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.

Comment 22

[ayman maat :maat]

Attachment: HTML5_SMS-MMSUserStorySpecifications_20130527_PhoNumSelection_v1.0.pdf

reference comment 21

Comment 23

[Julien Wajsberg [:julienw]]

Comment on attachment 753383 [details] [review]
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.

Comment 24

[Corey Frang [:gnarf]]

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

Comment 25

[Corey Frang [:gnarf]]

Comment on attachment 753383 [details] [review]
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.

Comment 26

[Corey Frang [:gnarf]]

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

Comment 28

[Rick Waldron [:rwaldron]]

Please CC me on any follow up bugs. Thanks

Comment 29

[Corey Frang [:gnarf]]

uplifted master: 5d808ed57f6a52ea4c976c55a409b8c4b65ae14f
to v1-train: ea27422630692d94def4af9332c0261b64526967

needed this to get audio/video attachments merged clean, can't wait for transitions