About the switch: The HIG says that boolean options using a checkbox must not apply a sliding switch: "Do not use sliding switches in Desktop applications. They only offer good user interaction on touch screens, so they should only be used in applications for Plasma Active."

Heiko Tietze wrote:About the switch: The HIG says that boolean options using a checkbox must not apply a sliding switch: "Do not use sliding switches in Desktop applications. They only offer good user interaction on touch screens, so they should only be used in applications for Plasma Active."

Ah, good catch, so everything is already done in that regard.

I love where this is going in general and I am very impressed with the productive debate. I would like to highlight one thing I think needs to be addressed both in the original proposal and the various suggestions: The enormous size of certain elements!

To quote a few others who noticed this as well:

scummos wrote:What immediately strikes me is that all the UI controls (esp. combo boxes, radios) are really huge. Is there a reason for that?
Tabs and buttons are pretty as suggested.

othersimon wrote:- I agree with scummos about the size - maybe slightly smaller for the radio button/slider button etc.

GreatEmerald wrote:

Nuc!eoN wrote:Hm, if truth be told, I'm not sure about this. It looks extremely big and clumpsy to me... IMO it should just be a little more.. subtle. This looks like some UI designed for a tablet.
Just my first impression though. But I appear to be the only one?

A bit. This must be due to the checkbox, radio button, slider handle and drop-down boxes. Other elements are in fact of the same size as it is right now. However, I don't think it's a bad thing, given that resolutions nowadays are typically large enough to support that (although some sort of scaling down option would be awesome for things like netbooks).

I think I speak for all of us when I say that - while the scroll bars are beautifully slick, befitting the flat and light new look - this is not the case for a number of elements that feel clumsy and simply misfit: the radio button, slider handle, checkbox, busy indicator, and the switch are huge and overpower the rest of the theme. I don't think this has that much to do with DPI since I am looking at screenshots only and compared using different sized screens. I am quite sure that making them way smaller will make the whole theme come together.

Ok, now I try some of the previous ideas with smaller controls:



18 seems to be a good size for radio buttons and the slider handler

Could it be possible to implement something like what Qt-Quick has with the ability to customise how round elements are?

Thanks for all the feedback. I'll try to get address everyone's feedback so far, but it's so much I hope I don't miss any one!

@Paulms Great gold-star feedback on the control appearance and sizes! Thanks! With both your's and mutlu's feedback I think I can find something that works.

@verbalshadow Thanks much for your gold-star comment with that idea for the busy indicator. I'll take a look to see how it works later this evening.

@Sogatori Oooh nice, thanks for sharing those Mochi busy indicators! Lots of good ideas there to chew on. Maybe a someone here is interested in taking a stab at the design for a busy indicator? I'd be very interested to see what you guys come up with. Any takers? Just remember the color palette.

@Heiko Tietze Yeah, the underlines are an active focus indicator. We may have to look at a different solution there. Thanks for the pointer!

@mutlu you're feedback on the heaviness of the checkbox and radio button in comparison to the scrollbars is well taken. I have some ideas for moving them in the direction of the scroll bar aesthetics. Of course, I welcome any other ideas folks have in this area.

@GreatEmerald Thanks much for taking the time to provide your feedback. I'll address the subset of your feedback specifically related to the UI controls design in my more general comments below.

Regarding the size of the radio button and checkbox controls, thanks for all the great feedback from everyone! The size was reduced a bit in my latest update (see the pic in my previous comment), but I'm open to reducing the size just a touch more. They will be intentionally a little larger than the tiny checkboxes and radio buttons of the past though.

Regarding rounded corners; In my latest update (see the pic in my previous comment) the corner radius is 2px for all controls. Consider your feedback on corner-rounding heard loud and clear. So it may well end up with a 3px corner radius (no greater) but it'll stay at 2px for now.

Regarding gradients; we may well eventually use gradients of some kind somewhere in the design, but for now let's try to find design solutions (with or without gradients) that don't result in an optical bulging of the controls (even if it's subtle). Great Ideas though, so please keep them coming!

Thanks everyone for your great feedback! Please keep them coming. I'll try to make some updates again today and post an update. Thanks again and keep the ideas coming!

Hey alake,

could you maybe explain what "chanelIdx" is in ColorUtils.js? Also, in the "blendColors" function, I presume the percentage defines how much of colour 1 is blended into colour 2?

Also, do busy indicators have to be in QML, or can they also be .gif/.svg?

alake wrote:I have some ideas for moving them in the direction of the scroll bar aesthetics. Of course, I welcome any other ideas folks have in this area.

Sounds good.

alake wrote:I'm open to reducing the size just a touch more. They will be intentionally a little larger than the tiny checkboxes and radio buttons of the past though.

Sounds good to me as well.

alake wrote:Regarding rounded corners; In my latest update (see the pic in my previous comment) the corner radius is 2px for all controls. Consider your feedback on corner-rounding heard loud and clear. So it may well end up with a 3px corner radius (no greater) but it'll stay at 2px for now.

How is that 2px? I mean, if that's 2px, then how does 1px look like? I see no possible middle ground between no rounding and what you have there (which is literally one pixel removed from the corners).

alake wrote:Regarding gradients; we may well eventually use gradients of some kind somewhere in the design, but for now let's try to find design solutions (with or without gradients) that don't result in an optical bulging of the controls (even if it's subtle).

I find "bulging" to be an important part of what makes a button a button. It's again a psychological thing: if you see a wall with something "bulging" from it (which means everything is smooth except that part), you instinctively want to flatten it, and nowadays also expect something to happen once you do. If you see an area being framed, you don't want to touch it, because it might be important, and if something will happen if you touch it, it will probably break it instead of making anything better (but most likely nothing will happen). Similarly, if you see a door, you want to go through it. If you see a door painted on the wall, you definitely don't try to go through it.

Sogatori wrote:could you maybe explain what "chanelIdx" is in ColorUtils.js? Also, in the "blendColors" function, I presume the percentage defines how much of colour 1 is blended into colour 2?

Sure, that's shorthand for the channel index. so if the color is an ARGB hex like "#78FF0000" the alpha channel would be 0, the red channel would be 1, the green channel 2 and so on.

Also, do busy indicators have to be in QML, or can they also be .gif/.svg?

Good question! So if you want the control to use colors from the current system color scheme then yeah, QML will be easier. But if we come up with a busy indicator that works well with all color schemes then we can use an image, preferably svg since that will scale with different DPI scale factors.

Hope this helps!

GreatEmerald wrote:How is that 2px? I mean, if that's 2px, then how does 1px look like? I see no possible middle ground between no rounding and what you have there (which is literally one pixel removed from the corners).

It is 2px because that's what it is. You're welcome to either take my word for it or look at the QML directly. Since I'm coming to the community for help, I'm hoping it is self-evident that I have no motivation to mislead folks here about this.

I find "bulging" to be an important part of what makes a button a button. It's again a psychological thing: if you see a wall with something "bulging" from it (which means everything is smooth except that part), you instinctively want to flatten it, and nowadays also expect something to happen once you do. If you see an area being framed, you don't want to touch it, because it might be important, and if something will happen if you touch it, it will probably break it instead of making anything better (but most likely nothing will happen). Similarly, if you see a door, you want to go through it. If you see a door painted on the wall, you definitely don't try to go through it.

There are many examples of buttons both in the real world and in successful UI designs that don't bulge and where users verifiably use them as successfully as bulging buttons. Let's try not to busy ourselves with crafting untested arguments for why buttons should or should not bulge. Bulging buttons are a fine design choice. So are non-bulging buttons. I'd like to encourage us to understand that it's ok for us to make design choices without burdening ourselves with developing complex but fragile rationale for why any choice is the only right choice. I'm eager to see what we can come up with, so let the ideas fly!

alake wrote:It is 2px because that's what it is. You're welcome to either take my word for it or look at the QML directly. Since I'm coming to the community for help, I'm hoping it is self-evident that I have no motivation to mislead folks here about this.

I did not mean to imply that. I'm genuinely curious, because that doesn't seem right. I'm also wondering if the guidelines were written with that in mind (that 1px is nothing at all, or something?).

alake wrote:There are many examples of buttons both in the real world and in successful UI designs that don't bulge and where users verifiably use them as successfully as bulging buttons. Let's try not to busy ourselves with crafting untested arguments for why buttons should or should not bulge. Bulging buttons are a fine design choice. So are non-bulging buttons. I'd like to encourage us to understand that it's ok for us to make design choices without burdening ourselves with developing complex but fragile rationale for why any choice is the only right choice. I'm eager to see what we can come up with, so let the ideas fly!

Well, users use Wine with its Win98 appearance successfully as well. That doesn't mean it looks good or can't be improved upon. I'm also not saying that it's the only right choice; I'm stating my opinion more than anything here. I doubt anything flat can look as natural as gradients do on buttons. Of course, if there are any other ideas about it, then I'd love to see them.

GreatEmerald wrote:

alake wrote:It is 2px because that's what it is. You're welcome to either take my word for it or look at the QML directly. Since I'm coming to the community for help, I'm hoping it is self-evident that I have no motivation to mislead folks here about this.

I did not mean to imply that. I'm genuinely curious, because that doesn't seem right. I'm also wondering if the guidelines were written with that in mind (that 1px is nothing at all, or something?).

QML seems to work in a bit odd ways with small corner radii. Here are closeups of radii from 1 to 4:

Well, how do you make a 1 pixel radius circle out of square pixels?
To me the behaviour looks more or less like what one would expect.

Thanks for the image! I suppose it would be right if you draw circles, but then I disagree with the guidelines. 1px is nothing at all, 2px is one pixel removed, only at 3px does any real smoothing start, and only 4px is what I'd call not threateningly sharp.

So I updated the checkbox and radio buttons and reverted to simpler tabs for the time being (plus a couple other minor updates).



Thanks much for your help and keep the ideas (especially for the busy indicator) coming!