[sms][mms] display the received time inside the sms/mms box

RESOLVED FIXED in Firefox OS v2.0

Status

Firefox OS
Gaia::SMS
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: whimboo, Assigned: steveck)

Tracking

unspecified
2.0 S2 (23may)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

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

Details

(Whiteboard: [p=2])

Attachments

(6 attachments)

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.
Flags: needinfo?(aymanmaat)
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.
Duplicate of this bug: 901636
Duplicate of this bug: 901467
Summary: [SMS] No date and time displayed in message list → [sms][mms] display the received time inside the sms/mms box
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.
Flags: needinfo?(aymanmaat)
Silvia, any update on this ?
Flags: needinfo?(sfer.ux)

Comment 18

4 years ago
Ayman needed it to do some work(wireframes)before doing any designs. Waiting for that.
Flags: needinfo?(sfer.ux)
So adding a needinfo on Ayman do that it's clear we're waiting for him. Thanks Silvia !
Flags: needinfo?(aymanmaat)

Comment 20

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

Will post to bug when done.
Blocks: 891754
Duplicate of this bug: 910072
There was a nomination in the dupe so I nominate here too.
blocking-b2g: --- → koi?
No longer blocks: 891754
Blocks: 891754
blocking-b2g: koi? → ---
ping Ayman
Whiteboard: [mentor=:julienw][good-first-bug]

Comment 24

4 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

Updated

4 years ago
Flags: needinfo?(felash)
Unfortunately, no wireframe/design yet...
Flags: needinfo?(felash)

Updated

4 years ago
Whiteboard: [mentor=:julienw][good-first-bug] → [mentor=:julienw][good first bug]

Comment 26

4 years ago
Created attachment 825871 [details]
FFOS_MessageApp_DateTimeStamp_V1.3_20131101_V0.1.pdf

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.
Flags: needinfo?(aymanmaat)
Great! Thanks a lot!

NI Victoria so that we don't forget about this ;)
Flags: needinfo?(vpg)

Comment 28

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

Comment 29

4 years ago
Created attachment 8334507 [details]
Sequence of the sticky date indicator
Thanks José!

I was supposed to send you a mail and completely forgot, good to see an update ;)
Flags: needinfo?(vpg)

Comment 31

4 years ago
Created attachment 8334511 [details]
SMS/MMS display message time SPEC

Comment 32

4 years ago
Created attachment 8334512 [details]
SMS_MMS_Date_Keyboard_Open
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 34

4 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..
Attachment #8334511 - Attachment description: 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.. → SMS/MMS display message time SPEC
(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!

Comment 36

4 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?

Comment 37

4 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.
(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.
Flags: needinfo?(vpg)

Updated

4 years ago
blocking-b2g: --- → 1.3?
its not blocking 1.4 land when ready and ask for approval.
blocking-b2g: 1.3? → -
Flags: needinfo?(schung)
(Assignee)

Comment 40

4 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 :)
Assignee: nobody → schung
Flags: needinfo?(schung)
(Assignee)

Comment 41

4 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.
Flags: needinfo?(vittone)
Flags: needinfo?(aymanmaat)
(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'

Comment 43

4 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.
Flags: needinfo?(schung)
(Assignee)

Comment 44

4 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...
Flags: needinfo?(schung)

Comment 45

4 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
(Assignee)

Comment 46

4 years ago
Created attachment 8377344 [details] [review]
Link to github

Hi Julien, this patch create another field at the button of the bubble, and with a sticky date header at top of the view.
Attachment #8377344 - Flags: review?(felash)
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.
Attachment #8377344 - Flags: review?(felash)
(Assignee)

Updated

4 years ago
Status: NEW → ASSIGNED
blocking-b2g: - → backlog
Duplicate of this bug: 1000793
Blocks: 950175
Flags: needinfo?(vittone)
Flags: needinfo?(aymanmaat)
(Assignee)

Comment 49

4 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.
Flags: needinfo?(vpg)
Flags: needinfo?(ofeng)
(Assignee)

Updated

4 years ago
Whiteboard: [mentor=:julienw][good first bug] → [mentor=:julienw][good first bug] [p=2]
Whiteboard: [mentor=:julienw][good first bug] [p=2] → [p=2]
Created attachment 8413641 [details]
1G.gif

(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.
Flags: needinfo?(vpg)
Flags: needinfo?(ofeng)
(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.
feature-b2g: --- → 2.0
(Assignee)

Updated

4 years ago
Target Milestone: --- → 2.0 S2 (23may)
(Assignee)

Comment 53

4 years ago
Hi Vicky, could you provide the small icon for deliver/read status in the prototype(and for different device pixal ratio)? thanks.
Flags: needinfo?(vpg)
Blocks: 1008277
(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.
Flags: needinfo?(schung)
(Assignee)

Comment 55

4 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.
Flags: needinfo?(schung) → needinfo?(ofeng)
(Assignee)

Comment 56

4 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!
Attachment #8377344 - Flags: review?(felash)
(Assignee)

Updated

4 years ago
Blocks: 1010093
(Assignee)

Updated

4 years ago
No longer blocks: 1010093
(Assignee)

Comment 57

4 years ago
Since I created bug 1010093 for delivery/read report specific issue, remove ni? for visual and UX.
Flags: needinfo?(vpg)
Flags: needinfo?(ofeng)
Comment on attachment 8377344 [details] [review]
Link to github

This looks good, only one nit in the test and some tuning for the CSS.
Attachment #8377344 - Flags: review?(felash)
(Assignee)

Comment 59

4 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.
Attachment #8377344 - Flags: review?(felash)
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.
Attachment #8377344 - Flags: review?(felash)
Comment hidden (obsolete)
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.
Flags: needinfo?(schung)
Flags: needinfo?(ofeng)
(Assignee)

Comment 63

4 years ago
Comment on attachment 8377344 [details] [review]
Link to github

Suggestion addressed, thanks for the feedback!
Attachment #8377344 - Flags: review?(felash)
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.
(Assignee)

Comment 65

4 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 ;)
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?
Attachment #8377344 - Flags: review?(felash) → review+
(Assignee)

Comment 67

4 years ago
Suggestion addressed and Travis is only failed in Calendar integration test, thanks for the review!
master: 6786c63a1d46a351094bd9fcef43199b34a30390
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Updated

4 years ago
status-b2g-v2.0: --- → fixed
Duplicate of this bug: 1022139
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.