Follow up to Bug 951676 to track the following scenario: 4. When we have more than one recipient associated with the message -> A circle with the number of recipients of that message will be shown. ni to visual design team to provide specs for this. Thanks!

Find attached the visual mockup and spec of how multiple recipients' thread should look in the messages inbox screen.

triage: set 2.1? to triage when planning 2.1

This was taken as VR for 2.1 and in planned sprint. So I'm replacing the 2.1? by feature-b2g.

Hey Fang, Here is the screenshot of the inbox panel that contains threads with multiple recipients. I'd like to confirm with you following points: 1. We display multiple recipients indicator for the any message draft with multiple recipients and for the non-draft MMS with multiple recipients. Right? 2. As per attached spec title for the thread with multiple recipients has the following format "first_contact_name_or_number + remaining_number_of_recipients". Currently we use another format "first_contact_name_or_number (+remaining_number_of_recipients)". Should we leave round brackets for number of recipients as it was before? Thanks!

Hello Oleg, after discussion with Fang, think I can answer your questions! 1. We will display the "+3" recipient number indicator after contact name (or number). We will NOT be showing the "round icon with total recipient number on it" on the right side, instead, to align the design when there's only one recipient, we want to use a avatar-like picture that suggests there are multiple people in the conversation. 2. We'd like to make 2 changes to the current design, first, remove the brackets. Second, try to show the name of 2nd, 3rd (and so on so forth) recipient when possible. This is to give user more info on who's in the conversation on the inbox level, because on the conversation/thread view page, we only show the first contact info. Possible combinations: a) when there's only enough space to show one contact name first_contact_name_or_number + remaining_number_of_recipients ex. Wilfred Mathanaraj +3 b) when there's enough space to show one contact name and part of second contact name first_contact_name_or_number + "," + second_contact_name_or_number (partial) + "..." + remaining_number_of_recipients ex. Jenny Lee, Fang... +2 c) when there's enough space to show two full contact names first_contact_name_or_number + "," + second_contact_name_or_number + remaining_number_of_recipient ex. Jenny Lee, Ray Ma +3 Fang will provide a visual to better explain the idea and define the space used for displaying contact name/number. Let me know if there's any problem, thanks!

Comment on attachment 8461808 [details] Multiple recipients thread I will attached the visual spec asap. Thanks!

As we're waiting for the new spec, reassigned for now.

Hi Fang, do we have any update about the new visual spec for multiple recipient in thread list view?

Hi, Attached the new visual spec. Spec includes: * multiple recipients layout * message draft with multiple recipients * No contact image * No recipient The default image Sabrina is still working on it. The image is going to work for the entire system, so it'll take some times. Let me know if you have any other questions about the spec, Thanks!

Per product prioritization, this could be 2.2 focus.

Use feature-b2g:2.2? rather than just 2.2.

Hey Fang, we still miss the generic image here :/

Attached the generic image, Thanks!

Fang, can you please give some guidance about how to use this image? * IIRC we don't need to use it for contacts without pictures. Or do we? * do we always use it at the top-left position? Also, can you try to compress the assets a little more? Thanks !

Unassigning until we have the answer.

Hi Julien, We'll use it for contacts without pictures now on. And For image position, we want to place it in random, So the pattern won't look all the same. Also the assets have newer version again. I already compressed the new assets. Currently Carol is working on all the default image for entire system with Pavel. For contact photo is in bug 1069820. Incase you need to know, since this is also contact default image. Let me know if you need anything else. Thanks!

Hey Fang, Could you please let us know if we should display default image for the 1-to-1 threads with numbers that user doesn't have in Contacts (aka unknown numbers)? Thanks!

(In reply to Oleg Zasypkin [:azasypkin] from comment #20) > Hey Fang, > > Could you please let us know if we should display default image for the > 1-to-1 threads with numbers that user doesn't have in Contacts (aka unknown > numbers)? > > Thanks! We're thinking not display anything in ​this case. So we have only two cases when we don't display anything: 1. Draft without recipient 2. Thread with a number that isn't in contacts. Thanks! :)

Comment on attachment 8495759 [details] GitHub pull request URL Hey Julien, Can I ask for your early feedback here? I have some concerns that I've left on GitHub. Thanks!

Comment on attachment 8495759 [details] GitHub pull request URL Looks good to me :) some comments on github but it should be ready soon !

Comment on attachment 8495759 [details] GitHub pull request URL Hey Julien, Here are some more fixes and generator syntax instead of recursive Promise chain. Could you please take a look? Thanks!

Comment on attachment 8495759 [details] GitHub pull request URL r=me with the comments handled. In case you want a second look for your additional changes, please ask Steve :)

Comment on attachment 8495759 [details] GitHub pull request URL Hey Steve, Since Julien is on PTO, could you please have a quick look at the latest commit in PR to be sure that everything is fine :) Thanks!

Comment on attachment 8495759 [details] GitHub pull request URL Looks great! It's nice to see more feature and new utils invented :)

(In reply to Steve Chung [:steveck] from comment #27) > Comment on attachment 8495759 [details] > GitHub pull request URL > > Looks great! It's nice to see more feature and new utils invented :) Thanks for review! Master: https://github.com/mozilla-b2g/gaia/commit/d5a7b209931e4d698dad865d57616d3235dacab7

https://moztrap.mozilla.org/manage/case/8071/ https://moztrap.mozilla.org/manage/case/7973/

let's keep the already-landed improvement in 2.2.