Cool to see the great progress on this.

I quick bit of feedback that I hope is useful. I tend to agree that the semantic distinction between "Theme" and "Style" is muddled. Perhaps it makes more sense to avoid those subgroups and simply rely on a rationale for the ordering of the modules. My own view of the ordering for Appearance is:

1. Color
2. Fonts
3. Icons (including emoticons)
4. Cursors
5. Window Theme
6. Desktop Theme
7. Widget Style
8. Splash Screen

My rationale for that ordering includes the following criteria:

• Easiest customization concept
• Customization impact (how many areas of the visual experience are affected by the customization)
• Preserves visual design language
• Easiest to discover or add new customization choices (GHNS, user installation, etc.)
• Helpful for accessibility

I did up a qualitative correlation matrix of this criteria here to help figure out how to sort it out: Appearance Module Correlation Matrix

So Colors, for example, is at the top of the list because most everyone understands the concept of color, it has a significant customization impact, it doesn't completely dismantle the default visual design language and it's easy to find new color schemes via GHNS. Widget Style ends up lower on the list because, while it has a significant customization impact, it almost completely dismantles the default visual design and there's no obvious way to discover and install new widget styles. I think it's ok if we swap around the position of a few modules whose scores in the correlation matrix are close (e.g. Widget Styles and Desktop Theme). Obviously the ordering will vary depending on how drastically different you judge each criteria.

I realize we could just use the ordering data from the card sorting study. But for the Appearance category, the ordering from the study is primarily informed by a history of the KDE Desktop that has arguably not had a holistic view of the visual design - so among the first things some users would do is a visual overhaul, especially as the visuals got a bit out of date. For the Appearance Category, I personally think it's ok to look forward with a little more confidence in the visual design and a fresh rationale.

Hope this is helpful. :-)

I would sort it in the same way. But we should really consider to avoid using "theme" or "style" for more than one group, as fbedussi said. What's about "Desktop Theme", "Window Decoration", and "Widget Style"? And I love the idea to have a supertheme that consists of all tweaks. A simple switch to mimic either Microsoft Windows, Mac OS X, or Tcl/Tk, and "KDE flat and monochrome". The selection of such a supertheme could be placed at the start page of the Appearance section (and all non-experts do not even have to care about the subtle distinction between theme and style).

One little thing to consider is how it will look when you're in the level 1 modules - eg 'Appearance'.

SySe has got to be usable at resolutions down to 1024x768 so i thought i'd scale Heiko Tietze's original mockups from the 'Top-level System Settings Interface' thread to see how they worked, here's how they looked (I've included the 'See also..' part in both):

http://element-6.deviantart.com/art/Sid ... 1400923513

I think we're limited to 5 level 2 pages max in each level 1 module in the "non-expert' mode before things start looking cluttered. We still need to make sure that we don't have loads of level 1 modules bunched together or the accordian 'tabs' (the rectangles that say 'Window behaviour', 'Notifications', 'Shortcuts and Gestures' and 'Activities') take up more and more of the sidebar not leaving much room for the level 2 pages themselves!

In 'Advanced' mode there's more room so the number of level 2 pages isn't really an issue!

It thought it did look much nicer for casual users with the big icons in 'non-expert' mode (and the clickable area was much bigger than in 'Advanced' mode too), personally i don't think we should just say 'we'll just shrink the icons in non-expert mode to be like the ones in Advanced mode'.

I think the idea to group icons together by anditosan was a good one (grouping Icon themes, icons styles, emoticons together). If we need to limit the number of level 1 modules & level 2 pages might it be worth having 'Icons' as a level 2 page within the level 1 'Appearance' module and have the 'Icon themes', 'icons styles' & 'emoticons' as tabs (yes the evil tabs) on the 'Icons' page? I bet 90% of the visits to the 'Icons' page won't want the last two 'Icon Styles' & 'Emoticons' tabs and the way Firefox 29 does it's tabs it very clean & uncluttered (Google it) - it still leaves the navigation difficulties but it won't add much visual clutter!

ken300 wrote:One little thing to consider is how it will look when you're in the level 1 modules - eg 'Appearance'.

Agreed. Anditosan is preparing a really awesome SySe design that uses another approach. This might solve some problems.
But please let's discuss questions about look and feel in the other thread ([Design Project] Top-level System Settings Interface). I know, this discrimination is artificial to some extend, sorry.

Heiko Tietze,

No problem!

I'd just noticed that earlier alake was saying that the distinction between 'Theme' & 'Style' is muddled. I wanted to have a look at your earlier layout scaled up to fit 1024x768 and see how many items it could cope with. I did the mockups for my own curiosity & thought i'd better post them here if we were limited to the 5 level 2 modules that they suggeted!!

Heiko Tietze wrote:I would sort it in the same way. But we should really consider to avoid using "theme" or "style" for more than one group, as fbedussi said. What's about "Desktop Theme", "Window Decoration", and "Widget Style"? And I love the idea to have a supertheme that consists of all tweaks. A simple switch to mimic either Microsoft Windows, Mac OS X, or Tcl/Tk, and "KDE flat and monochrome". The selection of such a supertheme could be placed at the start page of the Appearance section (and all non-experts do not even have to care about the subtle distinction between theme and style).

This has been promised to us since the early concept phases of Plasma Next (back when it was still codenamed Plasma 2), so we'll have to get the devs to deliver on that promise!
We should therefore design that section with this concept in mind and then present the devs with a "This is how we think it should look like!" that includes this.

Okay, everyone, the heat is on!
I've just promised Sebas that we'll have a categorization for him as soon as possible! The reason is that he'd like to get the new categories into Plasma 5.0, so that we'll have a kind of "stable API" of categories which KCM developers can use when porting their KCMs to Plasma 5, knowing that it will remain stable for the foreseeable future.

The problem is of course that when KCMs will be redesigned, they might get split up or merged, thus changing the organization. Therefore I could promise Sebas only stable categories on the first level, everything below that is subject to change later.
That means our focus has to be to create a set of 1st level categories which is "future-proof". We also have to think up the organization below that level which will be implemented in Plasma 5.0, but that may change later.

I think we can still use Heiko's suggestion as a basis for discussion, since it seemed most people here agreed with it mostly.
So this is what we've got so far:

Appearance
Workspace
Personalization
Networking
Hardware
Software

Software was introduced mainly to give 3rd Party KCMs a home if their developers don't assign a category to them. By now, I have come to thinking that this is not a good solution. Instead, we should provide clear guidelines so that 3rd party devs can put their KCMs in the right category.

What's missing here is a category for system-wide settings like Date & Time, Font Management, Startup & shutdown or Login Screen. The reason for this is that apparently, those have not been part of the card sorting from which Heiko's suggestion drew.
Personally, I think these should go into their own category even if they are thematically quite diverse, simply to make it clear for users on multi-user systems that - in contrast to the other categories - any changes they make here affect all users on their system.

I'd therefore keep them in a category called "System-wide Settings".

So what we'd have is:

• Appearance
• Workspace
• Personalization
• Networking
• Hardware
• System-wide Settings

So, please discuss! On Saturday evening, I'll send what we have to Sebas to implement it (unless I get the impression that either we reach a consensus on the first level categories even earlier, or that we cannot agree at all and should go back to the drawing board).
Then the next step is putting all KCMs in their (preliminary) new home.

So everyone get cracking, now it's for real!

colomar wrote:[So what we'd have is:

• Appearance
• Workspace
• Personalization
• Networking
• Hardware
• System-wide Settings

Look pretty good to me. Did you mean to exclude Software or do we just not have any kcms for that category (seems like File Associations would fit)? Also, since each of the other labels are essentially a modifier on "settings", might I suggest the last one function similarly? Like say "System" or "Computer" or something without "settings"?

Hopefully sebastian has what he needs to figure out what kcms should go into which top level categories. So, for example we don't end up with a plasma themes and window decorations under Workspace instead of Appearance. Otherwise all thumbs up from me.

Great, +1! (I would call the last category simply "System", because the "Settings" phrase is obsolete, as 1.) all the other categories do not contain that phrase and 2.) the modules inherit that property from the program itself (System Settings). Maybe we should rename the binary and the name of the application simply to "Settings", to solve the conflict with the subcategory?
If we plan to do the latter, better do it soon, to avoid breakage at a later point.

alake wrote:Look pretty good to me. Did you mean to exclude Software or do we just not have any kcms for that category (seems like File Associations would fit)? Also, since each of the other labels are essentially a modifier on "settings", might I suggest the last one function similarly? Like say "System" or "Computer" or something without "settings"?

I omitted Software because Heiko introduced it mostly to have a place where 3rd party KCMs would go, and I'd prefer for them to find a place in the other categories instead. If we find many KCMs which would fit into "Software" better than anywhere else, we can include it, of course.
About "System", I found it weird to have a System Settings -> System.
However,

kdeuserk wrote:Great, +1! (I would call the last category simply "System", because the "Settings" phrase is obsolete, as 1.) all the other categories do not contain that phrase and 2.) the modules inherit that property from the program itself (System Settings). Maybe we should rename the binary and the name of the application simply to "Settings", to solve the conflict with the subcategory?
If we plan to do the latter, better do it soon, to avoid breakage at a later point.

Changing the shell's name makes sense to me, because I wouldn't call all settings there "system settings". The problem with just calling it "Settings" could be that users might think it's just settings for Kickoff if they see it in there. Any other ideas for a new name?

alake wrote:Hopefully sebastian has what he needs to figure out what kcms should go into which top level categories. So, for example we don't end up with a plasma themes and window decorations under Workspace instead of Appearance. Otherwise all thumbs up from me.

No no, we need to provide that. I just wanted to focus on the top level first so we can give him that soon. Assigning KCMs to categories would be the next step for us (that's what I meant by "Then the next step is putting all KCMs in their (preliminary) new home.").

Thank you two for the input so far, keep it coming!

colomar wrote:Changing the shell's name makes sense to me, because I wouldn't call all settings there "system settings". The problem with just calling it "Settings" could be that users might think it's just settings for Kickoff if they see it in there. Any other ideas for a new name?

I had a look at how other "projects" handle this and I noticed they all (apart from Windows with "Control panel") call the application something like System Settings/Preferences so for the sake of being compatible with others we can simply leave the name, its more a philosophical matter (does the name describe something all the modules have in common or does it simply act as an hypernym?)
Personally I would try to find a better name for "System Settings" though, as if I would not know better by experience I would expect to find settings that affect the computer/system as a whole, i.e. all users.
We cannot use a more precise term though, as for example "Desktop Settings" would act as the other extreme, so my idea was simply to leave away the categorizing part of the name that tries to follow a hierarchy.
I see your concern though that users could confuse that with settings for a specific component, though personally "Settings" sounds that generic that I would not expect it to be of a specific component, because if it was, the specific component could be named easily.

Personally, my vote would be to leave the name 'System Settings' as it is.

All over the place in KDE is the word 'Settings' already, anyone that's not already familiar would be a bit confused if we changed from 'System Settings' to yet another 'Settings' (why are so many things all called 'Settings' - which one do i want?). Eg: Right-click the clock in the taskbar & you can access the 'Digital clock settings', right-click on the task manager and you get 'Task Manager settings' etc. etc. etc.

I'm not that keen on Colomar's suggestion of having a separate top level 'System-wide Settings' category for things that affect all users. IMHumbleO It would be better to keep those KCMs mixed in with the rest so that a normal user can find them (not separate them and hide them away) but find an improved way of making a user aware that what they were doing could or will affect all users. For example when you go to the 'Fonts' KCM & install a font it would ask 'install this for all users?', in the 'Date & Time' KCM there's something to make it really obvious that what you're doing is going to affect all users before you get to the stage where you hit the 'Apply' button. If we do end up with a 'System-wide Settings' category, I would just call it 'System-wide' though.

Just a quick rant - we've been asked by Colomar to do a specific, well focused task with a deadline and it seems a bit like things could be going off on a tangent a little bit. If Colomar goes back to Sebas in a day or two & says 'the VDG hasn't done what you actually asked us for - but here's a great new name for System Settings' then we're all going to look a bit silly. This is our chance to prove that the whole 'community design' thing can work & can get stuff done when it needs doing, maybe we should just all focus on what's been asked of us .

ken300 wrote:Personally, my vote would be to leave the name 'System Settings' as it is.

All over the place in KDE is the word 'Settings' already, anyone that's not already familiar would be a bit confused if we changed from 'System Settings' to yet another 'Settings' (why are so many things all called 'Settings' - which one do i want?). Eg: Right-click the clock in the taskbar & you can access the 'Digital clock settings', right-click on the task manager and you get 'Task Manager settings' etc. etc. etc.

Yes, that's the downside of changing it to simply "Settings". Maybe we can come up with an even better name, though.

I'm not that keen on Colomar's suggestion of having a separate top level 'System-wide Settings' category for things that affect all users. IMHumbleO It would be better to keep those KCMs mixed in with the rest so that a normal user can find them (not separate them and hide them away) but find an improved way of making a user aware that what they were doing could or will affect all users. For example when you go to the 'Fonts' KCM & install a font it would ask 'install this for all users?', in the 'Date & Time' KCM there's something to make it really obvious that what you're doing is going to affect all users before you get to the stage where you hit the 'Apply' button. If we do end up with a 'System-wide Settings' category, I would just call it 'System-wide' though.

Mixing them in would be possible as well, of course. Before deciding to do that, however, we'd have to see whether we'd find a good home for what's currently residing in the "System Administration" category (and which wasn't part of the card sorting study), though. These are:
- Date & Time (system-wide)
- Font Management (can handle both user and system-wide fonts)
- Login Screen (system-wide)
- Permissions (system-wide)
- Startup and Shutdown (user)
- Task Scheduler (user).

Okay, looking at these again, appears that there are only three KCMs which only contain only system-wide settings. So, where should we put them? From my perspective, putting any system-wide-only KCMs into "Personalization" would be contradictory.

Just a quick rant - we've been asked by Colomar to do a specific, well focused task with a deadline and it seems a bit like things could be going off on a tangent a little bit. If Colomar goes back to Sebas in a day or two & says 'the VDG hasn't done what you actually asked us for - but here's a great new name for System Settings' then we're all going to look a bit silly. This is our chance to prove that the whole 'community design' thing can work & can get stuff done when it needs doing, maybe we should just all focus on what's been asked of us .

It was the name of one category which lead us to side-track into naming the whole shell, so it was sort of necessary.
I do agree that agreeing on the categories has to be our priority now. Everything else comes later.

It seems to me like we agree on everything but System-wide and Software. If we find good new homes for all of those KCMs, I'm okay with putting them somewhere else and eliminating that category. For Software, it depends on wheter we think there are enough KCMs for which that would be the only category that makes sense.

colomar wrote:Any other ideas for a new name?

* Admin (or Superuser, All users, Multiuser)
* Cross System

Pro to remove this cat is that we have more space, con to me that 5 is a little bit unbalanced. Since both are very weak arguments I feel like 45:55% ,
We should consider l10n as well. Translators can add 'settings' on their own. Or we write very detailed guidelines.

Colomar,

One thing that springs to mind is that in some of the comments on Heiko's blog post with the prototypes of SySe on it (link: http://user-prompt.com/kde-system-setti ... avigation/) someone suggested that maybe we should target navigating with the mouse to advanced users who know where they want to go and target the search to casual users.

I suppose that if we did go down that path then the 'System-wide' category would make sense rather than trying to find other places to put those modules where they don't fit (yes i have just changed my mind - sort of). If casual users are lead towards the search function, then it makes little difference if the 'Date & Time' KCM is in one place or the other.

The problem is what to do with the modules that don't belong ONLY in the 'System-wide' category.