1060577 - Jarring change in appearance when clicking on address bar in new Browser app

Status: RESOLVED FIXED

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

Description

[Botond Ballo [:botond]]

STR:
  1. Open the Browser app from the Homescreen.

     You see a page with a white background with "Top Sites"
     and "History" sections, and a light gray search/address bar 
     also with a white background with a magnifying-glass button
     and a stack-of-squares button beside it, and the system bar
     above it.

  2. Tap the search/address bar.

     In addition to bringing up the keyboard, this drastically
     changes the appearance of the page:
    
      - These is now a dark gray overlay covering the page.

      - The appearance of the search/address bar has changed
        (darker gray, slightly smaller);

      - The UI elements at the right of the address bar have
        changed to a vertical bar and a 'Close' button.
     
      - The system bar above the address bar is gone.

This is a very jarring change in appearance - it feels like clicking on the address bar has taken you to a whole different page.

I think it would be a much better user experience if clicking on the address bar resulted in much more subtle changes, similar to what clicking on any input field is like - i.e. you stay on the same page, and it's only the inside of the input field that changes.

Comment 1

[Ben Francis [:benfrancis]]

This is implemented to spec, Eric do you have any comments from a design point of view?

Comment 2

[Eric Pang [:epang] UX]

Hi Botond, thanks for the feedback, I've added notes below.

>       - These is now a dark gray overlay covering the page.

This is to spec, because of content that appears behind it the overlay has to be dark enough for readability

>       - The appearance of the search/address bar has changed
>         (darker gray, slightly smaller);

The rocket bar shouldn't change height, it should be the same throughout the OS
This should be addressed with: https://bugzilla.mozilla.org/show_bug.cgi?id=1054778

Also, the text size in the expanded state should be the same as the RB search screen.  Ben, can you help look into updating this? Do we need to open a new bug or can it be addressed in the bug above?

The colour changes as expected

>       - The UI elements at the right of the address bar have
>         changed to a vertical bar and a 'Close' button.

This behaves as expected
  
>       - The system bar above the address bar is gone.

This behaves as expected - we wanted the RB search to be at the forefront 
 
> This is a very jarring change in appearance - it feels like clicking on the
> address bar has taken you to a whole different page.
> I think it would be a much better user experience if clicking on the address
> bar resulted in much more subtle changes, similar to what clicking on any
> input field is like - i.e. you stay on the same page, and it's only the
> inside of the input field that changes.

The RB Search screen is consistent across the OS.  The reason the entire screen is used is because of the search results that end up occupying the space.

I can see how this looks jarring in the browser though since a user might want to just edit a link without getting an entire search.  Francis, is there an option of the browser functioning independently (I'm afraid of breaking consistency though)? what do you think?  

Thanks!

Comment 3

[Francis Djabri [:djabber]]

My suggestion here would be try experimenting with lightening the overlay, or only showing the overlay when results are displayed. But whatever we do should apply consistently.

Comment 4

[Eric Pang [:epang] UX]

(In reply to Francis Djabri [:djabber] from comment #3)
> My suggestion here would be try experimenting with lightening the overlay,
> or only showing the overlay when results are displayed. But whatever we do
> should apply consistently.

I would say we can fade to a lower opacity overlay when the search app first loads (75%).  Then once the results start loading the opacity darkens to the current (90%).

We'll have to see how it feels.  Ben, what do you think?

Comment 5

[Ben Francis [:benfrancis]]

I don't think we should change the visual spec for 2.1 at this stage if we can avoid it. For areas that still aren't to spec, please do file separate bugs if they don't already exist.

Feel free to address this issue in a new visual spec for 2.2 though.

Thanks

Comment 6

[Francis Djabri [:djabber]]

Attachment: This video shows an opacity of 70% in empty state and 90% with results

Comment 7

[Francis Djabri [:djabber]]

Attachment: Screens of different opacities

Comment 8

[Francis Djabri [:djabber]]

I attached an animation from Eric in comment 6 which shows an initial opacity of 70% and then 90% opacity with results. I think this works well. 

I also attached in comment 7 some screens that show different opacities. The current overlay is definitely darker than the 90% opacity that Eric spec'ed. I think we could go for an 80% opacity if we only have a single opacity, but I think the 70/90 solution in the animation is the best.

Comment 9

[Ben Francis [:benfrancis]]

Stealing

Comment 10

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/24383

Here's a patch which sets 90% opacity on focus and 70% opacity on input.

Francis, Eric, what do you think?

Note that this going to make bug 1072309 (two Rocketbars visible since Browser Chrome was separated from focused Rocketbar) more obvious.

Comment 11

[Eric Pang [:epang] UX]

(In reply to Ben Francis [:benfrancis] from comment #10)
> Created attachment 8494517 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/24383
> 
> Here's a patch which sets 90% opacity on focus and 70% opacity on input.
> 
> Francis, Eric, what do you think?
> 
> Note that this going to make bug 1072309 (two Rocketbars visible since
> Browser Chrome was separated from focused Rocketbar) more obvious.

Hey Ben, thanks for working on this so quickly!  I think it looks good, but I think we need to up the input opacity to 80%.  At the moment it looks like the RB is floating in space.  Let's see if Francis agrees when he reviews :).

For the two rocketbars would it be possible to fade it out with the status bar icons?  Another possibility we could try is to use a gradient underlay where it's dark at the top (90%) and fades down (60%-70%).  Then when the RB is focus the entire underlay goes to 90%. 

Thanks again!

Comment 12

[Kevin Grandon :kgrandon]

The "small" rocketbar is supposed to expand into the large one, it seems we must have regressed that recently.

Comment 13

[Kevin Grandon :kgrandon]

Sorry, I marked the wrong bug here.

Comment 14

[Francis Djabri [:djabber]]

(In reply to Eric Pang [:epang] from comment #11)
> (In reply to Ben Francis [:benfrancis] from comment #10)
> > Created attachment 8494517 [details] [review]
> > https://github.com/mozilla-b2g/gaia/pull/24383
> > 
> > Here's a patch which sets 90% opacity on focus and 70% opacity on input.
> > 
> > Francis, Eric, what do you think?
> > 
> > Note that this going to make bug 1072309 (two Rocketbars visible since
> > Browser Chrome was separated from focused Rocketbar) more obvious.
> 
> Hey Ben, thanks for working on this so quickly!  I think it looks good, but
> I think we need to up the input opacity to 80%.  At the moment it looks like
> the RB is floating in space.  Let's see if Francis agrees when he reviews :).
> 

Yes, agreed!

Comment 15

[Ben Francis [:benfrancis]]

Oh, I wrote that backwards. It was 70% on focus and 90% on input.

I have increased the 70% to 80% which I think is what you meant?

Kevin, good call on the expanding Rocketbar regression, I have morphed bug 1072309 accordingly.

Comment 16

[Kevin Grandon :kgrandon]

Comment on attachment 8494517 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24383

This looks good, but my only concern is that we call handleInput when we focus on a URL which is one of the primary entrypoints into rocketbar. In this state I think that we should be showing at the 80% mode. What do you think ben?

Comment 17

[Ben Francis [:benfrancis]]

Hmm, so we do. I've changed it to only change the backdrop if triggered by an actual input event, that's the cleanest way I could think of.

Comment 18

[Kevin Grandon :kgrandon]

Comment on attachment 8494517 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24383

Almost. The problem I noticed now is that if you have a search term saved, we might show results along with a 80% opacity backdrop. I'm not sure what the best thing to do here is, but I guess we need to do some kind of checking to make sure we're not showing results when setting to an 80% backdrop.

STR:
1 - Focus on home screen rocketbar, and enter some text. See results.
2 - Press home button.
3 - Re-focus rocketbar, see saved search term and results.

Actual STR:
80% backdrop

Expected STR:
90% backdrop

Comment 19

[Ben Francis [:benfrancis]]

Comment on attachment 8494517 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24383

OK, I found a much simpler approach.

Comment 20

[Kevin Grandon :kgrandon]

Comment on attachment 8494517 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24383

Looking good now. Thanks!

Comment 21

[Ben Francis [:benfrancis]]

https://github.com/mozilla-b2g/gaia/commit/0f43950a976f2926979212a96c91f0c0fc6ef29d

Comment 22

[Ben Francis [:benfrancis]]

Comment on attachment 8494517 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24383

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): n/a
[User impact] if declined: Poor user experience
[Testing completed]: Unit test
[Risk to taking this patch] (and alternatives if risky): Low - one additional CSS class and small CSS change.
[String changes made]: None.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/e9cbcbb12c1ec76e0ccdc88f1962f2afa3dd17b2

Comment 24

[Kevin Grandon :kgrandon]

Hey guys - It seems that we've recently regressed this by landing bug 1117968. Instead of gradually darkening the background, we now display the search result background as a hard-color immediately.

I just wanted to verify that that was intended, as we did quite a bit of work here to address that initially, and I don't think the new UX is nearly as nice. I'd probably recommend fading into a more-dark color, and leave the initial state as semi-transparent.

Comment 25

[Ben Francis [:benfrancis]]

I noticed that too so I confirmed with Eric that that's what he wanted and he said it was. He might be able to explain more.

Comment 26

[Eric Pang [:epang] UX]

(In reply to Kevin Grandon :kgrandon [INACTIVE - heads down on Gij Issue] from comment #24)
> Hey guys - It seems that we've recently regressed this by landing bug
> 1117968. Instead of gradually darkening the background, we now display the
> search result background as a hard-color immediately.
> 
> I just wanted to verify that that was intended, as we did quite a bit of
> work here to address that initially, and I don't think the new UX is nearly
> as nice. I'd probably recommend fading into a more-dark color, and leave the
> initial state as semi-transparent.

Hey Kevin, Ben,

I completely agree, the grey doesn't work without the other visual changes/transitions.  
Can we revert to the old transition but make a few changes?

1. Update the background colour to a dark grey #333333
2. When the user taps the RB the background fades in but is transparent (not a change besides the colour)
3. When the user begins to type the background fades to 100% opacity

Let me know if I need to open a new bug for these changes. Ben, can you flag me on UI-reviews for changes like this next time? Thanks!

Comment 27

[Dale Harvey (:daleharvey)]

We cannot implement all the visual changes in a single commit, this change conforms to the specifications minus the transition. I think its a better idea to not churn on changing the specs mid way through to cater for some middle state where it is not fully implemented. These changes were needed in order to have the new features UI look reasonable. 

I think the best process is to make minimal updates as we need when working on new features, once they are all implemented we can do a run through to follow up on any UI changes that have been missed. Then finally when as far as a feature owner Ben / I am happy that the feature was implemented to match the product and visual specifications then it has a UX + Product review. 

We were scheduled to have the updates to the search app done by today, its looking like we will miss that but still should be able to be complete before next friday. That gives us 3 weeks to address any follow ups and changes to the before FL.

In a related note, is the transition specified in https://mozilla.app.box.com/s/x0kqlsutzq4hc6rvho53 used anywhere else in the OS? it looks hard to impossible to implement in a performant manner.

Comment 28

[Kevin Grandon :kgrandon]

(In reply to Dale Harvey (:daleharvey) from comment #27)
> We cannot implement all the visual changes in a single commit, this change
> conforms to the specifications minus the transition. I think its a better
> idea to not churn on changing the specs mid way through to cater for some
> middle state where it is not fully implemented. These changes were needed in
> order to have the new features UI look reasonable. 

If that's the case, let's just make sure we have some bugs filed, or comments in the code/bug to make things clear where they stand. There's no follow-ups mentioned in bug 1117968 for example.


> In a related note, is the transition specified in
> https://mozilla.app.box.com/s/x0kqlsutzq4hc6rvho53 used anywhere else in the
> OS? it looks hard to impossible to implement in a performant manner.

We have something similar for the original overflow menu that Chris implemented, performs fairly well: https://github.com/mozilla-b2g/gaia/blob/master/shared/elements/gaia_overflow_menu/style/external.css#L13

Comment 29

[Kevin Grandon :kgrandon]

Ben - do you want to file a follow-up/fix for comment 25?

Comment 30

[Ben Francis [:benfrancis]]

Happy to iterate on this to get it right, but as Dale says I think we should finish implementing this version of the spec before we start working on a new one. I've filed bug 1125810 for the proposed change but I think we should continue implementing the current spec at least for this sprint so we can see how it all fits together. We can iterate in the next sprint.