907103 - [SMS] Focusing on the Send button is hard

Status: RESOLVED WORKSFORME

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

Description

[Jan Jongboom [:janjongboom] (inactive)]

This is on 1.1 hamachi partner release from the beginning of August.

I have the feeling that the top few pixels of the send button (or at least between send text and horizontal rule) are not focusable. I miss it about 90% of the time unless I pay attention and press lower. Probably related to bug 907102.

Comment 1

[Rick Waldron [:rwaldron]]

This is not a bug in the Messages app.

Comment 2

[Jan Jongboom [:janjongboom] (inactive)]

It's a UX flaw.

Comment 3

[kenzo Ohta]

Attachment: margin of the send button.png

Hi All

I found out this bug.
There is no action area on the top few pixels of the send button.

Comment 4

[kenzo Ohta]

Attachment: patch_907103.txt

If this issue is avobe attachment orange part, I have challenged to writte a patch.
<<patch_907103.txt>>
I want to check.
And if this doesn't have any problems, I want you to assign this issue to me.
I can't change assain.

Comment 5

[Julien Wajsberg [:julienw]]

Hi Kenzo,

thanks a lot for this patch !

I'm not sure this patch is a correct patch though. Do you know why the messages-input margin would impact the send button ? The send button is not even inside the "messages-input" div ?

At least in Firefox the send button is focussable on all its surface, so maybe there is a specific bug on the device. I'll check today.

Comment 6

[kenzo Ohta]

Hi Julien-san,

Thank you for your reply.

> Do you know why the messages-input margin would impact the send button ?
> The send button is not even inside the "messages-input" div ?

Sure, The send button is not‘include' the "messages-input" div.
I try "messages-input" set background color, so I found the send button is on "message-input" div.

My attachment<<margin_of_the_send_button.png>>'s margin:0.8rem ver has some space above send button.
So I reduce margin to 0.7rem.

Comment 7

[Julien Wajsberg [:julienw]]

send button is on "message-input" div and therefore it should take the click input.

So I don't understand the patch (and I still don't understand the bug either).

Comment 8

[Rick Waldron [:rwaldron]]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> send button is on "message-input" div and therefore it should take the click
> input.
> 
> So I don't understand the patch (and I still don't understand the bug
> either).

Same here, I've never experienced the issue reported (here or in the other similar bug about the input area)

Comment 9

[Julien Wajsberg [:julienw]]

Tested in a very current master: the top of the send button works ok for me. However, the bottom has problem and this is bug 909821 already.

jan, do you still see this bug with the top of the send button ? Maybe you can show me in Oslo next week ?

Comment 10

[Jan Jongboom [:janjongboom] (inactive)]

Yep, will do.

Comment 11

[Jan Jongboom [:janjongboom] (inactive)]

Ah, found it. Type a SMS that has 2 lines of text.

Comment 12

[Julien Wajsberg [:julienw]]

Could this be that it's not that it's hard, but rather in that case the top of the button is not well different from the background, and therefore we're tempted to tap above it ?

Comment 13

[Jan Jongboom [:janjongboom] (inactive)]

Yes, that's what I realize now. We should make that whole area tappable.

Comment 14

[Julien Wajsberg [:julienw]]

But what should we do when the input composer grows more ? We can't make the whole right area tappable.

Possible solutions: the button could have a more visible border, we could grow the button, other ?

Since we're at it, I'd prefer to see the various buttons (pick attachment and send button) on the top of the right area too: would make some of the code we have easier and less brittle, and that would make the button far from the keyboard suggestions list (I'm always afraid of taping the send button when I want to tap the suggestion on the right).

Ayman, thoughts ?

Comment 15

[ayman maat :maat]

ok, after discussing directly with Julien i agree we have problems here and am of the opinion that this is more of a visual design challenge than an IxD challenge. 
So, passing this to Silvia to look at. I have already briefed her, but ni? to Silvia so she has a clear marker.

ping me when you have a proposition to review :)

Comment 16

[Julien Wajsberg [:julienw]]

Attachment: screenshot for the problem

here we can see how the send button is blending to the top of the free space

Comment 17

[Victoria Gerchinhoren [:vicky]]

This is not an SMS bug, this affects the common controls and it is part of the Building Blocks as well, should not be fixed separately in app.

Requesting info from the Building Blocks and System Components people here.
SHould we raise a new bug for redesigning the component?

Comment 18

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

Increasing the input height of the text area is something custom for SMS app. But if we need to change the visual style of the button, this should be done in input areas BB.

Comment 19

[Julien Wajsberg [:julienw]]

Arnau, then, could we do it ?

clearly, all buttons that I see on buildingfirefoxos.com all look framed ([1] [2]). Our button here is not framed just because the input height is growing. That's why I don't agree at all with the argument "all other buttons are done like this", this is simply visually not true.

[1] http://buildingfirefoxos.com/building-blocks/buttons.html
[2] http://buildingfirefoxos.com/building-blocks/input-areas.html

Comment 20

[Arnau March [:arnau] ( not working in Firefox OS anymore :( )]

I could change that as soon as we have a new visual proposal.

Comment 21

[Sergi]

I agree with you both buttons in the input field are confusing and would be better to have them framed. This was a design decision made by the art director after quite an amount of tests, and that's why the button looks unframed right now. 

It's not an straightforward solution, and it would require further design work.

Create a new bug and assign it to me with Arnau in cc, and we will try to solve it.

Thanks.

Comment 22

[Julien Wajsberg [:julienw]]

Assigning to Sergi here.

Any update on this Sergi ?

Comment 23

[Julien Wajsberg [:julienw]]

Hey José, this was a bug assigned to Sergi. See also bug 917711.

Would love to move forward on this :) (maybe you already did with the Visual refresh ?)

Comment 24

[José Vittone]

Hi Julien, 

This button would change with the visual refresh so this bug may not apply. Working on this doesn't make sense by now. I would close these bugs and re-open it later if needed (after implementing the visual refresh on this element). 

Does it make sense?

Comment 25

[Julien Wajsberg [:julienw]]

Good for me, as long as we move forward.

Comment 26

[Julien Wajsberg [:julienw]]

Hey José, I think the new buttons are still not framed. Can we do something about this?

Comment 27

[Anthony Ricaud (:rik)]

IMHO, it's more than just framing the button. When you have two lines of SMS text, if you tap slightly higher than the button, the keyboard will close. And then you have to wait for the transition to finish, move your finger and tap the bottom of the screen.

I think a good way to solve that problem is to not capture any touch event when you tap in this area (the one that displays MMS and/or character counts). Nothing would happen (no send, no keyboard closing) so you'd still have to retry but in the same area of the screen. This is easy to do code-wise and would solve one of the most annoying pet-peeves I have while dogfooding. What do you think Ayman?

Comment 28

[ayman maat :maat]

(In reply to Anthony Ricaud (:rik) from comment #27)
> IMHO, it's more than just framing the button. When you have two lines of SMS
> text, if you tap slightly higher than the button, the keyboard will close.
> And then you have to wait for the transition to finish, move your finger and
> tap the bottom of the screen.
> 
> I think a good way to solve that problem is to not capture any touch event
> when you tap in this area (the one that displays MMS and/or character
> counts). Nothing would happen (no send, no keyboard closing) so you'd still
> have to retry but in the same area of the screen. This is easy to do
> code-wise and would solve one of the most annoying pet-peeves I have while
> dogfooding. What do you think Ayman?

I agree and I think your solution is a great idea. However the framing of the Send button is still more than necessary in order to address the existing Usability problems that we have been more than aware of since V1.0. Visual Design need to address this in their solution otherwise they are simply exacerbating a known usability issue.

Comment 29

[José Vittone]

Having tried some alternatives, I pass the ni? to Vicky since I'm leaving.

Comment 30

[Anthony Ricaud (:rik)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/17576/files

This is implementing my proposition in comment 27. The visual part could be dealt with in bug 917711.

Comment 31

[Julien Wajsberg [:julienw]]

Comment on attachment 8396339 [details]
https://github.com/mozilla-b2g/gaia/pull/17576/files

I made a simple comment on github but I can't review now since I don't have a 1.5 phone right now.

Comment 32

[Julien Wajsberg [:julienw]]

Comment on attachment 8396339 [details]
https://github.com/mozilla-b2g/gaia/pull/17576/files

r=me with nits

I filed bug 988494 for the issue we saw in B2G.

Comment 33

[Anthony Ricaud (:rik)]

Fixed the nits and landed. https://github.com/mozilla-b2g/gaia/commit/a3d4a9e35c5e5f25d4ab6035aebf422f09938688

Comment 34

[Julien Wajsberg [:julienw]]

reverted: 41436fa35f55e3addbaddf2d52d720f24a6021d6

because this makes it more difficult to touch the input when it's empty. With the patch you can't focus it if you don't type out of the placeholder text.

Comment 35

[Anthony Ricaud (:rik)]

After some investigation, this is making focus harder because adding a touchstart event on the form element attracts the fluffing algorithm. Bug 949457 will change some margins to paddings, making it impossible to tap the form element so we'll wait for bug 949457 to land before landing this one.

Comment 37

[Dietrich Ayala (:dietrich)]

This bug is killing me in daily use. The send button on Nexus 4 basically never works at all when the keyboard is up.

It works fine with keyboard is down - first touch works every time.

Comment 38

[Julien Wajsberg [:julienw]]

Dietrich, are you sure you type the send button, or is it possible that you tap the space above, in an unconscious way to avoid the keyboard?

Comment 39

[Dietrich Ayala (:dietrich)]

Seriously. I'm hitting the [send] button. I'm not hitting anything else. The [send] button is the button I'm hitting. I'm not *not* hitting the [send] button.

PS: I'm hitting the [send] button.

PPS: https://www.youtube.com/watch?v=ZG_xNbVMmIA

Comment 40

[Stephany Wilkes]

I'm flagging Wilfred to ensure we can get this into the backlog. This is crazy.

Comment 41

[Anthony Ricaud (:rik)]

We already have a patch for this (it even landed but got backed out). See comment 35 for when this will land.

Comment 42

[Stephany Wilkes]

Comment on attachment 8396339 [details]
https://github.com/mozilla-b2g/gaia/pull/17576/files

This patch should be flagged for ui-review?. Flagging Victoria on Comms and Harly on Building Blocks. Both must give this ui-review+ in order for it to ship.

Comment 43

[Anthony Ricaud (:rik)]

This was already "ui-reviewed" in comment 28. There are no visual updates, just a change in UX.

The visual update will be done in bug 917711. That's where we need a ui-review.

Comment 44

[Julien Wajsberg [:julienw]]

Hey Stephany, I think we're all overreacting here :)

I believe the issue Dietrich is seeing is different to what we were trying to fix here. This could be a regression in the event fluffing code, and I'd suggest filing a separate bug for this.

What Anthony's patch does here is something different: it's preventing the keyboard from hiding when we miss the send button.

Therefore can we remove the ui review request?

Comment 45

[Stephany Wilkes]

Got it, rik. Makes sense. Thanks!

Comment 46

[Julien Wajsberg [:julienw]]

Comment on attachment 8396339 [details]
https://github.com/mozilla-b2g/gaia/pull/17576/files

Removing the ui-review requests then ! Thanks

Comment 47

[Anthony Ricaud (:rik)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/19864

Let's try again now that bug 949457 landed.

BTW, Dietrich, I think what you are seeing could be bug 984897.

Comment 48

[Julien Wajsberg [:julienw]]

Comment on attachment 8432379 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19864

Sorry, let's wait for the various bugs happening here...

Comment 49

[Anthony Ricaud (:rik)]

SMS has received lots of UX changes and I'm not experiencing this anymore.