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.

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

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

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.

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

Note the "Today" and "Yesterday" header. http://i.imgur.com/VqId5j4.jpg

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.

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

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)

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.

(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

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?

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.

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

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.

Silvia, any update on this ?

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

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

yep got this. on my list of things to do this week after FDN. Will post to bug when done.

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

ping Ayman

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

Unfortunately, no wireframe/design yet...

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.

Great! Thanks a lot! NI Victoria so that we don't forget about this ;)

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

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

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)

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

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

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?

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

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

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

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 :)

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.

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

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

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

(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

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

Comment on attachment 8377344 [details] 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.

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.

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

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

Oops, Omega already attached the prototype.

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

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

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.

Comment on attachment 8377344 [details] 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!

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

Comment on attachment 8377344 [details] Link to github This looks good, only one nit in the test and some tuning for the CSS.

Comment on attachment 8377344 [details] 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.

Comment on attachment 8377344 [details] Link to github I don't like the solution you used with vertical-align, so I suggested another solution. Also, other nits.

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.

Comment on attachment 8377344 [details] Link to github Suggestion addressed, thanks for the feedback!

Comment on attachment 8377344 [details] Link to github gave some early comments already but didn't try the new patch yet, so keeping the r request.

(In reply to Julien Wajsberg [:julienw] from comment #64) > Comment on attachment 8377344 [details] > 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 ;)

Comment on attachment 8377344 [details] 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?

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