New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 853241 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Add a hover effect to the omnibox in Refresh

Project Member Reported by jdonnelly@chromium.org, Jun 15 2018

Issue description

With #top-chrome-md=Refresh, we'd like to add a hover effect to the steady-state omnibox. Currently, the color is pretty close to that of the toolbar. Making the color darker on hover will make it clearer that it's a focusable element, improving a11y and general usability.

There are two proposals for what color to make the omnibox background on hover. Please try both and attach screenshots so we can make a final decision.

Proposal 1
transition to GG200 on hover 
Creates 1.2 ratio

Proposal 2
transition to GG300 on hover 
Creates 1.37 ratio

 
Components: UI>Browser>Omnibox

Comment 2 by orinj@chromium.org, Jun 15 2018

Owner: orinj@chromium.org
Labels: Proj-MdRefresh
Status: Assigned (was: Available)

Comment 4 by orinj@chromium.org, Jun 15 2018

Thanks, I forgot to assign.  Question for implementation:

Is there a general preferred way to add hover effects to views that don't already have them?  Right now I am starting with OnMouseEntered/Exited to detect hover but keeping custom state seems more error-prone than simply hooking up an existing behavior (if one exists).  It looks like the new tab button uses an ink drop while tabs themselves use a custom glow hover controller, so I guess it's fine to write something new - probably based on gfx::SlideAnimation driving a color tween: not hard, but not a simple matter of wiring up a component as I first thought.
I think OnMouseMoved is what you want. See for example how it's used for the suggestion result view hover here:

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/omnibox/omnibox_result_view.cc?l=284&rcl=c2199d8197dc81aaae7aae70bb6d5f0319fdabf2

Comment 6 by orinj@chromium.org, Jun 15 2018

Okay, transitioning with SlideAnimation works, but seems like unnecessary bulk and complexity.  How about just instantly switching background color on MouseEntered/Exited?  I like the fast & subtle hint.

Note, these screenshots are with backgrounds at GG200 and GG300, applied only on OmniboxViewViews, NOT the entire LocationBarView.  Let me know if we want it applied to the whole location bar, but isolating to the text field makes logical sense to me, even though it appears a bit starker.
OmniboxViewViews_Background_kGoogleGrey200.png
10.7 KB View Download
OmniboxViewViews_Background_kGoogleGrey300.png
7.8 KB View Download

Comment 7 by orinj@chromium.org, Jun 15 2018

Aha we were commenting at the same time.  Thanks, yes, OnMouseMoved will be great and that example shows it toggling local boolean hover state - so I will do likewise instead of the animation.

Comment 8 by orinj@chromium.org, Jun 15 2018

Went ahead and applied the effect to whole location bar using its existing RefreshBackground machinery, ran this by tommycli@ with GG200 and we agree it looks pretty good. :)  He says it's definitely supposed to be the whole location bar, not just the text field changing color. So I think it's done and I will upload a CL to start review.  If UX wants another shade of gray, it's an easy adjustment; I'm looking at overall approach first.
LocationBar_NotHovered_kGoogleGrey100.png
10.2 KB View Download
LocationBar_Hovered_kGoogleGrey200.png
10.2 KB View Download
LocationBar_Hovered_kGoogleGrey300.png
10.3 KB View Download
Yeah, I'm not sure if an animation is required or not.

bettes: can you comment on that and choose a color? Or would you like us to just land one and then you can see how it looks in practice in Canary?

Comment 10 by orinj@chromium.org, Jun 19 2018

tommycli@ and I think the instant switch from GG100 to GG200 looks great.  But how about for dark color schemes?  In the code I found a dark hand-coded RGB color, so I adjusted it by about the same amount, going about +7 shades brighter in R,G,B.  If there are some designer-approved colors to use for dark theme, I am all for giving dark chrome more love!
Project Member

Comment 11 by bugdroid1@chromium.org, Jun 20 2018

Comment 12 by orinj@chromium.org, Jun 26 2018

Status: Fixed (was: Assigned)
Cc: pkasting@chromium.org
Hello orinij@: I have a question regarding the hover effect. Is it intended that the hover effect has no fade in/out timing? If you hover e.g. over the Chip or the Bookmarks Star you see that the hover has a slightly fade in/out timing effect. Thanks in advance :)
Attached a screencast that is showing the difference.
Hover_Omnibox.mov
927 KB View Download

Comment 15 by orinj@chromium.org, Jun 27 2018

Hi! :)  Yes this was intentional.  My first understanding of the bug was that we should transition with a fade, but then I simplified it to an instant switch for two reasons:

1) Speed & Simplicity principles: the switch is very light, fast, and subtle, requiring less code complexity and memory (no animation state to track).
2) Unlike the Chip and Star UI elements, which will be hovered and clicked less frequently, the location bar itself is likely to have mouse crossings often.  Knowing exactly when you can click into it is actually helpful.

These were my reasons, and I went with them because tommycli@ and I both thought it looked good.  They're not the only domains of concern, though, so if it needs a fade for other reasons, let me know and I'll be happy to give the animation a go.
Thanks for your feedback and the clarification :) I like the Speed & Simplicity way it is working now 👍. Thank you very much!
We try to make pretty much all effects in Chrome animated; I think a fast hover effect here would be beneficial.  The frequent mouse crossings mean that without an animation, the UI flickers rapidly as you mouse to and away from the tab strip, which is worrisome.  I suggest a 200 ms timing (which matches the current background tab hover timing), but maybe something different is called for, and one of the UX motion designers would probably have input if you asked.

I'll let you file a bug on this if you agree.
Here's how one could implement an animation like that in the code:

https://chromium-review.googlesource.com/c/chromium/src/+/1081198

Comment 19 by orinj@chromium.org, Jun 28 2018

Cc: bklmn@chromium.org
I do agree, but I see pros & cons both ways.  How many shades of gray does it take to turn the pro of instant feedback into the con of blink annoyance?  How many milliseconds can we take to smooth the transition before the original intent of usability is compromised?

Seems like a balance to be struck by UX, so I will ask bklmn@ to look this over and provide a transition spec with tween type and duration.  Thanks for the feedback, all. :)

Comment 20 by bklmn@chromium.org, Jun 28 2018

Cc: helenepark@chromium.org
Thanks for the attention to detail here. Id say to start, add this transition to match the background tab hover motion would be great. Ill add helenepark@ to weigh in on timing. 
Spoke to Joel offline, 200ms for a bg tab hover transition sounds good to the both of us

Sign in to add a comment