Closed Bug 1010093 Opened 8 years ago Closed 8 years ago

[Message] Visual refresh for delivery/read report icon in thread view

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S3 (6june)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: steveck, Assigned: steveck)

References

Details

(Whiteboard: [p=1])

Attachments

(6 files)

+++ 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.
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.
No longer depends on: 871432
Summary: [sms][mms] display the received time inside the sms/mms box → [Message] Visual refresh for delivery/read report icon in thread view
Flags: needinfo?(vpg)
Flags: needinfo?(ofeng)
No longer blocks: sms-sprint-1
Whiteboard: [p=2]
Target Milestone: --- → 2.0 S3 (6june)
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?
Flags: needinfo?(schung)
(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.
Flags: needinfo?(schung)
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.
Flags: needinfo?(vpg)
Hi! Here are the mockup and assets Vicky has mentioned.
Attached file Assets. PNG. Sms
blocking-b2g: --- → backlog
feature-b2g: --- → 2.0
Flags: needinfo?(ofeng)
Attached image original.png
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.
Flags: needinfo?(b.pmm)
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.
Flags: needinfo?(b.pmm) → needinfo?(schung)
This is the original exclamation warning icon in thread view
Flags: needinfo?(schung)
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.
Flags: needinfo?(vpg)
(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!
Flags: needinfo?(vpg)
Blocks: sms-sprint-2
Whiteboard: [p=1]
Attached file Link to github
Some image assets updates and display new message read icon when read report returned.
Attachment #8429815 - Flags: review?(felash)
Comment on attachment 8429815 [details] [review]
Link to github

Oleg recently worked with this code so he'll be perfect to review this ;)
Attachment #8429815 - Flags: review?(felash) → review?(azasypkin)
Comment on attachment 8429815 [details] [review]
Link to github

Looks good, just one nit! r=me
Attachment #8429815 - Flags: review?(azasypkin) → review+
Thanks! Nits addressed and Travis is green now.
in master: 98cf4dd5509c2ec0b3db01938be0639d6fd2d8ad
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1047249
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.