Andrew (aka alake) summarized the discussion about system settings and created a wiki page. In order to formalize the result I started to add a couple of bullet points but realized soon that system settings are not well described without KCMs. So my addition concerns not only the shell but the KCM layout as well. At least it's a starting point for the discussion.

Here are my first thoughts: https://community.kde.org/KDE_Visual_De ... Guidelines

BTW: We need a good name for system settings, better than SySe or Kasymir.

PS: Andrew will add the see-as-well feature to the mockups.

Can't we just keep 'System Settings' as the name? There's really no need to go down the whole XMBC -> Kodi route just because people are bored with the standard name for a standard system feature,

I also agree. Just call it System Settings.

Kommando bridge like in star track (Kommandobrücke)

Thanks for all the replies. But actually the question of a good name is the least important. And I would be happy to get comments and additions on the guidelines for KCMs.

Sorry Heiko

Behavior
Show the selected setting in the navigation sidebar
Do not link to see-as-well KCMs within the same category.
Make sure a single KCM can run on its alone.

Appearance
Each modul has a header, description, preview section (if possible) and settings area
Separate simple content from advanced options, at best by using overall settings.
Single KCMs are just scroll areas. Do not use tabs. Use grouping instead of tabs
Layout the KCM content with two or three columns but not more.
Show advanced options when user want to configure the section via an edit button.
Offer import/export of overall settings via GHNS or on the hard disk.
Show GHNS ratings if possible

Thank you for starting this!
Comments so far:

To be honest, I don't think the HIG section structure really makes sense here. This is a concept, not a HIG. And "Is this the right control?" currently contains things which do not fit the section title. That said, I am absolutely certain that we do need a (or actually a set of) KCM design guideline(s). We do not need guidelines for the System Settings shell, because that is defined in the concept and then remains fixed.
Individual KCMs, on the other hand, do need HIGs for those designing them in order to prevent the hodgepodge of design solutions we currently see.

Therefore, I'd suggest merging the things in the "Is this the right control?" section with the "UI design Patterns" and "Layout Design" sections above (actually, much of it is already redundant with what's in there) and breaking out the Behavior and Appearance sections into a proper HIG.

The HIG will need to be expanded a lot. We need to look at existing KCMs, extract common patterns and establish the best ones. Currently we have a lot of cases where two or more KCMs do very similar things but in completely different ways. We need to fix this.
One pattern we might look at for the theme-related KCMs is https://techbase.kde.org/Projects/Usabi ... ter_Themes

colomar wrote:I don't think the HIG section structure really makes sense here.

Thats true we need an appropriate structure for finished design proposals. Even though it's not read by devs we should have a common understanding and a reference. In other projects I successfully apply this:
* Issue/Problem/Question
* Screenshot of exisiting UI (to illustrate the issue)
* Features/Functional Requirements (no solution here, just the list of functions)
* Heuristics/Nonfunctional Requirements (constraints for the design)
* New design/mockup

colomar wrote:The HIG will need to be expanded a lot. We need to look at existing KCMs, extract common patterns and establish the best ones.

We do not need to analyze the current KCMs since we want to introduce a new layout. And the balance between precise description and creative flexibility is crucial here.

Heiko Tietze wrote:The HIG will need to be expanded a lot. We need to look at existing KCMs, extract common patterns and establish the best ones.

We do not need to analyze the current KCMs since we want to introduce a new layout. And the balance between precise description and creative flexibility is crucial here.[/quote]

To be honest: The chance of a complete resign of KCMs happening in the foreseeable future is ~0. Redesign of the shell - yes. Fixing some issues and increasing consistency - yes. Completely changing the layout: Nice dream, but won't happen. Let's focus on what's realistic.

what I don't understand about KCM was, why is is so difficult to change something there.

In my naive thinking I would say you need a layout file for a module and you can fill this layout with different information from various moduls.

e.o.:
- header
- descritpion
- preview
- selection
- buttons (import, export, detail configuration)

I'm so wrong. and of corse there are two main layout types in the used KCM now and a view special layouts. So it isn't that much a redesign.

andreas_k wrote:what I don't understand about KCM was, why is is so difficult to change something there.

In my naive thinking I would say you need a layout file for a module and you can fill this layout with different information from various moduls.

e.o.:
- header
- descritpion
- preview
- selection
- buttons (import, export, detail configuration)

I'm so wrong. and of corse there are two main layout types in the used KCM now and a view special layouts. So it isn't that much a redesign.

In some cases (where KCMs are created via an XML file), that assumption is true. Even there, however, layouts like those proposed by Andy are not easily doable. If I rememver correctly, however, many KCMs are created directly from rather tangled C++ code, which makes it harder to change them.

If all KCMs were using QML, things would be much easier, but that is not the case.

colomar wrote:If all KCMs were using QML, things would be much easier, but that is not the case.

I cannot accept those exceptions as the default. Dealing with outdated code, styles, and structures is my business because companies fear to start from scratch. But KDE must not use 'legacy usability' in case of new developments.

what I don't understand about KCM was, why is is so difficult to change something there.

The problem is one of scale. Changing all KCMs requires changing each KCM individually. Regardless of the underlying tech.

If someone says "this KCM should be like that", that's fine and a realistic task..

When someone says, "we should change all the KCMs" that's a lot of hours of work. Not impossible, but somewhat daunting. It's not the sort of thing that's going to happen on a whim.

I understand you david and I don't want to say that the davs should do something. maybe it was possible to change one/some "standard" modules and with the knowlege of this it is possible that someone with less experience can work on the other modules. I'm someone how will say I'll do it, but I'm not an expert and so I don't do something because I think someone else can make a better job or I need someone else to be a mentor.

What I want to say is that when we have I would say 2-4 modules changed an voluntary (non expert) person can step in.

Key to getting anything done with an open community,, don't try to change 100 things at once, make one change a hundred times.

Pick /a/ KCM, change it to the new guideline, design it, and get it implemented.