1003843 - Follow up to Bug 951676 - [Messages][Refresh] Add specific image in case of more than one recipient in the list threads

Status: RESOLVED FIXED

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

Description

[Noemí Freire (:noemi)]

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!

Comment 1

[Victoria Gerchinhoren [:vicky]]

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

Comment 2

[Victoria Gerchinhoren [:vicky]]

Attachment: SPEC Inbox multiple recipient's thread

Comment 3

[Victoria Gerchinhoren [:vicky]]

Attachment: Visual Mockup. SMS_MMS_Inbox.png

Comment 4

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

triage: set 2.1? to triage when planning 2.1

Comment 5

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

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

Comment 6

[Oleg Zasypkin [:azasypkin]]

Attachment: Multiple recipients thread

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!

Comment 7

[Jenny Lee]

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 8

[Fang Shih [:fang]]

Comment on attachment 8461808 [details]
Multiple recipients thread

I will attached the visual spec asap. Thanks!

Comment 9

[Oleg Zasypkin [:azasypkin]]

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

Comment 10

[Steve Chung [:steveck]]

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

Comment 11

[Fang Shih [:fang]]

Attachment: 2.1_Messaging_inbox_VisualSpec.zip

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!

Comment 12

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

Per product prioritization, this could be 2.2 focus.

Comment 13

[Kai-Chih Hu [:khu]]

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

Comment 14

[Julien Wajsberg [:julienw]]

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

Comment 15

[Fang Shih [:fang]]

Attachment: Generic_image.zip

Attached the generic image, Thanks!

Comment 16

[Julien Wajsberg [:julienw]]

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 !

Comment 17

[Julien Wajsberg [:julienw]]

Unassigning until we have the answer.

Comment 18

[Fang Shih [:fang]]

Attachment: _Export_Contact_image.zip

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!

Comment 19

[Oleg Zasypkin [:azasypkin]]

Attachment: GitHub pull request URL

Comment 20

[Oleg Zasypkin [:azasypkin]]

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!

Comment 21

[Fang Shih [:fang]]

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

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8495759 [details] [review]
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 23

[Julien Wajsberg [:julienw]]

Comment on attachment 8495759 [details] [review]
GitHub pull request URL

Looks good to me :)

some comments on github but it should be ready soon !

Comment 24

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8495759 [details] [review]
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 25

[Julien Wajsberg [:julienw]]

Comment on attachment 8495759 [details] [review]
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 26

[Oleg Zasypkin [:azasypkin]]

Comment on attachment 8495759 [details] [review]
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 27

[Steve Chung [:steveck]]

Comment on attachment 8495759 [details] [review]
GitHub pull request URL

Looks great! It's nice to see more feature and new utils invented :)

Comment 28

[Oleg Zasypkin [:azasypkin]]

(In reply to Steve Chung [:steveck] from comment #27)
> Comment on attachment 8495759 [details] [review]
> 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

Comment 29

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 30

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

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

Comment 31

[Shing Lyu [:shinglyu]]

Attachment: MozTrap Test Cases