Steve Chung [:steveck] Assignee
	Description • 10 years ago

+++ This bug was initially created as a clone of Bug #871432 +++

I miss the date and time when each individual message has been sent or received. At the moment it seems like that those information is only occasionally available and even doesn't update. Means a message I have sent a couple of days ago is still listed with the time only. All that makes it very hard to follow a conversation.

	Steve Chung [:steveck] Assignee
	Comment 1 • 10 years ago

Sorry for creating the missleading commet...

This bug is focus on the delivery/read report icon display for new visual in thread view. attachment 8413641 [details] provides a prototype for the behavior, but I still got some conern in bug 871432 comment 55. Let move the discussion here because this issue is another story from timestamp re-position and I think we still need further discussion for the behavior.

	Julien Wajsberg [:julienw]
	Comment 2 • 10 years ago

From Victoria in bug 871432 comment 61:

Hi Guys,

I think I have missed some rationale on the change of position of the delivery icon. I the current implementation sits where the spinner does, not affecting anything else in the bubble. So i have a some questios/concerns

1. Why the need to change the icon position, since right now the icon sits where the spinner so the process would be spinner (sending) > delivered/failed/read icon as a consequence of the activity indicator after the action is finalised.

2. Why are we putting strings (failed, delivered, read) besides the icon? We'll have massive issues space wise due to localization. In this sense, since the delivery reports are not a default preset and the user intentionally activates them from settings, wouldn't they understand the icons easily? 


I find the current solution much more accurate that the proposed lately.

WDYT?

	Steve Chung [:steveck] Assignee
	Comment 3 • 10 years ago

(In reply to Julien Wajsberg [:julienw] from comment #2) 
> 1. Why the need to change the icon position, since right now the icon sits
> where the spinner so the process would be spinner (sending) >
> delivered/failed/read icon as a consequence of the activity indicator after
> the action is finalised.
I'm not sure it's a good idea to put the status to bottom. Maybe it could contain more details but also bring more challenges as you said in (2) below.
> 
> 2. Why are we putting strings (failed, delivered, read) besides the icon?
> We'll have massive issues space wise due to localization. In this sense,
> since the delivery reports are not a default preset and the user
> intentionally activates them from settings, wouldn't they understand the
> icons easily? 
I totally agree with this. It will become a huge problem if we put string information inside the content. User can open the report if they want futther details any time.

> 
> I find the current solution much more accurate that the proposed lately.
> 
> WDYT?

Another solution is we separate the original tickle icon into delivered/read icon at set them in the original position, and read icon will overpower the deliver icon if both report requested/returned. But let's wait for Visual and UX reply.

	Victoria Gerchinhoren [:vicky]
	Comment 4 • 10 years ago

Hi Guys,

Pau is providing a mockup showing the three icons to represent status:

- Failed (exclamation mark)
- Delivered (green)
- Read (blue eye)

For this we chose 3 colors thinking on the meaning of them but also in the later hierarchiy. Red stands out indicating failure, green calls attention indicating it has been recieved and status is OK, and blue is a more receeded color than the others because it is the one that will remain there indefinitely and we don't want it to compete too much with the message itself.

Mockup and assets for different sizes will be posted by Pau.

	Pau Masiá [:Pau]
	Comment 5 • 10 years ago

Hi! Here are the mockup and assets Vicky has mentioned.

	Steve Chung [:steveck] Assignee
	Comment 7 • 10 years ago

Hi Pau, the image you provided seems got different size than the original one(20 x 20) and the icon image didn't extend to the full size(see the original icon attachment). Could you please provide the icon with 20 X 20@1x and image fit to the size? Thanks.

	Victoria Gerchinhoren [:vicky]
	Comment 8 • 10 years ago

Hi Steve, 

In our system icon set we have safe areas where the icons sit, this areas have a few standard sizes to recognize where those icons go, since there are many icons that depending on the context would belong to one group or another, so if it's not a problem, we would like to stick to the safe area. 

Does this sizes really complicate your implementation?

Thanks.

	Steve Chung [:steveck] Assignee
	Comment 9 • 10 years ago

This is the original exclamation warning icon in thread view

	Steve Chung [:steveck] Assignee
	Comment 10 • 10 years ago

And this one applied the new icon. I already changed the image size in css to make sure the icon is fully extended, but you can see the icon image is still small than the original one obviously.

One reason is developer could not know the precise image size, and it might lead little inaccuracy between visual spec and actual layout. In visual spec we might want a specific padding between icon and text, but since the icon already have a safe blank area(but developer wont know the size of the area), developer need to shrink the padding value provided by spec to fit the idea layout.

If we are not so strict to the icon position and every icon will need to preserve a blank area in the future , I'm ok with this policy changes. And for this case, if you could confirm this new icon size is exactly you want, I'll be fine with these new assets.

	Victoria Gerchinhoren [:vicky]
	Comment 11 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #10)
> Created attachment 8426773 [details]
> Screen Shot 2014-05-05 at 10.50.36.png
> 
> And this one applied the new icon. I already changed the image size in css
> to make sure the icon is fully extended, but you can see the icon image is
> still small than the original one obviously.
> 
> One reason is developer could not know the precise image size, and it might
> lead little inaccuracy between visual spec and actual layout. In visual spec
> we might want a specific padding between icon and text, but since the icon
> already have a safe blank area(but developer wont know the size of the
> area), developer need to shrink the padding value provided by spec to fit
> the idea layout.
> 
> If we are not so strict to the icon position and every icon will need to
> preserve a blank area in the future , I'm ok with this policy changes. And
> for this case, if you could confirm this new icon size is exactly you want,
> I'll be fine with these new assets.

Hi Steve,

Yes I know that there's a little noise in this process and sorry about that. But it's for the sake of sharing unique icon sheets where every designer gets the material.

The new size looks ok, mainly because I preffer that all those icons share the same size and having bigger delivery report icons in every bubble would look busy and heavy. Please try to match the spacing and mostly that all icons have the same exact position, so when they change from failed to delivered there's no bouncing there, and also, they fit in the center of the spinner (so the transition from sending to failed, or sending to delivered is just smooth).

Thanks!

	Steve Chung [:steveck] Assignee
	Comment 12 • 10 years ago

Some image assets updates and display new message read icon when read report returned.

	Julien Wajsberg [:julienw]
	Comment 13 • 10 years ago

Comment on attachment 8429815 [details] [review]
Link to github

Oleg recently worked with this code so he'll be perfect to review this ;)

	Oleg Zasypkin [:azasypkin]
	Comment 14 • 10 years ago

Comment on attachment 8429815 [details] [review]
Link to github

Looks good, just one nit! r=me

	Steve Chung [:steveck] Assignee
	Comment 15 • 10 years ago

Thanks! Nits addressed and Travis is green now.
in master: 98cf4dd5509c2ec0b3db01938be0639d6fd2d8ad