Closed Bug 1050868 Opened 5 years ago Closed 5 years ago

Visual Refinements to Expanding Rocket Bar

Categories

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

x86
Gonk (Firefox OS)
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: epang, Unassigned)

References

Details

(Keywords: polish, Whiteboard: [systemsfe])

User Story

Spec/Flow: https://mozilla.box.com/s/tas8lrljyf4khcegl3kg
Motion: https://mozilla.box.com/s/3wvt1n5jxsbry9pu1p1v

Attachments

(2 files)

Attached video 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
Hey Eric, can't access the box link, can you check the access rights?
Flags: needinfo?(epang)
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!
Flags: needinfo?(epang) → needinfo?(etienne)
(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?
Blocks: 941182
Component: Gaia::Search → Gaia::System::Browser Chrome
Flags: needinfo?(epang)
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.
(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
Flags: needinfo?(epang)
Maybe we should make the transition to the search app different than the transition from the collapsed/expanded state?
(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.
Flags: needinfo?(etienne)
(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.
No longer blocks: rocketbar-search-mvp
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
User Story: (updated)
Blocks: 1041371
No longer blocks: browser-chrome-mvp
Assignee: kgrandon → nobody
Blocks: browser-chrome-mvp
No longer blocks: 941182
Keywords: polish
No longer blocks: browser-chrome-mvp
Assignee: nobody → eperelman
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S4 (12sep)
Eli, are you actively working on this?
Flags: needinfo?(eperelman)
I've been working towards this in-between my work on the software home button. Did you have a question about it?
Flags: needinfo?(eperelman)
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.
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.
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
Attachment #8491600 - Flags: review?(kgrandon)
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 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.
Attachment #8491600 - Flags: ui-review?(epang)
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!
Attachment #8491600 - Flags: ui-review?(epang) → ui-review-
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.
Attachment #8491600 - Flags: review?(kgrandon)
Target Milestone: 2.1 S4 (12sep) → ---
Blocks: rocketbar-next
No longer blocks: rocketbar-mvp
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?
Flags: needinfo?(epang)
Summary: [Search] Visual Refinements to Expanding Rocket Bar → Visual Refinements to Expanding Rocket Bar
(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.
Flags: needinfo?(epang)
Eli, are you still working on this?

Is this still work-on-able, or is this bug invalid now?
Flags: needinfo?(eperelman)
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.
Assignee: eperelman → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(eperelman)
Eric, re comment #20, should this bug be closed then?
Flags: needinfo?(epang)
(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.
Flags: needinfo?(epang)
Closing as per comment 24
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.