Mockups/new design discussions

Happy holidays everyone :grinning: :christmas_tree:

I’ve spent some time investigating what works best for window controls. I’ve made a few rough HTML mockups. I’m pretty sure I could remove most of these, but I’ll post them all below. Please ignore the rest of the image as the focus here was on the min, max and close buttons.

I’ve added a public poll, just to see if we’re on the same page.

4 Likes

Great work! I’m totally in favor of 4 or 6.
My ideal result would be to have widget “invisible” until needed.

3 Likes

Hey there, just before the year ends, an update on my part:

After setting up a new VM the Dock is still very transparent. IMO needs less transparency to feel like a solid Dock and work in every circumstance, with every wallpaper, and to be more clear.

For now, honestly, the blue is just present with the volume and this is not making sense entirely. There is no concept and the blue just breaks out from the orange only accents. Compressing / copy files in “Files” is when clicked on the progress clock presented by a green bar. Downloading in Firefox is also orange. So for now I’m still not convinced by a single blue bar. And for testing: the blue should fit the orange, like the base #1C6595 and lighter variations like #37759D and #5A92B6 and darker variations like #0E4E78 and #053C5F. Overall orange and blue are working fine together, it’s just confusing if the only visible blue in the whole system is the volume bar.

Yeah, I think this can work - let’s try it if you like! It is still orange, but less screaming for attention. If it is still too much, I also would go with just white/Unity 7 style. Maybe we need to take care of the possibility that with a round logo there is no square border/background and with a lot of open apps, the logo needs to be visually separated.
Also, the overlay on the button when clicked looks weird - is that a dock thing?

The actual window controls in communitheme works nice for me, maybe they can take more space for clicking and need a little adjusting. I also don’t see a white ring needed, this jumps out of style.

Buttons

They still make me think because we are still not right there.

IMHO: We’re mixing styles and concepts a little.

First, what I like is:
b1
Like said before, they maybe need a little more contrast/darker border, but they look nice, simple, and you know whats going on - like clickable, clicked and hover as a grey color. Non-clickable buttons appear flat, this is also fine with me.

Buttons on a dark background are very different, they need to work in the same way, but also needs to be different in style.

First the flat ones:
b2
You see, the flat buttons are borderless, but on hover they having a border like none-flat buttons. I think, they only need to have a hover color, not changing the type of button from flat to a raised/hover button. Also for now it looks not that nice with the dark border. When clicked, the buttons get’s an inner-shadow and this is fine for me, it gives us a nice and easy visual feedback - maybe the inner-shadow could be less dark, but that’s it.
So: I would suggest getting rid of the hover border to stay flat until clicked.

Next, the raised/hover buttons on dark and breadcrumbs:
Screenshot from 2017-12-30 13-02-46
This is hard to find a styling line. Now it is more a mixture of buttons and concepts.

  • The first thing you look at, is the less important - the non-clickable buttons. Also like said before, we should make the non-clickable darker and the clickable more bright to bring attention and meaning where it needs to be. Here we are misleading the focus.
  • We have two kinds of feedbacks on clicked buttons - inner-shadow and the orange line. I guess when having the orange line, it is not necessary to give the button an inner-shadow. When having a lot of buttons like here, it immediately starts to look nervous and crowded, also because the “Home” button is elevated quite next to the lowered button. Let’s keep it simple and stylish.
    We have that kind of buttons also in the software center/wallpaper and when having categories. So maybe let’s not think of them like typical buttons, but categories. Make them flat with a background, an orange line and a simple hover grey. So for now, just remove the inner-shadow for testing.
    The other way is to make them flat (if the orange line is not fitting to the rest of the system) and just work with the background grey and maybe if needed, an inner-shadow.

The settings, lock & off buttons:
Screenshot from 2017-12-30 13-40-21
They follow the flat buttons now, like I like them to be. Maybe we can add a background grey to make them more noticeable, but at least the hover grey needs to be brighter.

Some more:

  • When in “Files” and change the view from grid to list, the list types/categories header font needs to be a little darker to be better readable
  • Can we try to make the window header smaller to fit the rest of the system? Like in Firefox, the header is bigger and bolder than for example the top panel font.

So, thanks to all who contribute and I wish you all a good start to the new year!
It’s gonna be a LTS year^^

6 Likes

Hey, first of all, I’d like to say that your analysis is always very detailed and full of examples, so thank you for this work.

For now, honestly, the blue is just present with the volume and this is not making sense entirely.

That’s maybe because most of the changes are in the gtk theme, while my PR applied only to gnome-shell (and Firefox is gtk2, if I’m not wrong). @godlyranchdressing’s changes on the gtk3 theme have been merged in the very last days. Said that, I’d like a separation between selected widgets and indicators, but no problem to get rid of this blue entirely if it’s a common desire.

You see, the flat buttons are borderless, but on hover they having a border like none-flat buttons. I think, they only need to have a hover color, not changing the type of button from flat to a raised/hover button.

I agree that the dark border looks a bit weird now, but I need to see a borderless hover button before being sure that’s better. I’ll try something asap and post the result.

the raised/hover buttons on dark and breadcrumbs […]

I agree with the idea of a mixed style now. We might need some more mockups to look at and decide what is better. I’m not a designer, but I’d like to try myself directly in css, so I add this to my todo list as well.

So, thanks to all who contribute and I wish you all a good start to the new year!

Quote that! Good new Year’s Eve to everyone!

4 Likes

Hi all!

Here I show three different hover effects for headerbar flag buttons and I’d like to know your preferences

current version
headerbar-flat-buttons-border

borderless (as suggested by @luxamman)
headerbar-flat-buttons-borderless

a little variation with border color 5% ligher than current used (ubuntu bg color), that is #3D3A3A vs #302E2E
headerbar-flat-buttons-border-lighten5p

  • current hover
  • borderless hover
  • boder #3d3a3a (5% lighter than ubuntu_bg_color)

0 voters

9 Likes

Damn! You’re all doing an awesome job :clap:

A few comments on a screenshot from today:

@luxamman already adressed the issue here.

files_buttons_new

You’re right! The circle X makes it easy to distinguish from other OS’es and I think that’s essential, but I would like to see more space and a larger clickable area highlighted on hover as @merlijn-sebrechts mentioned .

+1 :grinning::+1:

7 Likes

Happy new year, everyone.

Just a reminder, unless you delete the CSS rules in /usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/stylesheet.css, those will override the theme’s. We can probably get around this by appending !important at the end of every changed/new rule for now, though.

Also, we need to figure out a way to indicate what version of the theme we’re using. Things like the headerbar buttons being too light when not in focus have been changed, those changes just haven’t been merged yet.

There’s quite a few widgets that look like progressbars that use a couple colors. There’s the GtkScale/volume slider that we’re proposing should use the blue and would be the most common widget seen, but there’s also the levelbar and progressbar.

The levelbar uses three colors to indicate whether or not it’s low, not empty, high or full. The proposed colors would be:

low = yellow
high (or not empty) = blue (instead of the default orange)
full = green

This is how it looks in SCSS with the different states:

&.low { @include block_highlight($warning_color); }

&.high, &:not(.empty) { @include block_highlight($neutral_color); }

&.full { @include block_highlight($success_color); }

Progressbars only use one color from start to finish which is the green you’ll see when compressing a file. Maybe we can use the blue here instead though.

On minimizing the use of orange, what does everyone think about something similar to the following for selected dates in the calendar?

Screenshot from 2018-01-02 15-10-19

I hope we can semi-finalize things by the end of the month so we can do mass testing through February.

4 Likes

should changing this file’s name have the same effect?

Nice idea, I’m only worried about creating too many corner cases for indicators

1 Like

Yeah, that does it. If anything goes wrong for anyone there’s always: sudo apt install gnome-shell-extension-ubuntu-dock --reinstall

2 Likes

In that case, how about something like this?

pathbar

Though if the stackswitcher follows that style we’ll need to either get rid of the border-radius

stackswitcher

Or get rid of the borders entirely

stackswitcher 2

I tried with a background color but I got rid of it since it messed up the openweather extension. Some extensions borrow class names and in this case, the openweather extension borrows the “.system-menu-action” class, it doesn’t seem to use the hover/active state though.

Good point on the orange. I’m guessing this should happen with every color (green, blue, etc.)? Just clarifying.

5 Likes

@godlyranchdressing I see that you’re using #f7f7f7 for all the text. Maybe remove the bold font from the selected text and just adding a bit of gray to the rest?

Untitled-1

How about using the full headerbar height like the Matcha theme does?

Yes! Adwaita doesn’t do this, but Ambience does :grin:
Speaking of colors, could the (now blue) volumeslider be a few pixels thinner, and the same for the orange around combo-boxes? When searching for a file in Nautilus, the orange border still feels a bit like a warning. Not sure if a 1px orange border solves that or it should be blue or something different? @luxamman ?

All the themes I’ve tried, all create a color-overlay on the selected file in Nautilus. This, especially with orange, almost always gives the icon a funky (in lack of a better word) color. Would it be possible to only color the background like this?

Screenshot-from-2018-01-03-15-24-20

5 Likes

Whoops, yeah, adding grey to the inactive elements text color makes sense. I’ll see how the current inactive text color works since Downloads and Home/Archives look very similar to me.

My only problem with using the full headerbar height is that it’ll only be the path-bar that uses it. The stackswitcher (which is the only other button that the underline effect would work well for) can’t replicate it.

I was thinking that it was too thin. Without a border around it (like Adwaita does it) it doesn’t really pop out, especially for the dark theme. Maybe we could do some testing with the border again? Right now checkboxes and I think switches use it.

On the blue, we really should do a poll or come to some sort of consensus. If we change the entry focus color to blue then I think it’ll be best if we just change everything to blue otherwise we’ll end up with stuff like the following:

blue

Not from what I’ve seen. The most I came out with was this:

.view:selected{ background-color: #ccc; background-image: linear-gradient(to right, #e95420, #e95420)

a

The folder becomes just a little darker since it’s being colored based on #CCC while the text background color is #E95420 since it’s pulling from the (fake) gradient. We can have this apply only to Nautilus.

4 Likes

PS: It might be good to create issues for the stuff where we agree.

This way, you can see which issues have been addressed yet and which haven’t, and you don’t have to repeat yourself. This all-in-one conversation is good for general discussion, but it becomes complicated to track individual issues.

Let me know if you need more permissions to triage issues etc.

4 Likes

Also, please, address one issue at a time with PR or it is really complicated to create new branches from master to develop something else

3 Likes

Thanks for the feedback!
Yes I’m with you with inactive windows, windows controls and the dock (still think we need a background), only the grey buttons are okay for me, I did get used to the grey quick.

Well (if I understood right), lot’s of time I don’t have to have a kind of warning or a kind of rating with multiple colors. That’s only useful and meaningful when it is warning to not go further. Lot’s of laptops would have the volume up to the red area, but that is not dangerous at all. Copy a file would also be dangerous at the end of the progress. I would stick to a single color.

That’s is okay for me - in your mockup the orange needs to be brighter (sometimes it is hard to see on a png) because the readable layer is too far away in contrast from the orange - so you have to focus your eyes on the contrast. For me, the actual way is fine and working for me.

Yeah, that looks much cleaner and more focused on what’s important! Maybe we can try without border in some circumstances like when having categories, in “Files” it maybe is too loose without (because of the crowded buttons).

Yes, true!

Also true, for me less like a warning because we get used to the orange over time. But making it less warning-like sounds good, not sure if we can borrow the buttons design/border to let them fit in and be less warning?
And speaking about nautilus, maybe @godlyranchdressing knows - did the icons like search/grid/settings get bolder?

It’s like changing orange to blue because of… blue! Here we better work with (a grey button border) gray, before it gets too colorful/nervous/unfitting. When using the blue, we should give it a “task” or meaning, like indication or time (like copy files). And that brings me to an other question: is the mouse circle (when loading stuff) also a part of the theme? I would then also use a blue with a different style, like in the Suru mockups.

Hm, maybe? You can try and decide, I guess. Is it enough noticeable?

Thanks!

I would suggest you filter the tasks from here to github issues until we are bugtracing?

Would be a good milestone, I will have another big session for testing and trying after the next update - please tell us when you create a new version with the latest changes.

And about buttons: did you change the colored buttons like the green/darker? In the software center they look nice, on the login screen they look still not polished.

Thanks, Stefan

5 Likes

I opened some initial “enhancement” tickets on gtk-communitheme. Some of them might have been already fixed by the last @godlyranchdressing merged PR, so feel free to close them if so.
I also preferred to keep the default github label names so far, but we can change them in “task”, “to be done” or whatever you like the most

2 Likes

I don’t know for sure, I haven’t actively been following the icon theme. It could be a color illusion.

Yeah, that could be done. I’ll see if I can get the colours to show up more often.

I think it’s something about the way the Shell draws things. I’ll see if I can make it look better.

Great! Sorry for the pull request/commit spam. I’ll make some issues myself.

2 Likes

No problem at all :slight_smile:

This question comes from Windows control: style buttons only when hover PR, that is actually changing in

So for this PR:

*   add square hover effect

my idea is that

As far as I can think of it, the box hover effect can be obtained only using images for the buttons. Currently the circular hover effect is performed by the button itself, if we want a bigger square and keep at the same time the “little” red circle inside, the circle should be provided by the image inside the button (so that the button boundaries can be expanded).

does anybody knows (@godlyranchdressing very likely :smiley:) if I’m wrong here?

PS: all ppa builds on launchpad are disabled until further notice as emergency measures [meltdown and spectre]. Meanwhile, you can build communitheme from source if you want to see the latest code.

1 Like

That sounds like the gist of it. Once there’s a mockup to work from we’ll need to recreate the look in the assets.svg file and then use background-image instead of background-color/border. That’ll let us use whatever dimensions we want.

Since it’ll involve more than just CSS I think it’s best we finalize the look of things before loading up Inkscape, though.

2 Likes