Well the first thing that I've come across that seems to be an obvious inconsistency is the liberal switching between horizontal and vertical layouts for very similar views., e.g:



Horizontal Add, Edit, Etc, Buttons, and....



Vertical Buttons!

Even with similar layouts the order of the buttons changes willy nilly, even though they are essentially for the same actions, for example:



The eagle eyed among you will have spotted that the 'remove' button is in second position on the first screen shot, but is now last in latter.

So, I suppose my question is, do we take the vertical layout approach, or the horizontal? Or do we keep on mixing it? And if we do decide on an approach, do we then dictate a button order?

Good spotted David! Well I guess what we go for is up to us

My idea is that we try to look not so much at whats available but what we would prefer in an ideal world. Just pretend you're a new user coming to KDE, you open up the settings - what would you prefer to see? How would you like it organized?

For me I'd like the buttons bigger. A lot bigger with more spacing and padding. But I also think the last two windows with vertical buttons have a bigger issue. The buttons refer to something that is intended to happen inside the window but seem divorced from it. Now it's half past three in the morning here and I have to go up in a few hours so no mockup but in my brain there isn't a list big enough that can't have buttons on top inside the same window to show that they belong to the list. That they are used to create, edit or delete things in that list instead of something on the side more related to "overview" or "help" than the list.

So say one horizontal buttons with "Add", then in the list let every single part of the list have a "move up/down", "modify" and "delete" on it's line instead of some random control. Up/Down is essentially arrows a symbol everyone can recognize, modify and delete can be icon+name. I mean try to make the things that BELONG together be close to each other and don't fear spreading things out a tad. One line or segment in the list doesn't have to be tiny, it can be a big section seperated from the others by either a line or by having the background in the list go "light grey"/"white"/"light grey".

Edit: ok what if you had, next to "Add" at the top, some blank fields with the things you have to fill out or that will get filled in for you? When you add it a new post gets added to the list below and you can there click the modify or delete or what have you on that section of the list. Oh and when I say "add on top" I mean inside the list window. Just keep an "Apply" button outside it.

While most KCMs indeed need to be improved, I see the current mapping of settings to KCMs and of KCMs to groups as maybe the bigger problem. Usually trying to find out in which KCM I can find a certain setting takes 95% of the time and effort for me, while figuring out how to actually set it is comparably "easy".

Therefore I don't think we can get around rearranging the whole system if we want usable Systemsettings as a whole.

And btw: What KlyDE did with Systemsettings was mostly rearranging (or simply removing) KCMs, so it does seem to be possible at least to some extent.

I do not know if this is off-topic, or whether it is linked to the oxygen theme, but I'd like to see replaced this ...

whit this

in the future

lazyit wrote:I do not know if this is off-topic, or whether it is linked to the oxygen theme, but I'd like to see replaced this ...

Sorry to cut you off here, but switches don't make much sense in a mouse+keyboard environment. They are great for a touch environment because there you can use them like real switches, but with a mouse, that's not the case. That's why it's explicitly stated in the KDE Human Interface Guidelines that they should not be used in Plasma Desktop. Gnome and Unity use them because they want to unify the desktop with the touch experience, but that means that you get a suboptimal experience in at least one of the environments.
therefore, we optimize Plasma Desktop for mouse+keyboard environments, where sliding switches simply don't make much sense.

colomar wrote:

lazyit wrote:I do not know if this is off-topic, or whether it is linked to the oxygen theme, but I'd like to see replaced this ...

Sorry to cut you off here, but switches don't make much sense in a mouse+keyboard environment. They are great for a touch environment because there you can use them like real switches, but with a mouse, that's not the case. That's why it's explicitly stated in the KDE Human Interface Guidelines that they should not be used in Plasma Desktop. Gnome and Unity use them because they want to unify the desktop with the touch experience, but that means that you get a suboptimal experience in at least one of the environments.
therefore, we optimize Plasma Desktop for mouse+keyboard environments, where sliding switches simply don't make much sense.

@ Colomar you're right and I apologize, because I did not know this. It is technically correct, but you have my eyes solution gnome is more beautiful. And for you? Not technically but for your taste ...

colomar wrote:Therefore I don't think we can get around rearranging the whole system if we want usable Systemsettings as a whole.

I have to agree with you that. I too find most of time in the settings is spent hunting for the correct module to go into, and I have been using KDE for a good few years now. The Date and Time module is a classic example of just how broken the system settings is, as you can set the date and time easily enough, but you have to go to the locale module to change the time format to either 12 or 24 hour! Crazy times.


As it stands though if it's not possible to re-arrange / combine etc at the moment then I still think this is a good exercise to do, as these elements will still be in the systemsettings no matter how the modules are arranged / merged etc.

My only concern @jensreuterberg is that if we get too crazy with ideas we might end up making things too difficult for the devs in question to implement and it will end up staying how it is, and we can't afford to let that happen really. Perhaps we should stick to re-arranging the existing elements, and creating a uniformed experience (like fixing the inconsistencies I mentioned above) first, then actually get that changed and rolled out, wait for feedback, and then if all is well look to change things significantly?

lazyit wrote:@ Colomar you're right and I apologize, because I did not know this. It is technically correct, but you have my eyes solution gnome is more beautiful. And for you? Not technically but for your taste ...

The screenshot from GNOME looks way better, we absolutely agree on that. I just don't think it's mainly because of the switches. It's because the KDE example is a huge tree with checkboxes in it, which is horrible. If you replaced the checkboxes there with switches, it wouldn't look better.
Therefore I think we can keep the checkboxes but have to get rid of gigantic checkbox-trees.

colomar wrote:Therefore I think we can keep the checkboxes but have to get rid of gigantic checkbox-trees.

Priorities wise I think the SSL module is very low indeed. I have never had the need to use it, and I don't know of anyone else who has either. Ideally we would need the input of someone who uses it before we make drastic changes to its workflow. There's nothing worse than having something changed by someone who does not use that thing, and although it might not look great perhaps the layout is optimal for those who do.

That being said, the change I would make would be to move bottom row of buttons to the side to match the other modules in terms of overall useability.

colomar wrote:The screenshot from GNOME looks way better, we absolutely agree on that. I just don't think it's mainly because of the switches. It's because the KDE example is a huge tree with checkboxes in it, which is horrible. If you replaced the checkboxes there with switches, it wouldn't look better.
Therefore I think we can keep the checkboxes but have to get rid of gigantic checkbox-trees.

One way you could see this is that there is a lot of text involved, and nothing happens if you click on the text itself. You'll have to navigate yourself to a checkbox (or slide in the Ubuntu case). An idea would be to merge text and their corresponding checkboxes into a clickable object, button if you like, that indicates in some way which state it's in (on-off). How this is done is not really the point, the point is that it's not necessary to have a seperate on-off element to an uninteractive description.

The solution to that is using checkboxes with labels, i.e. toggling the box when you click the text. UI which doesn't do that is simply broken and should be fixed.

Switches are, as said, a bad idea on the desktop. Let's stick with checkboxes.

scummos wrote:The solution to that is using checkboxes with labels, i.e. toggling the box when you click the text. UI which doesn't do that is simply broken and should be fixed.

Yep, that's what the HIG says, too: "Do not separate check box and label. Clicking on both the box and the label should toggle the option." Checkboxes alone are just too small click targets, so clicking the label instead comes naturally. If that doesn't work, the UI is indeed broken.

Not separating check boxes and labels definately makes a lot of sense. I would like to point out though that a common user would probably still go for the check box if it's not visually apparent that you could also click the label, and check boxes are small and just a tiny bit easier to miss with your mouse pointer. It would be nice if a common design principle would be to also visually link labels and check boxes so that it is obvious to a user that it doesn't matter where you click to toggle specific options.

If I am not completely wrong the pasted gnome screenshot is not compliant with GNOME HIG:

"...
Switches should be used for controlling services or hardware that have a clear on/off logic. They are particularly appropriate when those services or hardware do not activate immediately (ie. there is a delay between the switch being operated and it having an effect), or when they affect the operation of the system in a significant way.

Bluetooth is a good example of an appropriate use of a switch, therefore:

Bluetooth [ ON | OFF ]
And is more appropriate than a checkbox:
[✓] Enable Bluetooth

However, in many cases, toggling a state with a checkbox is appropriate. This, for example, is correct:
[✓] Repeat alarm daily"
...."
(taken from https://wiki.gnome.org/Design/HIG/Switches)

Therefore I suppose the gnome screenshot pasted here is not from an official gnome application.

So I do not think switches are only for touch/convergent devices. They have their logic (see above), but in the discussed case (ssl certificates) they would not be right anyway.

I think that introducing new widgets that are doing exactly same think as the old ones is a wrong direction (well, unless this is for touch sceen). Let's keep it simple and clear.