I love the mockup anditosan, only I think the avatar above, although nice, occupies a little too unnecessary space on his right

Just one small observation:

Shouldn't the avatar and the "personalization" avatar be the same since both of them are refering to the user account?
In the Sidebar the avatar and the Appearance icon are the same and that can lead to confusion if someone just decides to go there visually.
Maybe make the Appearance icon the Personalization icon and come up with a new one for the Appearance topic?

Also, for the initial screen of System Settings I think that kver's ideas are great since there's no redundance of information in his idea between sidebar and initial screen.

Again, bravo for the great job and I can't wait to see this become a reality.

Thanks for picking up the width discussion. Unfortunately my second concern got lost a bit. So I throw it back in the ring and try to explain a bit more.

When I do a rough count in my system setting I find ~35 entries on top level with ~85 sub-level entries (those in the vertical tab-bar in each section). When I get your mock right, then the 85 are the relevant number (those would have to show up in the second column). Just to get this in your mocks you would need to show more than 9 times 9 items in the two available columns. This is far more than would be recommended from a psychological pov (5 to 7 would be an ideal number).

But this number really still is an underestimate when we take a look at where system settings will evolve to. True, there is some potential in restructuring the existing information. On the other hand we need to cope with at least two structural deficits in the current KCMs. Fixing them will have the number rise significantly again:

1. We need to integrate activity specific settings to a lot of KCMs. Currently you can see a sparkle of it at the power settings. Create yourself 20 activities and have a look...

2. One of the core attributes of KDE is its configurability. We should not loose it, just the opposite, we should even make KDE more configurable. System settings have to be prepared for this. This means, for most KCMs we will have to provide at a minimum level the option to have an additional section 'advanced settings' where the toxic settings can be put.

The good news about all this is:
Your design can easily be changed to fulfil all those needs. Make it more drill-down! Just add a bread crump for back-navigation in depth and use only one column for navigation on the same level.

I did a rough balsamiq sketch of it:

Start:
https://cloud.user-prompt.com/public.php?service=files&t=31293424de540aa69909c9e3d0f788e6

1st Level:
https://cloud.user-prompt.com/public.php?service=files&t=2f068b704c5871695488dfe45a0c3315

2nd Level:
https://cloud.user-prompt.com/public.php?service=files&t=19edf645aad08fed34d653be1c51c3af

3rd Level (could go any deeper):
https://cloud.user-prompt.com/public.php?service=files&t=24871915bdf87fa3f2d19d4666f07842

I think this would go perfectly with your general design idea, while giving us the flexibility we need to structure this enormous content!

Björn

bjoernbalazs wrote:Thanks for picking up the width discussion. Unfortunately my second concern got lost a bit. So I throw it back in the ring and try to explain a bit more.

When I do a rough count in my system setting I find ~35 entries on top level with ~85 sub-level entries (those in the vertical tab-bar in each section). When I get your mock right, then the 85 are the relevant number (those would have to show up in the second column). Just to get this in your mocks you would need to show more than 9 times 9 items in the two available columns. This is far more than would be recommended from a psychological pov (5 to 7 would be an ideal number).

Actually, The "Magic Number 7" does not apply here since the list is visible in its entirety and therefore does not have to be kept in working memory in order to find the item the user is looking for.

But this number really still is an underestimate when we take a look at where system settings will evolve to. True, there is some potential in restructuring the existing information. On the other hand we need to cope with at least two structural deficits in the current KCMs. Fixing them will have the number rise significantly again:

1. We need to integrate activity specific settings to a lot of KCMs. Currently you can see a sparkle of it at the power settings. Create yourself 20 activities and have a look...

True, we probably need another hierarchy level for those.

2. One of the core attributes of KDE is its configurability. We should not loose it, just the opposite, we should even make KDE more configurable. System settings have to be prepared for this. This means, for most KCMs we will have to provide at a minimum level the option to have an additional section 'advanced settings' where the toxic settings can be put.

We still haven't decided how to present the separation between basic and advanced settings, but I don't think adding another hierarchy level would be the best way to do it.

The good news about all this is:
Your design can easily be changed to fulfil all those needs. Make it more drill-down! Just add a bread crump for back-navigation in depth and use only one column for navigation on the same level.

I did a rough balsamiq sketch of it:

Start:
https://cloud.user-prompt.com/public.php?service=files&t=31293424de540aa69909c9e3d0f788e6

1st Level:
https://cloud.user-prompt.com/public.php?service=files&t=2f068b704c5871695488dfe45a0c3315

2nd Level:
https://cloud.user-prompt.com/public.php?service=files&t=19edf645aad08fed34d653be1c51c3af

3rd Level (could go any deeper):
https://cloud.user-prompt.com/public.php?service=files&t=24871915bdf87fa3f2d19d4666f07842

I think this would go perfectly with your general design idea, while giving us the flexibility we need to structure this enormous content!

Each additional hierarchy level also means another click and another search for the right item, though.

I really do think we need to minimize the depth of the hierarchy as much as possible. Two to three total levels at best, including the top-level. With the visible lists in anditosan's mockups, as colomar mentioned, we don't need to worry as much about the number of entries at a particular level. And really, I don't think we need more than the two visual list levels as in the mockups. We can accommodate a third conceptual hierarchical level with grouping or tabs in the content area.

No one need fear the VDG getting rid of KDE's legendary configurability: It's one of the design principles we're using to guide the visual design. Let me suggest that hierarchy depth does not equal configurability. We can employ our design chops to allow for configuration flexibility without employing deep hierarchies that make can make navigation (knowing where you are and where to go for what you want) difficult. On the first go around some kcms may well not fit perfectly. That's ok. That's always been understood. Over time the design impetus should be to redesign the settings for those kcms to better fit the hierarchy. Whenever we have the impulse to add another level, let's first think about how we can make it work within the first two to three levels. Are these settings redundant? Would these settings be better centralized? Would these settings be better merged with another settings? These are all solvable. But, to find those solutions, I really think we need some design discipline on the hierarchy depth.

Hope this helps!

alake wrote:On the first go around some kcms may well not fit perfectly. That's ok. That's always been understood. Over time the design impetus should be to redesign the settings for those kcms to better fit the hierarchy.

This reminds me of a general concern I have which we should address early on: As so often, we should learn from others' mistakes. In this case, from Windows Vista (which serves as a clear example for "Nice idea, bad execution" in many areas). For Windows Vista, Microsoft finally redesigned their system settings. Their goal was to make them feel more "lightweight", similarly to what we're doing. And actually, they didn't do such a bad job - with the main interface and those few settings modules which they actually redesigned. But then, as soon as you clicked any of the other modules, you felt like you just stepped into a time machine that beamed you back to 1995. From the world of vast open spaces, big, beautiful icons, descriptive text and easy to use controls back to tiny, gray dialogs full of tightly packed checkboxes.
It felt like one had nothing to do with the other.

I'm not suggesting we should wait with the release of the new System Settings until all KCMs have been redesigned, but we should find ways to make the old KCMs not feel totally alien in the new world. Do we have plans for how to approach this problem?

colomar wrote:I'm not suggesting we should wait with the release of the new System Settings until all KCMs have been redesigned, but we should find ways to make the old KCMs not feel totally alien in the new world. Do we have plans for how to approach this problem?

When I think of a bold and professional approach to lots of menus, I think of Adobe. They are really not afraid of shrinking content for the sake of providing an interface that includes all menus that you will most often use. Take for example, Photoshop (this is a mockup for new features)

https://dribbble.com/shots/1160621-Inte ... nts/150800

Notice how small the buttons, menus, text, controls are. For some odd reason that really feels professional to me. I wonder if we could make something like this happen. To shrink the elements in syse too fit the screen. That would help a lot in smaller screens. Not for all KCMs, since it doesn't apply IMHO, but at least on the ones that control graphical elements. I think also that having a web design for control panels is also a good idea. If we can somehow have all those KCMs just scroll down to where you need to be but without adding more tabs.

anditosan wrote:Notice how small the buttons, menus, text, controls are. For some odd reason that really feels professional to me. I wonder if we could make something like this happen. To shrink the elements in syse too fit the screen.

I think the problem with shrinking is that it would not be very friendly to those with sight problems.

davidwright wrote:

anditosan wrote:Notice how small the buttons, menus, text, controls are. For some odd reason that really feels professional to me. I wonder if we could make something like this happen. To shrink the elements in syse too fit the screen.

I think the problem with shrinking is that it would not be very friendly to those with sight problems.

Very true and I think that making elements bigger is actually something achievable via the System Settings. You can enlarge font, buttons, etc.

Very true and I think that making elements bigger is actually something achievable via the System Settings. You can enlarge font, buttons, etc.

Though by increasing the size for better readability it would cause them the same issue that you were trying to solve by shrinking.

I have some more to say on this but I'm typing on my phone at mo. It'll have to wait until Monday.

colomar wrote:I'm not suggesting we should wait with the release of the new System Settings until all KCMs have been redesigned, but we should find ways to make the old KCMs not feel totally alien in the new world. Do we have plans for how to approach this problem?

The one thing we'll have up on Windows is that we have (generally) been tackling the design work from the bottom up. i.e. We put the visual design guidelines in place, applied those to the design building blocks like the controls, icons, etc. and now we're moving into application level redesigns like we are now with the System Settings. (ideally, in between the building blocks and the application level redesigns, we should be also doing some work on design patterns, but for now we'll have to rely on our shared tribal knowledge). This approach was a conscious choice for prioritizing my own contributions, at least in part to address exactly what you describe: a jarring visual experience as you navigate from portions "touched" by the VDG to areas not yet "touched". Sure we've done some opportunistic work out of that order, but like I said it's been helpful to prioritize my contributions. So the existing kcms should at least benefit from the design work done on the building blocks, even if they haven't themselves yet been redesigned in terms of layout and functionality. That doesn't mean the kcms will look and work exactly the way we eventually would like them to. But they shouldn't be completely alien like the Windows situation was either.

My hope was that that approach should hopefully give us the breathing room to take this step by step approach to overhauling the System Settings. Of course, if there's some low-hanging fruit that can be fixed in existing kcms, I certainly don't think we should be shy about "picking" them.

alake wrote:My hope was that that approach should hopefully give us the breathing room to take this step by step approach to overhauling the System Settings.

If we integrate several tabs into one scrolling area, and perhaps some sections too, we cannot go ahead with the 'legcay' modules. Maybe it's not too much work but Andi's design is different from what we have now from both the module's layout and the navigation or organization. On the other hand, Bjoern's suggestion is easier to implement since we could only separate the tabs into single pages.

Heiko Tietze wrote:If we integrate several tabs into one scrolling area, and perhaps some sections too, we cannot go ahead with the 'legcay' modules. Maybe it's not too much work but Andi's design is different from what we have now from both the module's layout and the navigation or organization. On the other hand, Bjoern's suggestion is easier to implement since we could only separate the tabs into single pages.

I agree that showing multiple legacy kcms at the same time wouldn't work, but I don't think that's necessary or desired to support legacy kcms in anditosan's design. Integrating settings into different sections in the scrollable area is only a potential solution when we're talking about redesigning kcms, not supporting legacy kcms. There's no technical reason why using a tabbar at the top of the content area as a kcm switching mechanism will prevent use of legacy kcms. Whether to accommodate legacy kcms or redesigned kcms, I can't think of anything in anditosan's design that would be more or less difficult to implement.

Would it be possible to put all of the Theme stuff in one place? The difference between theming your application and theming plasma is lost on pretty much every non-technical person I know that uses KDE. Even after I explain it to them they don't get it. There should be one Theming KCM module or section that handles it all.

Tormak wrote:Would it be possible to put all of the Theme stuff in one place? The difference between theming your application and theming plasma is lost on pretty much every non-technical person I know that uses KDE. Even after I explain it to them they don't get it. There should be one Theming KCM module or section that handles it all.

Yes, we all want that, and it's the plan. We "just" need to convince developers to invest the effort to implement such a thing.