1031610 - No more status bar on Message when creating a Message from other App

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Théo Chevalier]

Attachment: Flame master

When creating a new MMS from a picture in Gallery (for instance), there is no more status bar (see attachment).
However, when creating a new message from Message > New message, the status bar is still there.

Hey UX Team, is that the intended behavior?

Comment 1

[Stephany Wilkes]

Flagging Carrie and Vicky but this sounds like a regression.

Comment 2

[Carrie Wang [New account: [e-mail]]]

forward to Jenny!

Comment 3

[Jenny Lee]

When creating new MMS from other apps, status bar should be there. Tks!

Comment 4

[Théo Chevalier]

Thanks Jenny, setting flags accordingly

Comment 5

[Jason Smith [:jsmith]]

Switching to QA Wanted to do branch checks.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

Hey, this is there from long time ago.
Since inline activity is expected to cover the full app, make status bar show upon gallery doesn't really make sense.

Could you tell me why statusbar is important to you when you create message?

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

NOT a regression and this "feature request" doesn't make sense to me.
Please think about this scenario:

Fullscreen app A calls activity B which app is not fullscreen and activity B calls activity C which app is fullscreen and activity C calls activity D which app is fullscreen....., then what is expected? Do you want to see statusbar show/hide/show/hide in this case? How is the transition?

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #7)
> NOT a regression and this "feature request" doesn't make sense to me.
> Please think about this scenario:
> 
> Fullscreen app A calls activity B which app is not fullscreen and activity B
> calls activity C which app is fullscreen and activity C calls activity D
> which app is fullscreen....., 

For D I mean not fullscreen.

IMO the activity layout should be consistent with the bottom most opener.
Otherwise we are going to introduce a "statusbar is app by app" feature, and causes something bad happen.

Comment 9

[Stephany Wilkes]

Jenny, please respond to the UX queries here.

Comment 10

[Jenny Lee]

Hello Alive, I see your point. 
The reason why I think it makes more sense to show status bar is that it would give user a more consistent experience in terms of using Message, where most of the time there's a status bar on top. When you're sharing from a non-fullscreen app to Message, there you'll find status bar on top again (ex. share ringtone). That being said, the solution for this is that we show status bar in Gallery (as well as Video), if this cannot be done, we'll have to comply with current inline activity behavior and NOT show status bar as you suggested. UX will discuss the possibility of showing status bar with framework team in near future. Tks!

Comment 11

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.1, Flame 2.0, Buri 2.1, Buri 2.0 and Open C 2.0

Flame 2.1
Build ID: 20140702040207
Gaia: 85e97290431ce6aa0a965421e84d6070cd899129
Gecko: 7075808c3306
Platform Version: 33.0a1
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 2.0
Build ID: 20140702000201
Gaia: 3bfe47c58c959c42f5ffe0309b5380ea514ccd69
Gecko: f40e767ea283
Platform Version: 32.0a2
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.1
Build ID: 20140702060700
Gaia: b0ddb2122771e25cdd880359406a53b10cdc0507
Gecko: e82a9700f94b
Platform Version: 33.0a1
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0
Build ID: 20140702035037
Gaia: 085cdbf16dfd5249786016ac8ceafa1a54e88497
Gecko: a6e69640a00b
Platform Version: 32.0a2
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.0
Build ID: 20140702000201
Gaia: 3bfe47c58c959c42f5ffe0309b5380ea514ccd69
Gecko: f40e767ea283
Platform Version: 32.0a2 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual result: Creating an MMS from the Gallery or Video (but not Music) app creates a new message page with no status bar.  However, if the user swipes down from the top of the screen the status bar will appear and partially obscure the title bar.

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 1.4

Build ID: 20140630000201
Gaia: aa896d5db1b4929f3bf31a0f4bb7de50530222a8
Gecko: 8cba60bc12ef
Platform Version: 30.0
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Actual result: Creating an MMS from the Gallery, Video or Music app creates a new message page with the status bar present at the top of the screen.

Comment 12

[Joshua Mitchell (Inactive)]

QA-Wanted triage report: Not nomming as it is still being discussed if this is intended design or not.

Comment 13

[Jason Smith [:jsmith]]

Is not showing the status bar (which includes mobile data info) in this scenario a potential cert issue or not?

Comment 14

[Beatriz Rodríguez [:brg]]

I do think this is a bug.
With Flame 2.0:
- open the gallery --> I see the status bar
- try to share it by messaging --> the status bar disappear while opening the message app first and then attach it will have it....

This lack of consistency will be a certification issue in 2.0. Please try to follow 1.4 behaviour.

Comment 15

[Stephany Wilkes]

This is a regression and cert blocker. Nominating. Sorry. :(

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

If my memory serves me right, the sms create in v1.4 is using window disposition but it changes to inline  disposition in v2.0, Julien could you confirm?

If so this behavior is expected. If you guys really like the statusbar please back out the sms patch which makes it inline disposition. NOT a window-mgmt bug.

Comment 17

[Julien Wajsberg [:julienw]]

Yes, the "share" activity is an "inline" activity since bug 936729; so it's in v2.0 but not v1.4.

I won't change it because this has more implications than just the statusbar.

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

Never a system bug. If we decide to show statusbar anyway for every inline activity,
there will be someone filing: 'xxx activity has no statusbar in v1.4 before but it has statusbar now'.

Again, I don't think this is a bug.

Comment 19

[Julien Wajsberg [:julienw]]

So, we have a technical constraint here.

We switched to "inline" activity a while ago (in bug 936729 for v2.0 for the "share" activity, in bug 815093 for v1.3 for the "new" activity) because this makes these improvements:

* we have a brand new window (this means that anything that was happening in the app before is not changed)
* we have the design animation that's wanted for these activities
* we easily go back to the previous application

For all these reasons I don't want to change the activity type in SMS.


Jenny is open to not changing anything in comment 10.
Beatriz said in comment 14 that she sees the statusbar when launching Gallery. However, I don't (just tried on a Flame with the latest v2.0 image). Beatriz, can you please confirm?

I also discussed with Alive, he is also open to change the behavior: showing the statusbar if the activity is not a fullscreen app. But not in a blocker because it would be a risky patch, and it's more a feature request.

Comment 20

[Beatriz Rodríguez [:brg]]

(In reply to Julien Wajsberg [:julienw] from comment #19)
> So, we have a technical constraint here.
> 
> For all these reasons I don't want to change the activity type in SMS.
> 
> 
> Jenny is open to not changing anything in comment 10.
> Beatriz said in comment 14 that she sees the statusbar when launching
> Gallery. However, I don't (just tried on a Flame with the latest v2.0
> image). Beatriz, can you please confirm?
> 
> I also discussed with Alive, he is also open to change the behavior: showing
> the statusbar if the activity is not a fullscreen app. But not in a blocker
> because it would be a risky patch, and it's more a feature request.

Thanks for the summary and explanation. I have restested with today unagi-master and gallery app is full screen. I think I have understood the behaviour but I do think status bar should be kept in messaging app. Moreover, the experience should be the same no matter if the image was added from galery or by openning app messaging first.  Can you confirm that you will modify/reconsider it within 2.1?
(meanwhile I will double check if it could be consider cert blocker or not)

Comment 21

[Julien Wajsberg [:julienw]]

Thanks Beatriz !

Alive, this is a request for you, I don't know who owns this UX/Design decision.

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

Sorry, I still don't think inconsistency is bug.

The sms app supports inline activity in v2.0, this is nice.
The behavior described in this issue is there from inline activity invented.
So we could say it's a side effect of 'support inline sms activity'.

We cannot just change the overall system behavior because sms guy wants its statusbar.

For me no matter it has or has not, really doesn't matter.
The user could still pull down utility tray,
The user could still go to home to see the statusbar.

If we really implement the behavior you want,
consider about a non-fullscreen app is opening a fullscreen activity,
for example, contact app chooses a picture from gallery.
If gallery guy has the same feeling: they don't want see statusbar even they are called by some activity by a non fullscreen app, because they are fullscreen.
I, as an user, could also tell: the statusbar disappear when I am at contact app choosing a photo "is a bug". Why statusbar disappears? Is there a bug?

It's more obvious when recent inline activity animation changes to 'fade-in'/'fade-out'. User is hardly to notice the app is changed. They will just think, why? suddenly the statusbar disappears.

I feel we shouldn't do this until we have more app UXs, especially system wide, review this issue.

And sorry again, I cannot commit we will do it in v2.1, it's PM/EMP dutty.

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Yes, this is a feature and developers along cannot make the scheduling decision.

Given the relatively non-strait forward of this feature request and possible scope creep (*), I would recommend we not taking this feature request for 2.1 as the scope is already locked down.

That said, status bar is of systemsfe feature, so I am redirecting needinfo to Gergor.

* At least I don't see anyone taking about the transition of the status bar when the inline activity frame is shown, and possible iterations required to fine tune the detail.

Comment 24

[Stephany Wilkes]

Alive, can you clarify the UX question in comment #22, if what Jenny has advised won't work? Thanks!

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Stephany Wilkes from comment #24)
> Alive, can you clarify the UX question in comment #22, if what Jenny has
> advised won't work? Thanks!

Contact is picking picture from gallery, since current inline activity opening transition is not obvious,
when the user chooses the gallery to pick, he/she will see the statusbar just disappears. I will think this is a "bug" similar to this bug but it's coming from the solution UX provided for this bug.

Comment 26

[David Scravaglieri [:scravag]]

Shall we reconsider the blocking flag for this bug ?
I think if the behavior doesn't fit UX requirement because of incomplete specification or misunderstanding with system team, this will need more feature work that is not feasible in the current timeframe.

Comment 27

[Stephany Wilkes]

I read through this bug, again. Back on June 29, Jenny stated the expected UX behavior, which is an OS pattern: When creating a new MMS from other apps, the status bar should be there. This is not a solution to the bug, but a statement of the expected pattern.

Then, there was debate about whether or not this was actually a bug, but the UX observation is still the same: not having the status bar breaks a pattern, and Jenny has further described why it is shown. There's nothing new for UX to say here. 

It is now July 15, and there's still discussion, and now we've run up against a very close deadline, so I don't think we have any choice except to remove the blocking flag.

Comment 28

[bhavana bajaj [:bajaj]]

Keeping the UX comment in mind and the timeline not blocking here.

Comment 29

[Beatriz Rodríguez [:brg]]

Agree, we run out of time for 2.0 but IMHO this bug must be fixed and included in 2.1 schope. Will flag feature-b2g set to 2.1 help to give more priority here?

Comment 30

[Stephany Wilkes]

Well, we ran out of time and we didn't have to. This always had the right priority, it's just that we let a discussion drag on for almost a month. But it's a moot point now

Noting it for 2.1, though we also have to ensure this makes it into engineering backlogs for 2.1, so I'll ni? Jean Gong to add it to the scope doc.

Comment 31

[Julien Wajsberg [:julienw]]

What we really need is a clear spec. Alive should confirm but I think this is implemented like it is now for a reason, because there was an unclear spec.

Scoping won't help without a proper spec.

Moving this back to the Window Mgmt component because this will need to be changed at the system level.

Comment 32

[Julien Wajsberg [:julienw]]

And to be clearer, the spec should not be "the Messages app should have the status bar" but be generic, taking into account inline and window activities, and fullscreen and non-fullscreen apps.

Thanks

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Stephany Wilkes from comment #30)
> Well, we ran out of time and we didn't have to. This always had the right
> priority, it's just that we let a discussion drag on for almost a month. But
> it's a moot point now
> 
> Noting it for 2.1, though we also have to ensure this makes it into
> engineering backlogs for 2.1, so I'll ni? Jean Gong to add it to the scope
> doc.

Should be UX-b2g: 2.1 for now and only feature-b2g: 2.1 when confirmed. Gregor, any idea which team should track and deliver this feature?

Comment 34

[Gregor Wagner [:gwagner]]

It seems we still don't have full consensus about what should happen here. As Julien says in comment 31, we need a clear spec for: inline and window activities, and fullscreen and non-fullscreen apps.

Comment 35

[Stephany Wilkes]

Gregor, we have Building Block/UX patterns for these that we can share. This is documented there, by Harly. Please flag accordingly when agreed. Thanks!

Comment 36

[(inactive after 6/18) Alive Kuo [:alive]]

Just FYI, recent app title bar work make each app window has a shadow statusbar so this might not be difficult to do now.

Comment 37

[BMO Automation]

Firefox OS is not being worked on