Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Minor toolbar visual refinement suggestions #4400

Merged
merged 1 commit into from
Oct 4, 2016

Conversation

JohnONolan
Copy link
Contributor

Hi everyone! 👋 after chatting with some of the team yesterday I had a couple of suggestions for visual refinements. Rather than write a wordy issue or mess around with mockups -- I thought I'd offer a PR with a few minor refinement suggestions (and explanation).

If this is totally off-base / not how you guys work, please feel free to close. I won't be butthurt.

If you're all "uh, who the hell is this guy" (understandable) -- I'm John from https://github.com/TryGhost/Ghost -- I do all the design / front end over there. (Hi!)

This PR has a mix of bug fixes, refinements, and one enhancement. I'll briefly cover each and offer before/after screenshots to explain my work. All of these changes, by themselves, are miniscule and barely noticeable - but in concert, they contribute to (imo) a far more slick and native "feel".

Summary, before/after: (click on any image to see larger version)
brave

of course, all of this is mostly FAO @bradleyrichter :)


1. Tame the back buttons.

The back buttons in the tool bar feel a little overwhelming when alongside other native applications. They're pretty huge, and a little bit squished up against the browser window controls.

I reduced them down to a more standard 25px height baseline across all toolbar elements, which gives a more consistent/proportional horizontal flow -- and gave them a tiny bit more breathing room from the window controls.

[Note: Out of context, these look pretty small - but if you take the PR for a test-drive, you'll see that this size fits in far more with native application controls // feels "normal"]

image

Also, the hover state border radius wasn't working because the back button elements aren't square - so they come out as weird ovals. Adjusted to a more standard button shape:

image


2. Refined focus state of address bar

Move from a slightly in-your-face 2px border to a slightly less-obtrusive 1px

image


3. Slightly refine tab bar

The + icon, despite being svg, was slightly pixelated due to the CSS contain value. This sets a pixel size value which delivers a sharper icon, and also very slightly lightens the tab-bar background to make it feel less muddy, and naturally gives more emphasis to the tab's box-shadow due to greater contrast.

image


4. Bugfix: Brave menu hover state

Previously the icons in the brave context menu had no hover state color, but now they do!

image


5. Enhancement: Move to Native System Font Stack

So the default font right now is just plain arial - which is cool and mostly works, but we can have way more cross-platform compatibility and better rendering by using a native system font stack that caters to all devices / operating systems.

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;

image

Reference material to describe how this works and why it's awesome:

In the screenshot above, other than a small size tweak to better fit with native styles, you'll see there's barely any difference - which is a good thing. But this should be much more future-proof.


6. Shadow Pedantry

This is the most nerdtastic thing ever... but: Replace slightly-bold default box shadow on address bar with a 3 box-shadow alpha transparency symphony.

The main difference is a slightly less "heavy" feel to the shadow, which is a bit web 2.0 - and to make the address input feel more enclosed within the toolbar. Note the contrast between input and border, particularly in the bottom left corner.

image

Note: ^ You can actually notice the better font-family rendering here, on http

@bradleyrichter
Copy link
Contributor

Hi John - these are all great fixes! Thank you!

A few may get adjusted slightly with some planned UI tweaks which I will send your way for feedback.

@bbondy - please pull these in after @bclifton checks for Windows conflicts related to the big toolbar PR.

On Sep 30, 2016, at 4:51 AM, JohnONolan notifications@github.com wrote:

Hi everyone! 👋 after chatting with some of the team yesterday I had a couple of suggestions for visual refinements. Rather than write a wordy issue or mess around with mockups -- I thought I'd offer a PR with a few minor refinement suggestions (and explanation).

If this is totally off-base / not how you guys work, please feel free to close. I won't be butthurt.

If you're all "uh, who the hell is this guy" (understandable) -- I'm John from https://github.com/TryGhost/Ghost -- I do all the design / front end over there. (Hi!)

This PR has a mix of bug fixes, refinements, and one enhancement. I'll briefly cover each and offer before/after screenshots to explain my work. All of these changes, by themselves, are miniscule and barely noticeable - but in concert, they contribute to (imo) a far more slick and native "feel".

Summary, before/after: (click on any image to see larger version)

of course, all of this is mostly FAO @bradleyrichter :)

  1. Tame the back buttons.

The back buttons in the tool bar feel a little overwhelming when alongside other native applications. They're pretty huge, and a little bit squished up against the browser window controls.

I reduced them down to a more standard 25px height baseline across all toolbar elements, which gives a more consistent/proportional horizontal flow -- and gave them a tiny bit more breathing room from the window controls.

[Note: Out of context, these look pretty small - but if you take the PR for a test-drive, you'll see that this size fits in far more with native application controls // feels "normal"]

Also, the hover state border radius wasn't working because the back button elements aren't square - so they come out as weird ovals. Adjusted to a more standard button shape:

  1. Refined focus state of address bar

Move from a slightly in-your-face 2px border to a slightly less-obtrusive 1px

  1. Slightly refine tab bar

The + icon, despite being svg, was slightly pixelated due to the CSS contain value. This sets a pixel size value which delivers a sharper icon, and also very slightly lightens the tab-bar background to make it feel less muddy, and naturally gives more emphasis to the tab's box-shadow due to greater contrast.

  1. Bugfix: Brave menu hover state

Previously the icons in the brave context menu had no hover state color, but now they do!

  1. Enhancement: Move to Native System Font Stack

So the default font right now is just plain arial - which is cool and mostly works, but we can have way more cross-platform compatibility and better rendering by using a native system font stack that caters to all devices / operating systems.

font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;

Reference material to describe how this works and why it's awesome:

https://www.smashingmagazine.com/2015/11/using-system-ui-fonts-practical-guide/
https://medium.design/system-shock-6b1dc6d6596f#.rhqx5fmyz
In the screenshot above, other than a small size tweak to better fit with native styles, you'll see there's barely any difference - which is a good thing. But this should be much more future-proof.

  1. Shadow Pedantry

This is the most nerdtastic thing ever... but: Replace slightly-bold default box shadow on address bar with a 3 box-shadow alpha transparency symphony.

The main difference is a slightly less "heavy" feel to the shadow, which is a bit web 2.0 - and to make the address input feel more enclosed within the toolbar. Note the contrast between input and border, particularly in the bottom left corner.

Note: ^ You can actually notice the better font-family rendering here, on http

You can view, comment on, or merge this pull request online at:

#4400

Commit Summary

Introduce minor toolbar visual refinements
File Changes

M less/button.less (10)
M less/contextMenu.less (5)
M less/navigationBar.less (26)
M less/tabs.less (2)
M less/variables.less (6)
M less/window.less (2)
Patch Links:

https://github.com/brave/browser-laptop/pull/4400.patch
https://github.com/brave/browser-laptop/pull/4400.diff

You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@luixxiul luixxiul added design A design change, especially one which needs input from the design team. feature/titlebar and removed feature/titlebar labels Sep 30, 2016
@bradleyrichter bradleyrichter added this to the 0.12.4dev milestone Oct 1, 2016
@bsclifton
Copy link
Member

@JohnONolan these changes are great! Thanks for the time and thought put into this 😄

I'll be sure to test these on Windows and work w/ the team towards accepting this. Assigning to myself, @bradleyrichter, and @bbondy

@JohnONolan
Copy link
Contributor Author

Pleasure! Let me know if there's anything that I can do :)

@bbondy
Copy link
Member

bbondy commented Oct 4, 2016

Great stuff, thanks!

@lucidNTR
Copy link
Contributor

lucidNTR commented Oct 4, 2016

looks really cool

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
design A design change, especially one which needs input from the design team. QA/checked-Win32 QA/checked-Win64
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants