877683 - [MMS] Compose field obscured by subheader

Status: VERIFIED FIXED

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

Description

[Mike Pennisi [:jugglinmike]]

Steps to reproduce:

1. Open an existing message thread
2. Input text until the Compose field has grown to its maximum height

Expected result: The compose area is fully visible
Actual result: The subheader (which contains the "Carrier" message) obscures the top of the input field

Comment 1

[Mike Pennisi [:jugglinmike]]

Hi Ayman,

I filed this after speaking with Julien, but now I'm not sure this is a bug. The design specification does not describe what should happen in this case, so I wanted to check with you.

For context: the "subheader" contains the following UI elements:

- The "To" field (when creating a new thread)
- The "Carrier" notification
- The "Max MMS Size Limitation" notification
- The "Convert to MMS/SMS" notification

It seems to me that the "To" field should not be overlaid on the Compose input area, but that the other three elements (the notifications) were designed specifically as overlays. They have semi-transparent backgrounds and normally render on top of messages in the thread view. Therefore, it seems odd to implement special behavior to ensure that prevents the Compose input area from rendering beneath them.

Would you mind clarifying how the Compose input field should render in relation to these elements?

Thanks!

Comment 2

[Mike Pennisi [:jugglinmike]]

Attachment: Comparison of how notifications might interact with Compose field

This demonstrates two possible interactions between the "notification"-style elements (enumerated in Comment 1) and the Compose entry field. Although the notifications were designed to render on top of the Message thread, this behavior may not be appropriate for editable text. Note that the message thread is partially visible beneath the notification in the rightmost example.

Comment 3

[Dietrich Ayala (:dietrich)]

As Corey reminded me, this is easy to hit with keyboard up. Blocking+.

Comment 4

[Borja Salguero [:borjasalguero]]

Hi Mike. The requirement here *was* that the input should reach the main header, hiding the 'carrier' info only while editing, letting the user to use the max. space available (the same as intention as in the the to-field). It could be done removing https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/style/sms.css#L851 and checking the other 'z-index' for ensuring the right behaviour of the layers.

We should wait Ayman for confirming if we want to keep this behaviour (this is the one than you can test in v1.0.1) or change it to fit the requirements.

Comment 5

[ayman maat :maat]

(In reply to Dietrich Ayala (:dietrich) from comment #3)
> As Corey reminded me, this is easy to hit with keyboard up. Blocking+.

how do you mean Dietrich? can you give more detail?

Comment 6

[ayman maat :maat]

(In reply to Mike Pennisi [:jugglinmike] from comment #2)
> Created attachment 756602 [details]
> Comparison of how notifications might interact with Compose field
> 
> This demonstrates two possible interactions between the "notification"-style
> elements (enumerated in Comment 1) and the Compose entry field. Although the
> notifications were designed to render on top of the Message thread, this
> behavior may not be appropriate for editable text. Note that the message
> thread is partially visible beneath the notification in the rightmost
> example.

Hi Mike. 
Thanks for the screenshots. 

Just a bit of feedback: We need to ensure that when the user draws down the message input area that they can access the very 1st line of text that was input. This needs to be the case with the keyboard open or closed when either a new message is being composed or they are replying to an existing thread. We need to give them access to the 1st line so that they can read it AND so they can edit its contents.

referring to HTML5_SMS-MMSUserStorySpecifications_20130503_V8.0 page 42. The first wireframe on the left illustrates what i believe will be the maximum area on the vertical that message input field will need to clear in order to achieve what i wrote in the 1st paragraph of this comment.  Reading the screen zones of the wireframe from top to bottom. 

<zone 1> permanent on the screen: header indicating number of respondents and providing a back CTA.
<zone 2> permanent on the screen: To field feeding back to the end user who the new message will be sent to.
<zone 3> temporary on the screen: message informing the user that they have reached the maximum length of the message.   This is your curve ball because it is only present on the screen when the user has reached the maximum length of the message… but once it appears it sits on the screen permanently and therefore we need to ensure that the message input field when pulled down will also clear it. 

ping me if you want to discuss more tonight (my time).

Comment 7

[Mike Pennisi [:jugglinmike]]

Hey Ayman,

Thanks for the additional detail. The functionality you've described in Comment 6 differs from the examples in attachment 756602 [details] and the description in comment 4.

As it happens, the specified behavior is far more technically challenging to implement (specifically requiring a lot of special-case logic). I will try to design a few alternatives that respect the "Do not block user input" requirement, and I'll contact you via Skype to decide if we can find an acceptable compromise.

Comment 8

[ayman maat :maat]

(In reply to Mike Pennisi [:jugglinmike] from comment #7)
> Hey Ayman,
> 
> Thanks for the additional detail. The functionality you've described in
> Comment 6 differs from the examples in attachment 756602 [details] and the
> description in comment 4.
> 
> As it happens, the specified behavior is far more technically challenging to
> implement (specifically requiring a lot of special-case logic). I will try
> to design a few alternatives that respect the "Do not block user input"
> requirement, and I'll contact you via Skype to decide if we can find an
> acceptable compromise.

hey Mike i am sorry the specified behavior poses more challenges than it solves, that totally wasn't the intention. Sure, just ping me when your ready and lets see how we can work towards a solution.

Comment 9

[Mike Pennisi [:jugglinmike]]

Attachment: Video of the proposed solution running in Nightly

Hi Ayman,

I've attached a short recording to demonstrate the changes I implemented today. Please let me know if this meets your expectations and if there is some functionality I forgot to show!

Comment 10

[Mike Pennisi [:jugglinmike]]

Attachment: Implement specified "subheader-Compose" interaction

See commit message for technical explanation of specific changes.

Since this patch involves subtle UI behavior, I've also requested confirmation from Ayman that this is in line with UX's intentions (see comment 9)

Comment 11

[Corey Frang [:gnarf]]

Comment on attachment 758112 [details] [diff] [review]
Implement specified "subheader-Compose" interaction

Review of attachment 758112 [details] [diff] [review]:
-----------------------------------------------------------------

There is a bug with the transition for the singleline/multiline recipients field, discussed with mike

Comment 12

[Mike Pennisi [:jugglinmike]]

Attachment: Implement specified "subheader-Compose" interaction v.2

This version of the patch addresses the feedback from Corey in comment 11.

See commit message for technical explanation of specific changes.

Since this patch involves subtle UI behavior, I've also requested confirmation from Ayman that this is in line with UX's intentions (see comment 9)

Comment 13

[Corey Frang [:gnarf]]

Comment on attachment 758174 [details] [diff] [review]
Implement specified "subheader-Compose" interaction v.2

Review of attachment 758174 [details] [diff] [review]:
-----------------------------------------------------------------

r=me - seems stable now, or at least my testing can't break it :)

Comment 14

[Corey Frang [:gnarf]]

master: https://github.com/mozilla-b2g/gaia/commit/9e8b529b16875f63aec3ad5eae5ec9ce52721aa0

Comment 15

[Mike Pennisi [:jugglinmike]]

Sorry Ayman, I don't think I was clear with Corey about wanting your feedback prior to moving forward. The patch has landed in `master`, but I'm happy to work with you if anything I demonstrated in the video needs changing.

Comment 16

[ayman maat :maat]

Hi mike

I like what your solution, and the code looks good (to me) as well. Could i ask one final enhancement:

@2:46 in the video. Could you please switch the place of the 'carrier unknown' message and the 'You've reached the maximum length' message. So if we read the screen top down it will read as so:

<zone 1> header indicating number of respondents and providing a back /edit CTA.
<zone 2> 'carrier unknown' message
<zone 3> 'You've reached the maximum length' message
<zone 4> message being composed

The reason why i as this is down to grouping and association of information. <zone 1>The header and <zone 2>the carrier field (or 'to' field) are directly related and therefore should not be divorced. the carrier <zone 2> is a subset of information related to the contact presented in the header <zone 1> or in new message mode the content of the to field <zone 2> is more granular information about the number of recipients presented in the header <zone 1>. In either new message or 'reply to thread' mode <zone 3> The 'You've reached the maximum length' message is directly related to the content in <zone 4> the message being composed and therefore should not be divorced either.

Comment 17

[Mike Pennisi [:jugglinmike]]

Thanks for the detailed explanation, Ayman! Since this patch has already landed, I've created a new bug to track the change: Bug 879907 .

This will make it easier for others to understand the progress of that work and if I cannot get to it in a timely manner, allow someone else to pick up my slack.

Comment 18

[Corey Frang [:gnarf]]

maria, I'm flipping this around to block 879907 --- That ticket isn't needed unless this one is fixed first, so it blocks, not depends.

Comment 19

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 9e8b529b16875f63aec3ad5eae5ec9ce52721aa0 to:
v1-train: f5fd8a0ca030743f73584f5204a54ee6bdcaac56

Comment 20

[Deepa Subramanian]

The user is able to see the "carrier|phonenumber" sub header clearly all the time when composing a message and during the maximum height.

Issue is verified as fixed. 
Environmental Variables
Leo Build ID: 20130807071207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/11bb1b0eefff
Gaia: 60ca81600a080dae33058b0692ecaa213556c926
Platform Version: 18.1