Based on the results of the card sorting we prepared this first idea. Full blog post can be found here: http://user-prompt.com/results-of-card-sorting-the-kde-system-settings/

1. Appearance
* Themes (aka Workspace) (Widget Style, Desktop theme, Cursor theme)
* Style (Window decoration, Splash screen, Gtk)
* Colors
* Font
* Emoticons
(Remark: Jens Reuterberg proposed some kind of mega theme at the KDE forum, which sounds pretty nice. But all topics need some categories to keep the navigation consistent. Another point for discussion is where Widget Style belongs to: Theme or Style? Again, we should take care of balancing the structure.)

2. Workspace
* Window behavior (Desktop effects, Screen Edges, Launch Feedback, Task switcher, KWin Scripts, Window Rules)
* Notification (Applications, System Bell)
* Shortcuts and Gestures (Custom, Standard, Global)
* Activities
(Remark: Can’t we just drop the beep support (aka System Bell)? Who owns and want to use an in-built speaker instead of jingles?)

3. Personalization
* Account Details (Password, Path, Wallet)
* Regional Settings (aka Locale) (Country/Region, Language, Spell Checker)
* Standard Programs (Default Applications, File Association, Desktop Search)
* Accessibility

4. Networking
* (Network) Settings (Proxy, Preferences, Certificates (aka SSL Preferences), +Network Manager)
* Connectivity (Accounts aka (PIM) Personal Information, Instant Messaging and VoIP, Social Desktop, Web Shortcuts)
* Sharing
(Remark: Network Manager settings should get an own KCM, which is being in preparation right now. Secondly, it is questionable if PIM accounts should have a central configuration since it’s applied in Kontact only. And, apparently from the study results too, the organization of web shortcuts is difficult and could be improved by another wording.)

5. Hardware
* Input Devices (including Keyboard, Mouse, Touchpad, Joystick, Remote Control, Camera)
* Display and Monitor (including Gamma)
* Removable Devices
* Printers
* Multimedia
* Device Actions
* Power management

6. Software
* Bodega
* Adobe Flash Player
(Remark: Apparently, Bodega is just an idea for future improvements. The topic could be extended by the distribution specific software management.)[/list]

Cool, will check on these and how they work on the settings

(Remark: Can’t we just drop the beep support (aka System Bell)? Who owns and want to use an in-built speaker instead of jingles?)

No, I consider this a bad idea... if you haven't got any speakers connected this can be useful. In-built speakers are by default in most PCs for decades already.

Nuc!eoN wrote:

(Remark: Can’t we just drop the beep support (aka System Bell)? Who owns and want to use an in-built speaker instead of jingles?)

No, I consider this a bad idea... if you haven't got any speakers connected this can be useful. In-built speakers are by default in most PCs for decades already.

Actually, I don't know if PCs nowadays still have them (neither my desktop nor laptop have them). PCs have built-in speakers connected to a soundcard nowadays, but not the old things that could only make "beep" in different frequencies. Okay I'm dumb. Of course we still have those for the error beeps. Seems like I just couldn't get mine to work within Linux.
However: What would that be useful for? Do you really want your PC to make that horrible low-fi beep when an event comes in?

Heiko, thanks for your enormous effort conducting this study, kudos!

Here are my 2 cents: I think Software being an own category is a bit of a waste, it is too special. I would rather find a different name for this category (like System), that defines itself, as affecting more users than the current user (Installed software will be system wide). Fitting in this category would be user management, firewall settings, system date/time, systemd settings (http://kde-apps.org/content/show.php/Kc ... ent=161871) etc.

Other than that the results make perfect sense, congrats!

To be honest I think the submodules should be rewritten from scratch with the aim of being consistent.

kdeuserk wrote:Heiko, thanks for your enormous effort conducting this study, kudos!

Here are my 2 cents: I think Software being an own category is a bit of a waste, it is too special. I would rather find a different name for this category (like System), that defines itself, as affecting more users than the current user (Installed software will be system wide). Fitting in this category would be user management, firewall settings, system date/time, systemd settings (http://kde-apps.org/content/show.php/Kc ... ent=161871) etc.

Having system-wide settings (which need root privileges to change) in their own topic would make a lot of sense, yes!
The Flash or Bodega settings which were suggested to be placed in the "Software" would not fit in there, though, because they're both "per user" settings.

Nuc!eoN wrote:

(Remark: Can’t we just drop the beep support (aka System Bell)? Who owns and want to use an in-built speaker instead of jingles?)

No, I consider this a bad idea... if you haven't got any speakers connected this can be useful. In-built speakers are by default in most PCs for decades already.

I just asked a developer and he didn't know of any situation where the "System Bell" settings module actually takes effect, since no KDE application calls the function which would activate the System Bell. Do you know of any actual use it has?

colomar wrote:I just asked a developer and he didn't know of any situation where the "System Bell" settings module actually takes effect, since no KDE application calls the function which would activate the System Bell. Do you know of any actual use it has?

Uuh I have no idea actually. I though it would be triggered on a new notification. I have never used it but I though of users who might need this - if I had no external speaker connected, I think I'd activate this feature for notifications (so I don't miss them, like e.g. a new message in chat or SMS). Well I might be mistaken of the usefullness of course. You might be right that in the end nobody uses it.

kdeuserk wrote:I think Software being an own category is a bit of a waste, it is too special. I would rather find a different name for this category (like System), that defines itself, as affecting more users than the current user (Installed software will be system wide).

'Software' has the advantage of duality with Hardware, i.e. I expect the other when I see one of both. 'System' is a nice idea, but I would rather replace Workspace with it because of the sixy organization and for a better discrimination between Appearance and rather non-visual aspects.

Heiko Tietze wrote:'System' is a nice idea, but I would rather replace Workspace with it because of the sixy organization and for a better discrimination between Appearance and rather non-visual aspects.

Hm, actually I found the idea to use "System" for all system-wide settings (in contrust to user-specific ones, which are the majority) pretty useful.

I would like to suggest some adjustments to the Theme and Style designations:
First of all the current designation into the two categories seems rather arbitrary. E.g. why is window decoration which is likely to be associated more with the widget and desktop themes in Style (as well as Gtk), while Cursor theme which seems more distinct and independent is in Themes?

I therefore propose the following scheme for organization:
Themes is for the set of things that are expected to have related appearance and have a strong association with the other theme settings:
* Workspace/Desktop theme
* Application/Widget theme
* Window Decoration
* GTK theme
Styles is for the set of things that are expected to be independently configurable/only have loose associations with other appearance settings:
* Cursor theme
* Splash screen
* Emoticons
* Screen Locker? (if included in Appearance, rather than Workspace)

Some things which are in the middle according to this scheme:
* Colors (expected to be independent, but themes are often tied to a particular color scheme)
* Fonts (largely independent, but some themes may have strong associations with particular fonts)
* Icons (largely independent, but may have strong associations with some themes)
My suggestion on these would be to put Colors and Icons under Themes and Fonts under Styles.
Others' opinions may differ, so feel free to comment/critique/propose other schemes.

Hi,
as a user I can't grasp the difference between "theme" and "style", or at least my definition doesn't seem to fit into the proposed classification. In my opinion a theme is a predefined set of visual items coordinated with each other (e.g. desktop theme, login them, ksplash theme, cursor theme, window decoration theme, color theme, ecc.), while style is some parameter I can change and tweak on its own (e.g. drop shadows color, font size, font color, ecc.).

Just my two cents

(by the way It seems to me there is a huge work going on on the visual side of KDE, very cool!)

airdrik wrote:I would like to suggest some adjustments to the Theme and Style designations:
First of all the current designation into the two categories seems rather arbitrary. E.g. why is window decoration which is likely to be associated more with the widget and desktop themes in Style (as well as Gtk), while Cursor theme which seems more distinct and independent is in Themes?

I therefore propose the following scheme for organization:
Themes is for the set of things that are expected to have related appearance and have a strong association with the other theme settings:
* Workspace/Desktop theme
* Application/Widget theme
* Window Decoration
* GTK theme
Styles is for the set of things that are expected to be independently configurable/only have loose associations with other appearance settings:
* Cursor theme
* Splash screen
* Emoticons
* Screen Locker? (if included in Appearance, rather than Workspace)

Some things which are in the middle according to this scheme:
* Colors (expected to be independent, but themes are often tied to a particular color scheme)
* Fonts (largely independent, but some themes may have strong associations with particular fonts)
* Icons (largely independent, but may have strong associations with some themes)
My suggestion on these would be to put Colors and Icons under Themes and Fonts under Styles.
Others' opinions may differ, so feel free to comment/critique/propose other schemes.

If removing the cursor theme from the Themes section then maybe change the name from "cursor theme" to just simply Cursor.
And I wouldn't name any of the categories inside of the Theme topic as "Workspace/Desktop Theme", "GTK Theme", "Application/Widget Theme". I would simply call them "Workspace/Desktop", "GTK" and "Applications/Widgets". The main topic is quite self-explanatory so no need to repeat "Theme" in every subcategory.

[quote="Heiko Tietze"]Based on the results of the card sorting we prepared this first idea. Full blog post can be found here: http://user-prompt.com/results-of-card-sorting-the-kde-system-settings/

1. Appearance
* Themes (aka Workspace) (Widget Style, Desktop theme, Cursor theme)
* Style (Window decoration, Splash screen, Gtk)

Also here, I noticed that the current GTK style packs 3 submodules in it. GTK Themes, GTK Icon Theme, and GTK Window Behavior. Would it make more sense to spread these around to other modules like Icons and Window Behavior? As I tried designing possible new modules, I see that gtk icon and window behavior just simply feel out of place when it comes to working with KDE styles

* Colors
* Font
* Emoticons
(Remark: Jens Reuterberg proposed some kind of mega theme at the KDE forum, which sounds pretty nice. But all topics need some categories to keep the navigation consistent. Another point for discussion is where Widget Style belongs to: Theme or Style? Again, we should take care of balancing the structure.)

Could we agree maybe that emoticons are less relevant than icons as far as usage? Maybe we can call the Emoticons section rather *Icons
*Icons (Icon themes, icons styles, emoticons)

anditosan wrote:Would it make more sense to spread these [parts of themes/styles] around to other modules like Icons and Window Behavior?
... Maybe we can call the Emoticons section rather *Icons

Good idea, emoticons as subsection of icons. Sooner or later we should consolidate the threads on SySe, run a user test IMHO, and start thinking about a (rather visual) guideline for KCM's itself. Where is the hammock man [1] when needed!