A recent change (probably bug 875338) changed how the scroll to bottom used to work, in a good way. Notably, we were previously scrolling to bottom too often, and it was annoying. However, now, when we send a message, we're not scrolling to bottom anymore. Same when we receive a message belonging to that thread, although I don't know if we should here, because the user does not control this. In an ideal world, I'd rather show an in-app banner saying "hey, you've received a new message" with a link that would trigger the scroll to bottom behavior. Should not be too difficult to do, as we already have that banner. Requesting Ayman's wisdom here, as I don't see where this is specified. Additional question for you: do you think it's important enough to be fixed in 1.1 ? Depending on Ayman's answer this should be leo or could wait for 1.2. (I'd rather wait for 1.2)

(In reply to Julien Wajsberg [:julienw] from comment #0) > A recent change (probably bug 875338) changed how the scroll to bottom used > to work, in a good way. Notably, we were previously scrolling to bottom too > often, and it was annoying. > > However, now, when we send a message, we're not scrolling to bottom anymore. > > Same when we receive a message belonging to that thread, although I don't > know if we should here, because the user does not control this. In an ideal > world, I'd rather show an in-app banner saying "hey, you've received a new > message" with a link that would trigger the scroll to bottom behavior. > Should not be too difficult to do, as we already have that banner. I agree, this would be a very good solution rather than auto scrolling to the bottom of the message thread in order to show the new message (which would be rather annoying) Will slap together some wireframes tomorrow and attach to this bug > > Requesting Ayman's wisdom here, as I don't see where this is specified. > Additional question for you: do you think it's important enough to be fixed > in 1.1 ? > > Depending on Ayman's answer this should be leo or could wait for 1.2. (I'd > rather wait for 1.2) I would be happy to do this fix in 1.2 so unless there are any objections lets do that not removing needinfo to me until i have provided the wireframes.

add to backlog 891754

Ayman, I think the wireframe here would be easy to do (maybe we only need the text and the link) so that someone can move forward here ?

It's my proposal!

Please, assign this bug to me. =)

Comment on attachment 800887 [details] Pull Request link bug 905208 One reviewer is enough, Rick is busy these days, and moreover he's not a peer of the Messages app (even if he could review things if a peer ask it).

Comment on attachment 800887 [details] Pull Request link bug 905208 I reviewed things on the patch. I've seen Rick already gave some comments and that's good ! But he didn't see the whole picture (because he hasn't worked a lot with this part of the code), which gives more weight to my comment 7 :) (sorry Rick ;) ) Caio please request review again from me when you're ready !

Ayman, as you see, there is some activity on this bug, so I'd like your advice here (see comment 3), otherwise we'll need to file a follow-up with your changes.

Ayman, as you see, there is some activity on this bug, so I'd like your advice here (see comment 3), otherwise we'll need to file a follow-up with your changes.

(In reply to Julien Wajsberg [:julienw] from comment #8) > Comment on attachment 800887 [details] > Pull Request link bug 905208 > > I reviewed things on the patch. > > I've seen Rick already gave some comments and that's good ! My review was purely minor technical points that needed to be addressed. > But he didn't > see the whole picture (because he hasn't worked a lot with this part of the > code), which gives more weight to my comment 7 :) (sorry Rick ;) ) No apologies necessary.

Comment on attachment 800887 [details] Pull Request link bug 905208 Implemented reviews and tests case

Comment on attachment 800887 [details] Pull Request link bug 905208 some more comments on github I think we're close :)

Hey Tyler, We'd need a correct english message for this. This is for a notice that will be displayed when we receive a message while the thread is scrolled up. Discussed with Ayman, and our current proposal is something like: "New message from <contact>, <a>read it</a>" The text between <a> will look like a link so that the user knows this is clickable. Flagging Victoria as well, in case she can share her thought about the visual design.

wrong Tyler, sorry Tyler ;) hey Tyler, see comment 14 please, thanks !

Hey Julien, Can I see a screenshot to understand what we're talking about? Thanks!

Victoria, What Julien is talking about is in the image

Removing Ni? to me as i spoke with Julien Directly about this during the Oslo Work Week

Ayman, What did you decide? The same position of comment 14?

(In reply to Julien Wajsberg [:julienw] from comment #14) > Hey Tyler, > > We'd need a correct english message for this. This is for a notice that will > be displayed when we receive a message while the thread is scrolled up. > > Discussed with Ayman, and our current proposal is something like: > > "New message from <contact>, <a>read it</a>" > > The text between <a> will look like a link so that the user knows this is > clickable. > > Flagging Victoria as well, in case she can share her thought about the > visual design. An idea... The format of the suggested message seems likely to cause problems because of the varied lengths of names. It's likely (especially when translated) that there won't be room for the message and link. Based on the attached visual, it looks like there will be a notification in the notification bar at the top of the screen, so they will know there is a new incoming message. My suggestion would be to simply put "Jump to new message", all clickable, in the box that appears at the top of the thread, with an icon or something that visually relates it to the new message notification in the not. bar. Thoughts?

The current proposal was to _not_ send a real notification in that case, especially because we don't control them yet (ie: once they're sent, we can't "close" them), and therefore it would be weird to still have that notification once the message is read. I agree with your general issue and already talked about this with Ayman. But if we don't put the contact name, UX-wise it's not clear whether we got a message from this number of from another number. Another idea: how about reusing the "unread" symbol that we already have in the message list view, and putting it for example in front of the contact name ?

(In reply to Julien Wajsberg [:julienw] from comment #21) > Another idea: how about reusing the "unread" symbol that we already have in > the message list view, and putting it for example in front of the contact > name ? This seems like a great idea. It accomplishes the same thing as the notification, and saves us the need to put the name in the message. The icon appears next to the name in the currently open thread, and the text, to be a bit clearer, can say: "Jump to newest message" This should make it very clear that it refers to the currently viewed thread. Does this work for everyone?

Ayman, see comment 21 and comment 22. Thanks !

(In reply to tyler.altes from comment #22) > (In reply to Julien Wajsberg [:julienw] from comment #21) > > > Another idea: how about reusing the "unread" symbol that we already have in > > the message list view, and putting it for example in front of the contact > > name ? > > This seems like a great idea. It accomplishes the same thing as the > notification, and saves us the need to put the name in the message. The icon > appears next to the name in the currently open thread, and the text, to be a > bit clearer, can say: "Jump to newest message" > This should make it very clear that it refers to the currently viewed thread. > > Does this work for everyone? I share this thing. I guess that put the name of contact is a kind of duplicate message, since the user is in the conversation thread. Using the mobile facebook app as a reference, they use a banner like us, to notify the user about new messages on newsfeed. I guess I didn't understand about the unread badge. Is it possible to create a kind of prototype of this?

(In reply to Caio Lima(:caiolima) from comment #24) > (In reply to tyler.altes from comment #22) > > (In reply to Julien Wajsberg [:julienw] from comment #21) > > > > > Another idea: how about reusing the "unread" symbol that we already have in > > > the message list view, and putting it for example in front of the contact > > > name ? > > > > This seems like a great idea. It accomplishes the same thing as the > > notification, and saves us the need to put the name in the message. The icon > > appears next to the name in the currently open thread, and the text, to be a > > bit clearer, can say: "Jump to newest message" > > This should make it very clear that it refers to the currently viewed thread. > > > > Does this work for everyone? > > I share this thing. I guess that put the name of contact is a kind of > duplicate message, since the user is in the conversation thread. Ayman's proposition follows the principle of least effort. _Not_ putting the name of the contact would make the user think: is it a new message in this thread, or is it a new message elsewhere ? And then he'll remember "no, ok, if this is a new message elsewhere, the notification does not look the same". So that's a lot of effort. > > Using the mobile facebook app as a reference, they use a banner like us, to > notify the user about new messages on newsfeed. > > I guess I didn't understand about the unread badge. Is it possible to create > a kind of prototype of this? I'm still not sure of this, and I'd like to wait for Ayman's guidance before any further work.

(In reply to Julien Wajsberg [:julienw] from comment #25) > Ayman's proposition follows the principle of least effort. _Not_ putting the > name of the contact would make the user think: is it a new message in this > thread, or is it a new message elsewhere ? And then he'll remember "no, ok, > if this is a new message elsewhere, the notification does not look the > same". So that's a lot of effort. But this effort can either be resolved by putting the name in the text -- which is longer, harder to read, almost certain to cause length problems with the string, and repetitive from the name just above it -- or by putting a simple visual marker of some kind to reinforce the fact that there is a new message in this thread. The second option gets my vote for the sake of keeping the text clear and concise, but if/how/where the visual marker should appear... Ayman?

Yep, but I was explaining the whole UX process to Caio :-)

I've done some wrong things on squash+rebase

(In reply to Julien Wajsberg [:julienw] from comment #27) > Yep, but I was explaining the whole UX process to Caio :-) Thank you Julien! I guess we are only wiating for UX to finish this bug, right?

It would be preferable to see the name of the person from whom the message is from in the banner as, though it is repetitive, it reduces the end users cognitive load as they know *exactly* who the message is from. The second thing is that i am expecting the indication (blue dot icon) that we currently use to show a new message to change in the future comms track as it is not particularly strong. So its not an item within the UX to rely on. Never the less space is indeed an issue. Could i suggest that we just just the first name (or just the last name if first name is empty) in the banner. This would form enough of a connection between the content in the header and the message in the banner - and would also be robust against evolutions in icon / indicators.

(In reply to ayman maat :maat from comment #30) > It would be preferable to see the name of the person from whom the message > is from in the banner as, though it is repetitive, it reduces the end users > cognitive load as they know *exactly* who the message is from. The second > thing is that i am expecting the indication (blue dot icon) that we > currently use to show a new message to change in the future comms track as > it is not particularly strong. So its not an item within the UX to rely on. > > Never the less space is indeed an issue. Could i suggest that we just just > the first name (or just the last name if first name is empty) in the banner. > This would form enough of a connection between the content in the header and > the message in the banner - and would also be robust against evolutions in > icon / indicators. So, I'll work on this then.

As far as the message, then, it should just say "New message from (first_name)" This will seem very strange if it's the last name, but I guess it will correspond with the info at the top of the message thread, so maybe it's okay. A question: Is it necessary to put "See message" within the banner? Or should it be obvious that you tap to see it? All notifications and similar modules in Android and iPhone are tappable, but never make it explicit in text. It will seriously help the space issue if we don't use it, but I'm less familiar with our specific audience and the rest of the functions, so I'll leave it up to you guys to decide if it's necessary.

Problem is that we have other such messages that are not tappable. Therefore it might confuse the user and he might not discover it's tappable, or try to tap on other notices. But maybe that's not a problem because the user can still scroll down manually (?) Otherwise maybe an icon might be enough ?

Hey Sergi, Ayman told me you might be the best to help here, as a BB peer. We'd need a design for a tappable/clickable notice. Our idea right now is a normal notice with an icon to indicate it's tappable (for example: a finger icon) on the right or the left (I'd say the right is better). Maybe a more context-sensitive icon here could be a good idea too, could be for example a "down arrow", because the tap action will scroll the thread to the bottom. But it's really up to you, thanks in advance for your help !

(In reply to Julien Wajsberg [:julienw] from comment #34) > Hey Sergi, Ayman told me you might be the best to help here, as a BB peer. > > We'd need a design for a tappable/clickable notice. Our idea right now is a > normal notice with an icon to indicate it's tappable (for example: a finger > icon) on the right or the left (I'd say the right is better). > > Maybe a more context-sensitive icon here could be a good idea too, could be > for example a "down arrow", because the tap action will scroll the thread to > the bottom. > > But it's really up to you, thanks in advance for your help ! Hi Julien, We are not using any component with exactly the same behavior you're proposing here, so i assume this is a custom component you created for the SMS app. The most similar standard component is "Status" (you can find it here: http://buildingfirefoxos.com/building-blocks/status.html), but the main difference when compared with the one you're proposing is that "Status" is used to confirm a user action or to alert the user to a system event, and automatically disappears after some seconds. My main concern is you're using a component which looks like "Status" but behaves differently. In the case of SMS i assume the notification will disappear when the user taps on it, while "Status" disappears automatically. Taking into account that the standard behavior is the "Status" doesn't require the user to interact with it, he may try to tap on other instances of the standard "Status" used across the UI when it's not needed. IMHO what you have here is more an interaction issue. I don't think a component like the one you're proposing effectively works for this purpose. My suggestion is to use the standard "Status" component here to alert the user when a new message arrives, and let him scroll down on his own if he wants to. I can't see the advantage in creating a new component to just automatically scroll to a given point of the screen. Anyway, if you have decided to use this notification as it is, my suggestion here is that you give it a different visual treatment so it's easier to differentiate it from the "Status" BB. Another problem i see is that the component lacks affordance, because it's originally an alert not supposed to be tapped, and just adding a different color to some parts of the text doesn't invite the user to interact with it. I don't think adding an icon would help. On the contrary, it will add more visual complexity. Hope this helps.

Sergi, those were exactly our thoughts. We'd really want to be able to tap on the notice (we think it really makes sense from an UX PoV), or, at the very least, to keep it shown until the user manually scrolls to the bottom. My first plan was to have something that looks like a link inside the notice, to create the affordance to tap. But if the whole text looks like a link this is quite ugly, right ? And if we want to make only part of the text look like a link, then which part ? Adding a text for this does not fit well either. So I was hoping that you could help on this ;)

Hey Julien, The problems we're facing here are mainly 2: We should make clear you can tap the notification to perform and action, and we need to create a design that let you fit long names. I've used the "status" BB as a base to create a new component, Find attached an screenshot. As you said making text look like a link doesn't work in a mobile phone, so i thinks it's better using an action button with a clear call to action. The message will be placed on the left, next to it, and we may use an ellipsis if it doesn't fit. Using an icon doesn't make things more clear, and it adds a little bit of noise. Eventually we may use a larger banner if we want to fit more text, but my recommendation is to keep it small. After talking with Ayman we agreed that from an IxD PoV the notification should vanish in two scenarios: 1) when it is tapped 2) also when the screen is scrolled I'm also concerned about the performance of the phone when having to scroll through a long list of messages to the bottom of the screen. Have we tested that? Let me know your thoughts. Thanks!

(In reply to Sergi from comment #37) > Created attachment 810493 [details] > tappable_notification.jpg > > Hey Julien, > > The problems we're facing here are mainly 2: We should make clear you can > tap the notification to perform and action, and we need to create a design > that let you fit long names. agreed (even if we'll display only part of the full name) > > I've used the "status" BB as a base to create a new component, Find attached > an screenshot. As you said making text look like a link doesn't work in a > mobile phone, so i thinks it's better using an action button with a clear > call to action. The message will be placed on the left, next to it, and we > may use an ellipsis if it doesn't fit. Using an icon doesn't make things > more clear, and it adds a little bit of noise. Eventually we may use a > larger banner if we want to fit more text, but my recommendation is to keep > it small. agreed too, this looks very good to me :) > > After talking with Ayman we agreed that from an IxD PoV the notification > should vanish in two scenarios: > 1) when it is tapped > 2) also when the screen is scrolled That's exactly what the current patch is doing :) Just to make it cristal clear: we can tap the whole notification, not only the button, right ? Note to Caio: we can use a real button too, for accessibility reason. > > I'm also concerned about the performance of the phone when having to scroll > through a long list of messages to the bottom of the screen. Have we tested > that? This is not a problem, Gecko knows how to scroll ;) As Ayman suggested, rather than _scrolling_ we're _jumping_ (ie: no transition), so it really behaves ok. > > Let me know your thoughts. > > Thanks! Thanks to you, this is great ! Need info for the one question in the middle of my answer.

BTW, another option here may be using an icon instead of a text inside the button. That would let us giving more room to text and less to the button, but still keep component's affordance.

(In reply to Sergi from comment #39) > BTW, another option here may be using an icon instead of a text inside the > button. That would let us giving more room to text and less to the button, > but still keep component's affordance. An icon inside a button doesn't look very good in my head, but probably you can make it look good ;)

(In reply to Julien Wajsberg [:julienw] from comment #38) > (In reply to Sergi from comment #37) > > Created attachment 810493 [details] > > tappable_notification.jpg > Just to make it cristal clear: we can tap the whole notification, not only > the button, right ? > Note to Caio: we can use a real button too, for accessibility reason. I'd say yes. If the user taps anywhere in the notification the action will be triggered. Anyway i think users will try to tap the button area.

(In reply to Julien Wajsberg [:julienw] from comment #40) > (In reply to Sergi from comment #39) > > BTW, another option here may be using an icon instead of a text inside the > > button. That would let us giving more room to text and less to the button, > > but still keep component's affordance. > > An icon inside a button doesn't look very good in my head, but probably you > can make it look good ;) Yes, you are right. Lets attach to the button with text at the moment. I'm adding Arnau in needinfo just in case he can help us converting this to a building block you can use.

Maybe the only thing we'd need now is the font size measurements, if that's possible ?

All the elements i've used are from standard components we're already using. - You can check the Status here: http://buildingfirefoxos.com/building-blocks/status.html - Action (default) buttons here: http://buildingfirefoxos.com/building-blocks/buttons.html Let me know if you need any other info to build it. Thanks!

Sergi, in your attachment, there are 2 different font sizes inside the status. "New message from" is smaller than the contact name. Was that a mistake then, and should everything have the same size ?

Or should the contact name be between <strong></strong> ?

(In reply to Julien Wajsberg [:julienw] from comment #45) > Sergi, in your attachment, there are 2 different font sizes inside the > status. "New message from" is smaller than the contact name. Was that a > mistake then, and should everything have the same size ? You're right! that was my mistake. I've updated the screenshot. Now the text is the same size as in "Status"

great, looks good, thanks !

So guys, I've had a look in the design proposal. I'm still with a doubt, Are we going to use only the first name?

Actually, I'm having some problems to implement this status and the button. It looks like the "status.css" and "button.css" aren't being loaded. Hulien, I've pushed my code to see what I'm doing wrong.

Giving some Updates. I've already put the button but i have 2 questions about the implementation: 1. How can I force the text to break into two lines, as in the screenshot? 2. About big names, What will be our rule to consider that a name is big?

(In reply to Caio Lima(:caiolima) from comment #50) > So guys, I've had a look in the design proposal. > > I'm still with a doubt, Are we going to use only the first name? Hi Caio, yes as i stated in comment 30: "Could i suggest that we just use the first name (or just the last name if first name is empty) in the banner. This would form enough of a connection between the content in the header and the message in the banner"

(In reply to Julien Wajsberg [:julienw] from comment #33) > Problem is that we have other such messages that are not tappable. Therefore > it might confuse the user and he might not discover it's tappable, or try to > tap on other notices. > > But maybe that's not a problem because the user can still scroll down > manually (?) > > Otherwise maybe an icon might be enough ? banners that are actionable should have either a different visual treatment or some iconographic indicator / affordance to differentiate them... but the path to such a solution should be defined more by Visual Design, therefore it is more of a question to Sergi. happy to discuss options though :)

(In reply to Caio Lima(:caiolima) from comment #52) > Giving some Updates. I've already put the button but i have 2 questions > about the implementation: > > 1. How can I force the text to break into two lines, as in the screenshot? I think you can really use 2 elements, one for each line, so that the contact is always on the second line. > 2. About big names, What will be our rule to consider that a name is big? The second line will get "text-overflow: ellipsis; overflow: hidden; white-space: nowrap;" No need to do that yourself, gecko will do it for you :)

ping for review Julien =)

Comment on attachment 800887 [details] Pull Request link bug 905208 r=me I'll file bugs with the issues I notices while reviewing. Please squash, rebase, and ad "r=julien" in the first line of the commit log, and then add the keyword "checkin-needed" so that someone (maybe me ? ;) ) will merge it.

I guess that it's alright ;)

master: 468666880428fc4c5f4bf602ab962fd49acb427c thanks a lot !