949500 - [Messages] Subject. When scrolling an extended message, the subject field is not hidden

Status: RESOLVED DUPLICATE of bug 949457

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

Description

[isabelrios]

v1.3 12/12 build:
Gecko-c8ebb7f
Gaia-cbd2921

STR
1. Compose a new message with enough lines to scroll
2. Add subject to the message
3. Once the subject is shown, tap on the text field and scroll sliding up

EXPECTED
According to WFs  https://bug919966.bugzilla.mozilla.org/attachment.cgi?id=8337619 page 10 screen 4 to 7, when sliding up, the subject field is hidden

ACTUAL
It is possible to scroll but the subject field is always visible.

Comment 1

[Julien Wajsberg [:julienw]]

Mmm right, the scroll should be on the whole form instead of the compose text input only.

Let's do this once we're converted to flex-box in bug 949457.

Comment 2

[Joe Cheng [:jcheng] (please needinfo)]

ni? ayman to take a look at this further 
triage: 1.3+. if this is too much work, lets rediscuss

Comment 3

[ayman maat :maat]

Yes scroll needs to take the whole form not just the message input field. The specification of this was quite deliberate. 

At the moment in new message mode we loose a lot of space on the y axis due to: 

- the header, 
- the ‘to field’ and 
- the word suggestions row just above the keyboard. 

(I am currently working on a design proposition that combines the header and the ‘to field’ - like it used to be before this cumbersome header was imposed on the new message dialogue - in order to make more room for the message body)

..Design wise our aim is to maximise the amount of visuality given to the message body during composition as this is really the most important area on the screen when it is in focus. If we keep the subject visible not only do we add what is really noise to the screen (subject is fairly irrelevant once it has been written and should be only accessible to the user only on demand) ..but we also loose up to two lines of message body.. reducing an already small message area to a pitiful 3 lines… that amount of real estate is not even remotely competitive. using it is a little bit like trying to have a conversation through a letter box in a door.

In view of this the specification of scrolling of the subject field was quite deliberate. From a UX PoV its absolutely not an optional extra.

Comment 4

[Julien Wajsberg [:julienw]]

Ayman, do you think this is really a 1.3 blocker or would that be ok from your PoV if this is done in 1.4?

I'd really like to do bug 949457 before messing more in this already messy area of code. Each time we touch this there is a huge risk of regression.

Comment 5

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> Ayman, do you think this is really a 1.3 blocker or would that be ok from
> your PoV if this is done in 1.4?
> 
> I'd really like to do bug 949457 before messing more in this already messy
> area of code. Each time we touch this there is a huge risk of regression.

Yes unfortunately from a UX PoV i do think that this should block v1.3. When we look at the New Message Composer usability is vey much impaired by the loss of real estate on the Y plane due to the presence of the subject field. This reduction in usability is exacerbated when attachments (video, image) are present. The avoidance of this situation was why i deliberately specified the subject field to scroll away.

Comment 6

[Tony Chung [:tchung]]

blocking 1.3+

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

Fernando, do you mind taking a look at this? Thanks

Comment 8

[Fernando Campo (:fcampo)]

Sure, no prob, I'll start with it on monday

Comment 9

[Borja Salguero [:borjasalguero]]

I would suggest to move this to 1.4. We have some well-known issues based on the current structure of the composer (a lot of JS magic behind, old markup...) which let SMS App to split the available space (which is dynamic) between the subject & the input of the composer. However all this 'magic' needs to be reviewed and should be fixed before adding more functionality. I would appreciate if we move this to the next release, having enough time fix the Composer, adding all the features needed (actually Im gonna reassign this to me for taking a look asap). Ayman, Joe, Wdyt?

Comment 10

[ayman maat :maat]

(In reply to Borja Salguero [:borjasalguero] from comment #9)
> I would suggest to move this to 1.4. We have some well-known issues based on
> the current structure of the composer (a lot of JS magic behind, old
> markup...) which let SMS App to split the available space (which is dynamic)
> between the subject & the input of the composer. However all this 'magic'
> needs to be reviewed and should be fixed before adding more functionality. I
> would appreciate if we move this to the next release, having enough time fix
> the Composer, adding all the features needed (actually Im gonna reassign
> this to me for taking a look asap). Ayman, Joe, Wdyt?

Sure from a UX PoV its fine to move this to V1.4 if we need more time to implement in order to improve code quality and minimise risk. But we should endeavour to deliver within the V1.4 timeframe because it is a UX issue.

Comment 11

[Julien Wajsberg [:julienw]]

So it's different to what you said in comment 5 ;)

This is also my preference (see comment 1).

Comment 12

[Joe Cheng [:jcheng] (please needinfo)]

1.4? to triage for 1.4

Comment 13

[Joe Cheng [:jcheng] (please needinfo)]

move to 1.5? to be considered together with visual refresh

Comment 14

[Joe Cheng [:jcheng] (please needinfo)]

this is part of the visual refresh for 1.5

Comment 15

[Borja Salguero [:borjasalguero]]

Closing this due to, as part of Visual Refresh, subject now is part of the message container, so this specification lo longer apply. Check bug https://bugzilla.mozilla.org/show_bug.cgi?id=949457 for more details.