the dolphin look will change in 5.4 so it looks nice too you only have to wait some days

schnelle wrote:Breeze is flat. Very flat. And yet this thingy is 3D glossy looking:

Just as a heads-up this looks like it's already been fixed in 5.4. I'll double-check it when I personally move up to the new version, but updated screenshots have already been shown in the Breeze bugtracker.

Edit: errrr. what Andreas said.

hugo.pereira@free.fr wrote:

alake wrote:

hugo.pereira@free.fr wrote:The only (potentially serious) downside is the 'selected' checkboxes in menus and lists ...

Yup, definitely think we have some opportunities there.

Perhaps we could use the normal palette rather than the selection/highlight palette to draw the checkbox + make sure inside the checkbox boundary is filled (with the normal background color) not transparent?

Yeah, I remember you suggested something like this in the past already in the corresponding bug report. I 'think' I tried it locally and was not happy with the result, but I should probably try harder and possibly share the result with others.

Note:
for menus at least, this is in fact a non issue: since checkboxes and radiobuttons are on the extreme left side of the menu item, one could just start the selection rect to the right of it, with no overlap with the checkbox. I do not think that it would affect usability, but it would definitly fix the issue (in a way that is similar to what we had when selection was only a line below the active text).

The case with checkboxes in lists is more problematic: the solution above would definitly not work ... So ... will try yours again

Best,

Hugo

Here's a bunch of checkable designs; click the image below for a hiDPI look;



What I've done is shave 2px off of all the variations; I think everyone said this was the way to go. Going from top-to-bottom there's...

• Current, for comparison.
• Resized widgets. About the only other change to these (and all subsequent icons) is that I removed the shadows from disabled elements. This is so disabled elements don't pointlessly call your attention as much.
• The next version has the first colour tweaks; strict adherence to the Breeze pallet, and also style guidelines when it comes to the outlines, which are now 40% opacity black. Instead of focus elements becoming washed, these ones now move to blue. Tri-state checkboxes are slightly 'cleaner'. Disabled items are more obvious, and are strictly 20% opacity black shapes, (you cannot see it, but they have no backgrounds at all). Finally, this variant and all subsequent variants have slightly reduces shadow opacity (10%) compared to the current 20%.
• The next set is multicolour. This helps differentiate the checkboxes and radio buttons by colour. If we went this route, I'd like to see an OSX style switch where users can pick between one and multi colour widgets.
• After that is a set with thick focus borders. This is my personal favourite variant, as I think it would be really good usability to obviously highlight the current widget.
• Finally, a "detailed" set which adds details which adds the old tri-state style frame-in-frames. It makes checkboxes and radio buttons more obvious and I think is a usability win, but begins to diverge from the breeze 'less is more' approach.

Ken, you are so awesome! I just wanted to say that out loud. Those are interesting proposals!

Here's what I'm sorta thinking:

1. Start with the "W/ HIG Colour Guidelines" row
2. Make "Ready, Checked/Unchecked" look like "Focused, Checked/Unchecked"
3. Add "Thick Focus" outlines to "Focus, Checked/Unchecked/Tri-State"

I'd be curious to see how that looks.

alake wrote:Ken, you are so awesome! I just wanted to say that out loud. Those are interesting proposals!

Here's what I'm sorta thinking:

1. Start with the "W/ HIG Colour Guidelines" row
2. Make "Ready, Checked/Unchecked" look like "Focused, Checked/Unchecked"
3. Add "Thick Focus" outlines to "Focus, Checked/Unchecked/Tri-State"

I'd be curious to see how that looks.

I think I got it... So many widgets! @_@

I have 3 variants here; one with and one without the blue outer borders (from Focused states); B and C simply having different opacities for the outlines. I messged up the uploads, so you're only going to see the one extra variant. My thinking for "Alake B/C" is anticipating button outlines, so we can more closely match buttons and text-boxes. I figure these radios will serve as a bit of a blueprint for any fiddling with other widgets.

"Resized" for reference.



My new favourite is "Alake B".

Just as a follow-up to what I meant by matching the buttons, and kind of the overall direction I'm thinking when it comes to making everything match a bit better;



(very, very rough mind you; as usual click to get a hiDPI view)

I've also tweaked the blacks to use the same shade of "black" that the monochrome icons use; this way when in disabled mode we simply set the icon opacity to 40% and we get perfectly matched disabled buttons / icons.

Here's what it looks like if you run the logic through the rest of the widgets; feedback?

Note: Please remove this image from any quotes.

Hello,

I really like the blue outlines. They look much better than the current two shades of blue. However, the theme should be self-consistent. Maybe we could use the following associations : thin outline=hover, thick outline=focus and blue background=selection. The only widget where it wouldn't work is the tab bar.
I prefer the first version of the list. Rationale : I think the use of colorful backgrounds behind icons should be avoided (they lead to contrast issues). It works OK for the active button, because the background remains visible for only a fraction of a second. In lists, menus and default buttons, it just doesn't work − there were requests to make the icon white in the latter case, which is technically not feasible.

Nitpicking now:

Kver wrote:

• The tab bar feels disconnected from the frame (esp. at the corner).
• The frame and the lines between tabs have different colors.

Kver wrote:

• The two round corners of different radii (the button and the menu) feel weird to me.

Kver wrote:

• How does it look with the full list and window frames ? They will interact visually.

Edit: Fixed image URLs

louis94 wrote:Hello,

I really like the blue outlines. They look much better than the current two shades of blue. However, the theme should be self-consistent. Maybe we could use the following associations : thin outline=hover, thick outline=focus and blue background=selection. The only widget where it wouldn't work is the tab bar.
I prefer the first version of the list. Rationale : I think the use of colorful backgrounds behind icons should be avoided (they lead to contrast issues). It works OK for the active button, because the background remains visible for only a fraction of a second. In lists, menus and default buttons, it just doesn't work − there were requests to make the icon white in the latter case, which is technically not feasible.

Nitpicking now:

Hello, and YAY nitpicking! Thanks for jumping in.

Where :hover is really *broken* in terms on consistency is the text boxes, and immediately after leaving for the day it started to irk me too.

I like the idea of the stronger 2px line for hover highlights, since it would be immediately obvious for the colourblind and persons with impaired vision; but it can use more consistency than I have here for sure. For text inputs, what if we used the 2px outline for hover and active states, allowing the carat to distinguish *what* is active in the boxes. When I look at grey turning into blue, it's a very subtle change and I don't know if it's appropriate on an accessibility level.

On the left sidebar, we do have the dark grey for 'toggled' buttons which could be applied to the sidebar... But I'm a bit worried because traditionally the highlight has been used for the left-side bar. I'll mock it up to see what the result is, and depending on the result we'll nitpick from there.

louis94 wrote:The tab bar feels disconnected from the frame (esp. at the corner).

The tab bar design is from the design used in Kate; I don't know who made it, but I immediately groked the simplicity of it, and that it's more detached from the content container. The main issue I think is the larger corner radius, which I'll get into below...

louis94 wrote:The two round corners of different radii (the button and the menu) feel weird to me.

The logic I'm using with corner radii is that we have two "classes" of widget; containers and content. If the widget (like a list, menu, or frame) contains other widgets, it will user the larger radius so when things like buttons or text fields are nested, the spacing of the corner feels more natural.

The upside is when you look at a button near a corner or an item in a list it just "fits" better, even if its a but further away from the corner. The downside is that things outside the widget may not share the same radii. So, we can either go with things fitting nicer inside the widget, or things lining up better outside the widget.

I don't thin the different radii is necessarily all that much of an issue; progress bars, sliders, and scroll bars all have different degrees of "roundness", so if I had to pick my battles I'd throw my chips into having nested things appear to fit a bit better.

louis94 wrote:The frame and the lines between tabs have different colors.

We have a couple options here. And again, I've gotta explain the logic here, first.

I've given frame outlines 20% opacity, and widget outlines 40% capacity. Tabs are a real red-headed step-child since they are meant to be both interactive widgets, AND blend into potential frames. I think I just need to make 3 or 4 tab designs and see what the winner will be.

On a side note, this does point out that tick-marks on sliders are technically the wrong shade, so I will correct that.

louis94 wrote:How does it look with the full list and window frames ? They will interact visually.

I'm not quite sure what you mean by the full list... But with the window frames, it's a good time to bring up a couple things;

We were chatting it up in the VDG hangout, and one thing that was mentioned is defaulting to borderless windows. At this point we've seen several systems including OSX, Ubuntu (kind of), Gnome, and a few others show that borderless designs don't negatively impact usability.

So with that in mind we can turn to the cosmetics and functionality of window frames, and Breeze has significant room for improvement.

• We can't go edge-to-edge with things like video, browser displays, etc. It just makes these content containers look less professional, too. Also, any time a horizontal line goes across an application (like a toolbar line) it always leaves a little gap on the edge; again, unprofessional looking.
• It throws off spacing. Technically an application can never be "perfectly" spaced - there would always be more padding on the left, bottom, and right edges.
• Our particular implementation (make it look like more chrome) kinds of defeats the point of having borders in the first place (differentiating resizable sections of the window)
• It actually makes it *harder* to grab the edge of a window because the default border width (~3-4px) is smaller than the borderless grab margin (~8-10px).
• In some situations "gaps" can be exposed between the "seamless" edge and the application. E.g. resizing an application can do this.
• Not all applications respect the system colour palette, so you'll get window borders that look out-of-place in contrast to the application.
• Not all windows can be resized, so users need to rely on cursor cues as window frames aren't a bulletproof resizability indicator anyway.

So, yeah, unless there's any objections we'll be pushing for the default border to be set to "none".

And I can say, without borders this will all look *great* - as I get to window border designs you'll get to see the goal.

If the default isn't changed and we keep borders, we still have two options design-wise. The first option is to tweak the sidebar to look more like the current one. No biggie. Option #2 I'll be exploring in this thread soon, and that is changing it so the decoration border colour follows the titlebar colour, more like Windows. To me, this is a usability issue as much as it's a cosmetic issue; they are designed to give no indicator that you can do anything special, and they look broken under too many circumstances.

Later in this thread when I start targeting window frames I'll more formally propose changes based on defaulting to borderless windows, and what to do with bordered windows to improve usability.

Kver wrote:Where :hover is really *broken* in terms on consistency is the text boxes, and immediately after leaving for the day it started to irk me too.

I like the idea of the stronger 2px line for hover highlights, since it would be immediately obvious for the colourblind and persons with impaired vision; but it can use more consistency than I have here for sure. For text inputs, what if we used the 2px outline for hover and active states, allowing the carat to distinguish *what* is active in the boxes. When I look at grey turning into blue, it's a very subtle change and I don't know if it's appropriate on an accessibility level.

I wrote a small Web page with buttons, text fields and combo boxes featuring different combinations for focus and hover for everyone to test. You can download it here; use a recent browser (tested on FF 40 and Chromium 44).

Kver wrote:

louis94 wrote:The two round corners of different radii (the button and the menu) feel weird to me.

The logic I'm using with corner radii is that we have two "classes" of widget; containers and content. If the widget (like a list, menu, or frame) contains other widgets, it will user the larger radius so when things like buttons or text fields are nested, the spacing of the corner feels more natural.
(...)
I don't thin the different radii is necessarily all that much of an issue; progress bars, sliders, and scroll bars all have different degrees of "roundness", so if I had to pick my battles I'd throw my chips into having nested things appear to fit a bit better.

Kinda expected that answer... maybe pushing the popup 1-2px to the left would solve it. Will try on my html tomorrow.

Kver wrote:

louis94 wrote:The frame and the lines between tabs have different colors.

We have a couple options here. And again, I've gotta explain the logic here, first.

My logic was that the more colors there are in a given region, the less clean it feels. The GNOME folks solve this by not having any separator at all (see here). I'm eager to see your mockups.

Kver wrote:

louis94 wrote:How does it look with the full list and window frames ? They will interact visually.

I'm not quite sure what you mean by the full list... But with the window frames, it's a good time to bring up a couple things;

That's a common ellipsis in French, equivalent to "the full list frame and window frame". Not sure it's legal in English.

Kver wrote:We were chatting it up in the VDG hangout, and one thing that was mentioned is defaulting to borderless windows. At this point we've seen several systems including OSX, Ubuntu (kind of), Gnome, and a few others show that borderless designs don't negatively impact usability.
(...)
And I can say, without borders this will all look *great* - as I get to window border designs you'll get to see the goal.

Awesome news ! Maybe the left window shadow will need to be hardened a bit.

Edit: Fixed download link

Without having read all postings: Please make sure that checkboxes (and probably radiobuttons as well) work in lists. I faced the problem that a selected list item in blue overrides the (yet no set) blue check mark of the box. Unfortunately, I don't remember where it happened, but it should be easy to test in a real mockup.

I've just updated my live preview with check boxes and flat buttons; use a recent browser (Firefox 40 recommended).

louis94 wrote:I've just updated my live preview with check boxes and flat buttons; use a recent browser (Firefox 40 recommended).

Nicely done! I love it! Kudos for also using the style of animation I was thinking of for the 2px hover borders (with the thickening effect).

So, looking at your wonderful demo...
I like Checkbox #4 / Radio #4 which retains the frame based on focus and hover; this is better for keyboard navigation and is a usability win.
I could go for text input #2 or #3, but solely for consistency with the rest of design I'm leaning on #3.
We don't really to the text underline by default, so for the buttons I'd default to #4, and have the underline be an option.
For the select menus I'm thinking #6 even though technically speaking #4 is more 'true' to the 2px highlights; But in theory the menu is already "active" so it can justify the filled menu items.

If I can make some input on changes;

In Firefox the vertical alignment is off on checkboxes. You can fix this by setting vertical-align: middle; to your :before and :after tags. You can also set a negative top-margin after doing this to keep the boxes from looking too low: margin-top: -.2em;

One minor difference is text inputs which shouldn't have shadows; this is because they have the "sunken in" shadow (which, man, you have eagle-eyes to catch this stuff), and to help subtly differentiate them from buttons.

I also see that you're using shades of grey for the outlines, in your CSS use rgba(0,0,0,.2) and rgba(0,0,0,.4) for the borders. When using rgba borders, use background-clip: padding-box; to prevent the fill from seeping into the transparent border.

But, seriously, nicely done. *Applauds*

I like the checkbox designs, however I am not sure I like the combination of a thin black border and a blue filling in the unfocused-checked state. Alake B is my favourite too.
For the unfocused → hover → focused design I like this variant the most so far: 1px dark grey borer → 1px blue border → 2px blue border.

One thing we should consider is that there is currently not the resources nor the will to solve the issue that we can not change the color of the monochrome icons on when they are highlighted. So we should move away from the blue filling of buttons and highlights when they are pressed. Something like a grey-ish color seems more appropriate and has a better contrast than dark blue←→ black.

I agree with louis94 that the corner radii should be consistent, or at the very least when two UI elements appear in the same space e.g. the highlight and the context menu they should have matching radii or maybe one element should have none.

Also those 2px and 1px spaces between the underline of the tab and the separators and between the menu highlight and the menu gets a big no-no from me XD

Kver wrote:[…]Technobabble […]
One minor difference is text inputs which shouldn't have shadows; this is because they have the "sunken in" shadow (which, man, you have eagle-eyes to catch this stuff), and to help subtly differentiate them from buttons.

I think that warrants the question what lies beneath this metaphysical plane. Input boxes are recessed and appear to have white filling, while toggle buttons are recessed and have a grey-er filling.
Or maybe this plane isn't just a plane but actually quite thick, and cutting through it reveals another, white plane? I think the answer to these questions should have an effect on the intensity of the shadows used etc.
I propose that the closer an object gets to the screen the lighter the filling and vice versa, unless to cut through a really thick piece of the UI to reveal a white 2nd layer.

EDIT: My take on the context menu issue:

Sogatori wrote:I like the checkbox designs, however I am not sure I like the combination of a thin black border and a blue filling in the unfocused-checked state. Alake B is my favourite too.
For the unfocused → hover → focused design I like this variant the most so far: 1px dark grey borer → 1px blue border → 2px blue border.

This seems to be the popular idea, and as a whole it gives a little more flexibility for the variety of widgets - so I think logic and common sense dictates we move in this direction.

Sogatori wrote:One thing we should consider is that there is currently not the resources nor the will to solve the issue that we can not change the color of the monochrome icons on when they are highlighted. So we should move away from the blue filling of buttons and highlights when they are pressed. Something like a grey-ish color seems more appropriate and has a better contrast than dark blue←→ black.

I think we're moving in this direction anyways, favouring the 2px outline and toggle-style tint in lieu of the more distracting blue - which looks like it's going to be more of an animation tool, or action indicator. That being said, in areas where it makes sense (such as hovered menu actions) blue will still be the colour that's used, as it's just a common expectation. I'd also hate to wash the whole UI of all colour just because of icons, I don't think making *everything* grey is the solution there... But we can be a bit more reserved and smarter with its usage.

Sogatori wrote:I agree with louis94 that the corner radii should be consistent, or at the very least when two UI elements appear in the same space e.g. the highlight and the context menu they should have matching radii or maybe one element should have none.

Also those 2px and 1px spaces between the underline of the tab and the separators and between the menu highlight and the menu gets a big no-no from me XD

Yeah, the tabs need to be reworked. It's a case of me liking the design in Kate, but this is about creating a more consistent UI, and if these tabs don't work then I'm not keen to push a broken design. So, more experimentation is needed, and nest round will se tab designs much closer to what we have now.

On the corner radii, since it looks like we'll be going edge-to-edge with the next round of menus, I think we'll get to switch out the radius to the smaller variant. Depending on what we do with tabs, we may get to keep or lose what we've got for panes. This is iterative.

Sogatori wrote:I think that warrants the question what lies beneath this metaphysical plane. Input boxes are recessed and appear to have white filling, while toggle buttons are recessed and have a grey-er filling.
Or maybe this plane isn't just a plane but actually quite thick, and cutting through it reveals another, white plane? I think the answer to these questions should have an effect on the intensity of the shadows used etc.
I propose that the closer an object gets to the screen the lighter the filling and vice versa, unless to cut through a really thick piece of the UI to reveal a white 2nd layer.

It is slightly weird that text fields are more prominent than buttons. Right now we have a grand total of 1 widget with a deliberate gradient: buttons... If you consider the gradient used for inputs to simply be a shadow. Approached from this angle, it makes buttons the odd man out in the entire set; so next iteration I'll just remove the gradient. This also makes our rules on shadows consistent.

For figuring out planes and layers, I'm not overly concerned about trying to get into the metaphysics of a digital interface. We do have a bit of things getting lighter as we call importance to them, but I don't believe trying to be overly rigid in this regard unless it creates usability issues.

On a side note at this point I'd say the entire design is already pretty gradient-free; making the buttons some strange bastion of gradient-based depth effects is a bit ridiculous. If people want gradient-based depth effects, there's Oxygen. Just had to get that off my chest before someone says it and makes me fly off the rails.

Sogatori wrote:EDIT: My take on the context menu issue:

Hahahah, I think you're spot on with the "should be" part. #2 just fits everything better, as #3 seems to break a lot of consistency with the remainder of the widgets; there's too much line weirdness and it's a little hard to tell what's going on. #3 also breaks consistency linework. I think I like having the titles use a tinted background because it visually separates above and below better. So, yes, I think #2 should be the way to go.