Henrik Skupin [:whimboo][⌚️UTC+1] Reporter
	Description • 11 years ago

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.

	Gene Lian (I already quit Mozilla)
	Comment 1 • 11 years ago

(In reply to Henrik Skupin (:whimboo) from comment #0)
> I miss the date and time when each individual message has been sent or
  ^^^^^^^^^^^^^^^^^^^^^^^^
What do you mean you "miss" the date and time? Could you please elaborate more on this?

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

I guess you're saying you used to send/receive the SMS with a wrong date & time. However, after you reset the date & time from the Settings App, the previous SMS messages are still associated with the old time, which should be updated to the new time instead?

If yes, why is it a bug? It sounds reasonable to me to mark the SMS messages with the current system time.

	Henrik Skupin [:whimboo][⌚️UTC+1] Reporter
	Comment 2 • 11 years ago

(In reply to Gene Lian [:gene] from comment #1)
> > I miss the date and time when each individual message has been sent or
>   ^^^^^^^^^^^^^^^^^^^^^^^^
> What do you mean you "miss" the date and time? Could you please elaborate
> more on this?

Only for some of the messages within a thread the date and time is visible. Lets say I have sent a message 2 days ago, so I still see the time only. A reply happened yesterday, but it doesn't show any date and time in the message list.

> I guess you're saying you used to send/receive the SMS with a wrong date &
> time. However, after you reset the date & time from the Settings App, the
> previous SMS messages are still associated with the old time, which should
> be updated to the new time instead?

No, I don't have changed any date/time settings. It's just about not displaying / updating the time data for entries in the message list.

	Gene Lian (I already quit Mozilla)
	Comment 3 • 11 years ago

OK, got it. Sorry for my misunderstanding. For this bug, I believe this is a Gaia issue because the Gecko has exposed the associated received/sent time for each SMS/MMS message.

Cc'ing Gaia folks.

	Rick Waldron [:rwaldron]
	Comment 4 • 11 years ago

> Only for some of the messages within a thread the date and time is visible. Lets say I have 
> sent a message 2 days ago, so I still see the time only. A reply happened yesterday, but it 
> doesn't show any date and time in the message list.

The problem is that the design puts all messages under "date headers" in the thread view, so you can assume all messages that appear under "Today" are from today, so it makes sense to indicate the time, but not repeat the date (because we know these messages are from today)

	Rick Waldron [:rwaldron]
	Comment 5 • 11 years ago

Note the "Today" and "Yesterday" header.

http://i.imgur.com/VqId5j4.jpg

	Henrik Skupin [:whimboo][⌚️UTC+1] Reporter
	Comment 6 • 11 years ago

This is not satisfying and hides important information about the time the message has been sent. I needed that in one case but I'm unable to retrieve that information. On Android you can tap onto a message and get the message details. If we would have something like that, all would be fine.

	Rick Waldron [:rwaldron]
	Comment 7 • 11 years ago

Henrik, I'm sorry that you don't find that this satisfies your requirements. I'll defer to Ayman for more info.

	Tim Maks van den Broek [:mad_maks]
	Comment 8 • 11 years ago

I am not sure this bug is about the same issue as i see. the screenshot in #5 is the main view but if you go to one thread (with the balloons) a the sms are also threaded in today, yesterday etc.. The first sms of the day has a time but the second one has no time and you can't see if it send at the same time ore 2 hours later.

I think it need the time in every balloon (or next to it)

	Borja Salguero [:borjasalguero]
	Comment 9 • 11 years ago

Hi Tim,
This is actually a UX requirement. All messages will be grouped in a 'daily' group, and in the latest period of time of 10mins. So if you receive 3 messages today, for example:
[10:23] Hola!
[12:12] Hey!
[12:13] How are you?

You will see:
[Today]
Hola!
[12.12]
Hey!
How are you?

Last 2 messages are grouped because were sent within the last 10 min period.

	Tim Maks van den Broek [:mad_maks]
	Comment 10 • 11 years ago

(In reply to Borja Salguero [:borjasalguero] from comment #9)
> Hi Tim,
> This is actually a UX requirement. All messages will be grouped in a 'daily'
> group, and in the latest period of time of 10mins. So if you receive 3
> messages today, for example:
> [10:23] Hola!
> [12:12] Hey!
> [12:13] How are you?
> 
> You will see:
> [Today]
> Hola!
> [12.12]
> Hey!
> How are you?
> 
> Last 2 messages are grouped because were sent within the last 10 min period.

But it groups the day, not just the last 10 min

10:23 hello
16:00 goodbye

is

today 10:23pm
hello
goodbye

so you don't see that the last one is send hours later

Keon with build 20130630111001

	Borja Salguero [:borjasalguero]
	Comment 11 • 11 years ago

It should be something like that (Imagine that when the example was executed, the time was 12:14):
> [10:23] Hola!
> [12:12] Hey!
> [12:13] How are you?
 
You should see:
[Today]
Hola!
[Today 12.12]
Hey!
How are you?

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 12 • 11 years ago

But it isn't with Unagi and Gaia 1.1.0.0-prerelease 20130705230210.

The messages are group by date, the date and the time of the first SMS are shown as header of the first SMS (and it doesn't use relative dates, it uses "06.07.2013" instead of "Today").

Makes a missed SMS "Will arrive in 2 hours" pretty void.

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 13 • 11 years ago

Further information: The date-time header uses the time of the last sms in that conversation.

	Julien Wajsberg [:julienw]
	Comment 16 • 11 years ago

Removing Ayman's need info as we discussed about this IRL and we very much want to do it. Please wait for Silvia's visual design before doing any work.

bug 901453 will address the 'I want to see when the message was actually sent' use case.

	Julien Wajsberg [:julienw]
	Comment 17 • 11 years ago

Silvia, any update on this ?

	Silviaf
	Comment 18 • 11 years ago

Ayman needed it to do some work(wireframes)before doing any designs. Waiting for that.

	Julien Wajsberg [:julienw]
	Comment 19 • 11 years ago

So adding a needinfo on Ayman do that it's clear we're waiting for him. Thanks Silvia !

	ayman maat :maat
	Comment 20 • 11 years ago

yep got this. on my list of things to do this week after FDN.

Will post to bug when done.

	Julien Wajsberg [:julienw]
	Comment 22 • 11 years ago

There was a nomination in the dupe so I nominate here too.

	Julien Wajsberg [:julienw]
	Comment 23 • 11 years ago

ping Ayman

	Madana Manjunatha
	Comment 24 • 11 years ago

Hi Julien / Ayman / Silvia,

Any updates on this? If the wireframes for the new design are ready, I will take up this bug.


Regards,
Manjunatha

	Julien Wajsberg [:julienw]
	Comment 25 • 11 years ago

Unfortunately, no wireframe/design yet...

	ayman maat :maat
	Comment 26 • 11 years ago

Thanks for flagging this to me again Julien.

Pull out from forthcoming message app 1.3 wireframe pack (V7.0) attached for your reference. 

I will brief the visual designer on this on Monday

Sent and Received Date will also appear in the message detail card which will also be part of the seventh edition of the wireframe pack.

	Julien Wajsberg [:julienw]
	Comment 27 • 11 years ago

Great! Thanks a lot!

NI Victoria so that we don't forget about this ;)

	ayman maat :maat
	Comment 28 • 11 years ago

(In reply to Julien Wajsberg [:julienw] from comment #27)
> Great! Thanks a lot!
> 
> NI Victoria so that we don't forget about this ;)

I think this will be picked up be another designer, i will confirm on Monday.

	Julien Wajsberg [:julienw]
	Comment 30 • 11 years ago

Thanks José!

I was supposed to send you a mail and completely forgot, good to see an update ;)

	Julien Wajsberg [:julienw]
	Comment 33 • 11 years ago

hey José, we don't have a sticky header in the thread view.

However, we have the "carrier" line that is sometimes absent (in group mms threads for example)

	José Vittone
	Comment 34 • 11 years ago

Comment on attachment 8334511 [details]
SMS/MMS display message time SPEC

Hi guys, here are the visual spec for this.  Take into account that some elements have different states, mainly the sticky header, when changing from one day to another.  Please ask me if you have Q..

	Julien Wajsberg [:julienw]
	Comment 35 • 11 years ago

(In reply to Julien Wajsberg [:julienw] from comment #33)
> hey José, we don't have a sticky header in the thread view.

Ok, I get it, you added it in this visual.

I'll file another bug for this, thanks!

	José Vittone
	Comment 36 • 11 years ago

Hey Julien, 

- Regarding the sticky header, seems to be necessary in this case. If there are any problem on implementing it, we should ask Ayman for a workaround. 
- If the carrier is absent, the visual is the same. Do you think is necessary an example for that case?

	José Vittone
	Comment 37 • 11 years ago

(In reply to Julien Wajsberg [:julienw] from comment #35)
> (In reply to Julien Wajsberg [:julienw] from comment #33)
> > hey José, we don't have a sticky header in the thread view.
> 
> Ok, I get it, you added it in this visual.
Yes, I messed up with the attachments and its description.
 
> I'll file another bug for this, thanks!
Arnau told me that there is a css solution that may helps.

	Julien Wajsberg [:julienw]
	Comment 38 • 11 years ago

(In reply to José Vittone from comment #37)

> > I'll file another bug for this, thanks!
> Arnau told me that there is a css solution that may helps.

Yep, "position:sticky", but it's not enabled yet ;)

Don't worry, we already have a FixedHeader library that we use for the thread list, it's just that it's not the scope of this bug.

	Wilfred Mathanaraj [:WDM]
	Comment 39 • 11 years ago

its not blocking 1.4 land when ready and ask for approval.

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

Although it's not a blocking issue, user could gain better use experience by display the timestamp right inside the message bubble. Since it is ignored for months, I might kick off when I have free cycle. But please feel free to steal a good first bug :)

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

Although this question is belongs to delivery report display inside message bubble, it is related to this timestamp re-layout because they will both appear at the bottom of the bubble.

Hi Ayman, I remember you said we need the remove the delivery tickle in the bubble and just showing the 'delivered'/'read' text at the bottom or a short period of time. Could you please update the WF about the delivery display here or in bug 919977? We need the behavior about duration for showing the text exist in the bubble and other complex scenario like:
- What if delivered and read event start almost at the same time(Notice that a message could have multiple receivers and each of receiver will have both information to update)? 
- If the message content is shorter then timestamp, how we handle the message bubble size when we need to display 'delivered'/'read' text? It seems weird to change the bubble size dynamically when user got the event, but preserving space for status text seems not a great ux either...

Jose, we will also need your help to provide a precise visual spec got these string's position in the bubble. But a finalized WF spec would be top priority here.

	Tim Maks van den Broek [:mad_maks]
	Comment 42 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #41)

> - If the message content is shorter then timestamp, how we handle the
> message bubble size when we need to display 'delivered'/'read' text? It
> seems weird to change the bubble size dynamically when user got the event,
> but preserving space for status text seems not a great ux either...

Note that for localization we need even more space, I.e. 'read' is in dutch 'gelezen'

	ayman maat :maat
	Comment 43 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #41)
> Although this question is belongs to delivery report display inside message
> bubble, it is related to this timestamp re-layout because they will both
> appear at the bottom of the bubble.
> 
> Hi Ayman, I remember you said we need the remove the delivery tickle in the
> bubble and just showing the 'delivered'/'read' text at the bottom or a short
> period of time. Could you please update the WF about the delivery display
> here or in bug 919977? We need the behavior about duration for showing the
> text exist in the bubble and other complex scenario like:
> - What if delivered and read event start almost at the same time(Notice that
> a message could have multiple receivers and each of receiver will have both
> information to update)? 
> - If the message content is shorter then timestamp, how we handle the
> message bubble size when we need to display 'delivered'/'read' text? It
> seems weird to change the bubble size dynamically when user got the event,
> but preserving space for status text seems not a great ux either...
> 
> Jose, we will also need your help to provide a precise visual spec got these
> string's position in the bubble. But a finalized WF spec would be top
> priority here.

ok I am going to discuss this with Jose and provide you with clear direction. Is this the complete list of items regarding delivery read timestamp and text you require clarity on or are there more? please list all cases if there are more so i can close this in one pass. 

leaving ni? to me until i provide direction.
ni? to Steve to confirm whether or not there are more cases to be covered.

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

For now, outgoing message will only have delivery/read status need to display. But IMO keeping the status string(or maybe icon) permanently would be more convenient than just flash when message is delivered/read. As an user, I just want to make sure the message is delivery/read most of time, but I would not keep my eyes on the screen. Although we will have proactive notification to notify user message status change, they could not know which message's status changed while they launch message app from notification. However, keeping the status string in the bubble permanently will lead another concern about how we handle multiple receivers case. Showing the count for 2 status seems tedious...

	ayman maat :maat
	Comment 45 • 10 years ago

(In reply to Steve Chung [:steveck] from comment #44)
> For now, outgoing message will only have delivery/read status need to
> display. But IMO keeping the status string(or maybe icon) permanently would
> be more convenient than just flash when message is delivered/read. As an
> user, I just want to make sure the message is delivery/read most of time,
> but I would not keep my eyes on the screen. Although we will have proactive
> notification to notify user message status change, they could not know which
> message's status changed while they launch message app from notification.
> However, keeping the status string in the bubble permanently will lead
> another concern about how we handle multiple receivers case. Showing the
> count for 2 status seems tedious...

Yep I hear exactly what you are saying Steve. These are pretty much all the points and concerns Jose and I discussed before we delivered the prototype to you. Ok. I am going to sit down with Jose and put together a full spec for you that will illustrate how this will behave. Will ping you with it in a few days.

leaving ni? to me until I provide direction

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

Hi Julien, this patch create another field at the button of the bubble, and with a sticky date header at top of the view.

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

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

If we do the position: sticky now, we need to remove the old behavior that generates a header every 10 minutes.

But I don't know if we should implement the "position: sticky" now since we delayed the visual refresh. For example, it looks really strange when there is a carrier subheader.

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

Hi Vicky/Omega,
About the comment 44 and comment 45, could you provide some solution for the delivery/read icon position? Ayman proposed to add the delivery/read string after the timestamp at bottom and fade out aftre a timeout. If you all agreed with his idea, could you update the prototype for that? or you have another thought for this scenario?

Another thing is julien's concern in comment 47 that it might look strange to put the sticky header in the thread view especially when carrier subheader displayed. Omega said maybe we could leave the date in the same position instead of stick to the top. But it would be great if you could have a conclusion with a prototype update for that, thanks.

	Omega Feng [:Omega] [:馮於懋]
	Comment 50 • 10 years ago

(In reply to Steve Chung [:steveck](PTO until 5/12) from comment #49)
> Hi Vicky/Omega,
> About the comment 44 and comment 45, could you provide some solution for the
> delivery/read icon position? Ayman proposed to add the delivery/read string
> after the timestamp at bottom and fade out aftre a timeout. If you all
> agreed with his idea, could you update the prototype for that? or you have
> another thought for this scenario?

Vicky and I have a conclusion. See the attachment for reference.

> Another thing is julien's concern in comment 47 that it might look strange
> to put the sticky header in the thread view especially when carrier
> subheader displayed. Omega said maybe we could leave the date in the same
> position instead of stick to the top. But it would be great if you could
> have a conclusion with a prototype update for that, thanks.

Just leave the date on the scrollable page instead of sticking it at top.

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

(In reply to Steve Chung [:steveck](PTO until 5/12) from comment #49)
> Hi Vicky/Omega,
> About the comment 44 and comment 45, could you provide some solution for the
> delivery/read icon position? Ayman proposed to add the delivery/read string
> after the timestamp at bottom and fade out aftre a timeout. If you all
> agreed with his idea, could you update the prototype for that? or you have
> another thought for this scenario?
> 
> Another thing is julien's concern in comment 47 that it might look strange
> to put the sticky header in the thread view especially when carrier
> subheader displayed. Omega said maybe we could leave the date in the same
> position instead of stick to the top. But it would be great if you could
> have a conclusion with a prototype update for that, thanks.

Steve,
I am attaching a prototype Jose did for this showing the delivery report position and behaviour.

More comments on this should be fom Omegas side.

Thanks!

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

Oops, Omega already attached the prototype.

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

Hi Vicky, could you provide the small icon for deliver/read status in the prototype(and for different device pixal ratio)? thanks.

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

(In reply to Steve Chung [:steveck] from comment #53)
> Hi Vicky, could you provide the small icon for deliver/read status in the
> prototype(and for different device pixal ratio)? thanks.

Sure, I am on it. But isn't there a bug specifically for this? leaving the NI as a reminder.

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

Comment on attachment 8413641 [details]
1G.gif

Hi Vicky, I just had a discussion with Omega, I raised some questions about the prototype:
1) If the message content is shorter then time + status string length, should we adjust the length dynamically, or leave a sufficient length for the the status string? Dynamic width change might be annoying while status changes, but user won't see the unnecessary space in the bubble; leaving the sufficient at first could avoid the width changing, but it got redundant space in some case(before report received or status string is much shorter than preserved space).
2) This prototype seems missing the multipule recipient case, how could we display the status if someone already got the report but someone didn't, or in the more complecated case, we request both delivery and read report for all the receivers?

Since the report display part might need more discussion, I will give a patch simply for changing the timestamp position and create another bug for report icon issue.

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

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

Hi Julien, I polish the old patch again with some changes:
- Remove the sticky header as your & Omega's suggestion.
- Remove the last message block so that block will be only classified by date.
Thanks!

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

Since I created bug 1010093 for delivery/read report specific issue, remove ni? for visual and UX.

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

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

This looks good, only one nit in the test and some tuning for the CSS.

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

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

Since we already set the padding just as spec required, I adjust the text position to make it close to the container bottom.

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

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

I don't like the solution you used with vertical-align, so I suggested another solution.

Also, other nits.

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

Victoria, Steve created bug 1010093 for the specific issue of the delivery/read report notification. It would be easier to have the discussion there, so I'm copying your question there.

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

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

Suggestion addressed, thanks for the feedback!

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

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

gave some early comments already but didn't try the new patch yet, so keeping the r request.

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

(In reply to Julien Wajsberg [:julienw] from comment #64)
> Comment on attachment 8377344 [details] [review]
> Link to github
> 
> gave some early comments already but didn't try the new patch yet, so
> keeping the r request.

Patch update and fixed the conflicts ;)

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

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

r=me with the "display: block" added for the time element.

I think we should eventually add "datetime" attributes to all our <time> elements, can you file a bug for this?

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

Suggestion addressed and Travis is only failed in Calendar integration test, thanks for the review!
master: 6786c63a1d46a351094bd9fcef43199b34a30390