Closed Bug 949500 Opened 11 years ago Closed 11 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 949457

People

(Reporter: isabelrios, Assigned: borjasalguero)

References

Details

(Whiteboard: burirun1.3-2, burirun1.3-3)

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.
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.
Depends on: 949457
ni? ayman to take a look at this further triage: 1.3+. if this is too much work, lets rediscuss
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(aymanmaat)
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.
Flags: needinfo?(aymanmaat)
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.
Flags: needinfo?(aymanmaat)
blocking-b2g: 1.3+ → 1.3?
(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.
Flags: needinfo?(aymanmaat)
blocking 1.3+
blocking-b2g: 1.3? → 1.3+
Fernando, do you mind taking a look at this? Thanks
Flags: needinfo?(fernando.campo)
Sure, no prob, I'll start with it on monday
Assignee: nobody → fernando.campo
Flags: needinfo?(fernando.campo)
Target Milestone: --- → 1.3 C2/1.4 S2(17jan)
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?
Flags: needinfo?(aymanmaat)
Flags: needinfo?(jcheng)
Assignee: fernando.campo → borja.bugzilla
(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.
Flags: needinfo?(aymanmaat)
So it's different to what you said in comment 5 ;) This is also my preference (see comment 1).
1.4? to triage for 1.4
blocking-b2g: 1.3+ → 1.4?
Flags: needinfo?(jcheng)
Whiteboard: burirun1.3-2
Blocks: 951682
Target Milestone: 1.3 C2/1.4 S2(17jan) → 1.3 C3/1.4 S3(31jan)
Target Milestone: 1.3 C3/1.4 S3(31jan) → 1.4 S1 (14feb)
Whiteboard: burirun1.3-2 → burirun1.3-2, burirun1.3-3
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
move to 1.5? to be considered together with visual refresh
blocking-b2g: 1.4? → 1.5?
Target Milestone: 1.4 S2 (28feb) → ---
this is part of the visual refresh for 1.5
blocking-b2g: 1.5? → ---
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.