1050868 - Visual Refinements to Expanding Rocket Bar

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System::Browser Chrome, defect)

Description

[Eric Pang [:epang] UX]

Attachment: current.mp4

When accessing the RB search from an app looks currently looks really janky.

I've attached a video of the current implementation ('current.mp4')

Some areas that need to be updated:
- The status bar icons should fade out on tap
- The input field should expand to the full expanded width
- Text in colapsed state needs to fade out on tap
- The Search text, cancel and div line should fade in
- The background should be the current app (Francis, can you confrim if this is still the case?)

I'm hoping to get closer to the motion here on box:
https://mozilla.box.com/s/8e3eed15f1656f8kbfb4

Comment 1

[Etienne Segonzac (:etienne)]

Hey Eric, can't access the box link, can you check the access rights?

Comment 2

[Eric Pang [:epang] UX]

Hi Etienne, sorry about that, give this link a try.
https://mozilla.box.com/s/oedme1y7u6m3s6lxvk0a

Let me know if it still doesn't work. Thanks!

Comment 3

[Ben Francis [:benfrancis]]

(In reply to Eric Pang [:epang] from comment #0)
> - Text in collapsed state needs to fade out on tap

Is that definitely what you want? You mentioned before that you made this change because you thought it would be easier to implement? Given we already have the text expanding/shrinking would you rather keep that, or have the collapsed text fade out and the expanded text fade in in all scenarios? For example, it looks quite nice when you collapse/expand the Rocketbar on scroll and the text shrinks into the status bar. Do you want to change that so it fades out and fades back in again?

(In reply to Eric Pang [:epang] from comment #2)
> Hi Etienne, sorry about that, give this link a try.
> https://mozilla.box.com/s/oedme1y7u6m3s6lxvk0a

That link is to a visual spec, not an animation, is that what you intended?

Comment 4

[Kevin Grandon :kgrandon]

I think we'll need to implement some of these and try them on an actual device. I've found the more fading we do is way more distracting than not fading at all, and takes away from the browsing experience. My focus shifts from the web content to the header as I scroll down the page.

Comment 5

[Eric Pang [:epang] UX]

(In reply to Ben Francis [:benfrancis] from comment #3)
> (In reply to Eric Pang [:epang] from comment #0)
> > - Text in collapsed state needs to fade out on tap
> 
> Is that definitely what you want? You mentioned before that you made this
> change because you thought it would be easier to implement? Given we already
> have the text expanding/shrinking would you rather keep that, or have the
> collapsed text fade out and the expanded text fade in in all scenarios? For
> example, it looks quite nice when you collapse/expand the Rocketbar on
> scroll and the text shrinks into the status bar. Do you want to change that
> so it fades out and fades back in again?
> 
Hey Ben, I think the transition in the browser on scroll works great!
This is regarding accessing the rb from an app - see the attached video in the attachments.  The transition is strange since the text changes.  We need something that eases from 'Phone' (or other app name) to 'Search or enter address' in the example.  It's odd to have 'Phone' grow then abruptly change to 'Search or enter address'. That's why I'm thinking a fade is needed here.

> (In reply to Eric Pang [:epang] from comment #2)
> > Hi Etienne, sorry about that, give this link a try.
> > https://mozilla.box.com/s/oedme1y7u6m3s6lxvk0a
> 
> That link is to a visual spec, not an animation, is that what you intended?

You're right, I mean to paste the link to the motion, sorry
https://mozilla.box.com/s/3wvt1n5jxsbry9pu1p1v

Comment 6

[Kevin Grandon :kgrandon]

Maybe we should make the transition to the search app different than the transition from the collapsed/expanded state?

Comment 7

[Etienne Segonzac (:etienne)]

(In reply to Kevin Grandon :kgrandon from comment #6)
> Maybe we should make the transition to the search app different than the
> transition from the collapsed/expanded state?

+1
I think we should isolate the case of launching search from a collapsed rocketbar.
And in this case, fade the text first (quickly) then start the scaling transition.

Comment 8

[Eric Pang [:epang] UX]

(In reply to Etienne Segonzac (:etienne) from comment #7)
> (In reply to Kevin Grandon :kgrandon from comment #6)
> > Maybe we should make the transition to the search app different than the
> > transition from the collapsed/expanded state?
> 
> +1
> I think we should isolate the case of launching search from a collapsed
> rocketbar.
> And in this case, fade the text first (quickly) then start the scaling
> transition.

that makes sense to me.

Comment 9

[Eric Pang [:epang] UX]

Just wanted to add a note about the background staying as the current screen.  Only when accessed from the homescreen does the wallpaper show.  Also the overlay is a higher opacity which can be seen in this spec  here: https://mozilla.box.com/s/tas8lrljyf4khcegl3kg

Comment 10

[Ben Francis [:benfrancis]]

Eli, are you actively working on this?

Comment 11

[:Eli Perelman]

I've been working towards this in-between my work on the software home button. Did you have a question about it?

Comment 12

[Ben Francis [:benfrancis]]

Nothing specific, just wanted to make sure it was moving forward and wondered what requirements you're working to? I think a lot of Browser Chrome polish bugs got merged into this one and I've lost track of what is left to do.

Comment 13

[:Eli Perelman]

I've been using the spec and video attached for this, but I haven't rebased master in a while, so I suppose I should do that and see what's up.

Comment 14

[:Eli Perelman]

Attachment: Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24190

Kevin, I've got a patch here that is a partial attempt to resolve some refinements from the spec. This one addresses:

- Status bar icons fade away
- Chrome title fades away
- Underlay darkens and expands down to #000 and 0.9 opacity

Comment 15

[:Eli Perelman]

I'd like to address a couple points from the spec that I believe are risky for v2.1 or present significant more effort to do when coupled with the patch I've already presented:

1. 'Close' and div line fades in:

We realistically probably can't or shouldn't separate these elements from the input itself. While the close string and div line are technically separate from the input element itself, the placeholder string is a part of the input element, and syncing the animations of the 2 would be difficult based on the requirement of having the search input expand and showing the text fade in along with these 2 elements

2. Input field grows

This one is tough because the input field is not a single one present in the system app, but rather has a duplicated .title element for each open app. This element is contained within the app's chrome and we couldn't animate this element to expand to the rocketbar input size by simply just adjusting dimensions. We could experiment with absolute positionings and allowing the chrome to overflow, but I'm thinking that's probably not a good idea.

Alternatively, you could simulate the appearance of the input field growing from the "Search the web" input to the rocketbar one by making the rocketbar input the same size as the chrome title and animating it, but that seems risky at this stage considering the layout changes it might affect.

Comment 16

[Kevin Grandon :kgrandon]

Comment on attachment 8491600 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24190

Thanks for the patch Eli. I'd like Eric to do a ui-review here first, because TBH I'm not really a fan of this. I think it's a lot more jarring to have so many more things moving than a simple fade.

Comment 17

[Eric Pang [:epang] UX]

Comment on attachment 8491600 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24190

Thanks for working on this Eli, but seeing parts of it implemented I'm going to have to agree with Kevin.  Seeing as we can't resize the input field to the correct size the underlay appearing as a curtain looks jarring.  The idea was to have everything move down together in time.

The current fade transition is less distracting, but I did noticed that when you access the RB from the collapsed state then close you get a quick flash.  Is this something we can fix?  I think if this can be addressed the transition is good for 2.1.  Thanks again!

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8491600 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24190

(In reply to Eric Pang [:epang] from comment #17)
> Comment on attachment 8491600 [details] [review]
> Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/24190
> 
> The current fade transition is less distracting, but I did noticed that when
> you access the RB from the collapsed state then close you get a quick flash.
> Is this something we can fix?  I think if this can be addressed the
> transition is good for 2.1.  Thanks again!

Hmm, this may have actually been another problem which I backed out yesterday. This was possibly due to the revert of bug 1055299. We may want to take another look at this same patch again to see if anything is different. I'm going to clear review for now, and due to the delicate nature of this transition, we may want to get a ui-review for this first. The code mostly looks good though.

Comment 19

[Ben Francis [:benfrancis]]

Eric, are there still changes we're expecting to make here for 2.1, or shall we re-visit with a new spec in 2.2?

Comment 20

[Eric Pang [:epang] UX]

(In reply to Ben Francis [:benfrancis] from comment #19)
> Eric, are there still changes we're expecting to make here for 2.1, or shall
> we re-visit with a new spec in 2.2?

Hey Ben, for 2.1 I don't think there's anything we need to change besides the two Rocket Bar problem.  But it's being addressed in bug 1090562 so that should cover it :).  Thanks for checking in about this.

Comment 21

[Dietrich Ayala (:dietrich)]

Eli, are you still working on this?

Is this still work-on-able, or is this bug invalid now?

Comment 22

[:Eli Perelman]

From what I understand, It's still work-on-able, but maybe under different requirements. Regardless, I won't be taking this on anytime soon.

Comment 23

[Dietrich Ayala (:dietrich)]

Eric, re comment #20, should this bug be closed then?

Comment 24

[Eric Pang [:epang] UX]

(In reply to Dietrich Ayala (:dietrich) from comment #23)
> Eric, re comment #20, should this bug be closed then?

Hey Dietrich, thanks for checking in.  Looks like it's already been address in another bug, so we're good to close.

Comment 25

[Ben Francis [:benfrancis]]

Closing as per comment 24