Sogatori wrote:Applied to the mouse cursor KCM I came up with something like this:...

Good compromise, and it offers all freedom to designers for a limited preview as Ivan suggests. However, the "more" expander should be placed below the selection area because it provides access to the expert options (tweaks for the selected item). And I like the original idea by Andi to have just +/- icons for "add (and remove) new theme". The dropdown is rather a placeholder, I guess. And again it's better located below the list.

Heiko Tietze wrote:

Sogatori wrote:Applied to the mouse cursor KCM I came up with something like this:...

Good compromise, and it offers all freedom to designers for a limited preview as Ivan suggests. However, the "more" expander should be placed below the selection area because it provides access to the expert options (tweaks for the selected item). And I like the original idea by Andi to have just +/- icons for "add (and remove) new theme". The dropdown is rather a placeholder, I guess. And again it's better located below the list.

Oh right, I forgot to mention that: Basically I was not sure about the "more" button, as we do not know how many themes a user may have installed so we can't know where the more button will show up. It could be directly in the users view, or below the visible area. Unless we'd go back to a no in-line preview abstract, which should save space.
As a compromise I put it below preview/modification area, so it would not fall out of view as the list gets longer. That's why I thought of combining the "currently in use" and the "preview area". Basically the user would select a theme, and could then tweak it to their liking. The preview on top would change with the changes made, while the selected theme in the list would stay the same.

I liked Andy's idea of the +/- buttons/icons, too. However, I don't know any area where we use them currently, so I left them out. If we started to use them more frequently I will be a happy panda . You are right about the location though. Though I have a question to you as a usability expert: Do you think it's good to disconnect the "remove theme" button from the location of what it's supposed to remove? If we are not to challenge the guideline in this regard the user has to select the theme and then move the mouse to the remove button on the (bottom) right. Whereas, if we'd show one of these circel-y remove buttons on hover as in my mockup, the action and the item would be spatially connected. The "add theme" button does not have this problem, because it adds something to no specific location other than the list.

Either way, thank you for your input

Sogatori wrote:I will be a happy panda . ...

Having add and remove together overrates the association between selection and the appropriate action, IMHO. Methinks right of the selection is good since it adds a full column of user friendly white space. Plus, the +/- should be added by default so it becomes a pandafication feature.

Sogatori wrote:...combining the "currently in use" and the "preview area".

Makes no sense to me, in general. Again, we are talking about the "guideline way" of KCMs.

By the way, your mockup shows a sidebar which part of the system settings framework and not the KCM. Therefore some buttons should be added - or perhaps shown depending on whether or not the KCM is being loaded standalone.

Heiko Tietze wrote:Having add and remove together overrates the association between selection and the appropriate action, IMHO. Methinks right of the selection is good since it adds a full column of user friendly white space. Plus, the +/- should be added by default so it becomes a pandafication feature.

Allright then, I will adapt the mockup to this scheme then later.

Heiko Tietze wrote:

Sogatori wrote:...combining the "currently in use" and the "preview area".

Makes no sense to me, in general. Again, we are talking about the "guideline way" of KCMs.

I know, and I am saying that the guideline is wrong in this regard. Saying that it's good, because it's in the guideline is a circular argument.
I am a bit confused now though, before you had no objections to this idea. Have you maybe overlooked this link? It explains my mockup more thoroughly. But you have to download it unfortunately to really see anything .

My understanding was that the KCM is always loaded in some king of shell around it. Either the System Settings one or the one for stand-alone display. These shells have different buttons. I could be wrong, in which case I will revise the mockup.

Sorry, missed that. I wouldn't change headlines/titles in any case (Used vs. Modified). And to me it's more logical to start at top and get more detailed by going down. The "Add Theme" thing was supposed to open the common GHNS dialog.
Anyway, I'd like to hear more opinions since this thread was supposed to be a touchstone for the guideline. Sure we can change it, but in this case I'd like to see more and different KCMs working with the idea.

Not that my opinion matters much but I really like the direction of the discussion so far.

I quite like the general layout pattern with the "In Use" section at the top and the "Available" section below with the inline preview selections. It provides really clear information to the user about what they're currently using and allows them to quickly scan and compare the available selections visually without depending on a preview. I assume the In Use section would change when the use clicks "Apply" which I think works well.

Generally I can think of a couple more common needs:

• Adding a theme (GHNS, local theme package file, or repository)
• Removing a currently installed theme
• More detailed settings for the active theme

My thought is that controls for adding and removing themes should be visually co-located with the Available section since that is what those actions apply to. In fact the control for removing a theme could be directly co-located with each theme in the Available section. Similarly, I think the control showing the more detailed settings for the active theme should be visually co-located with the In Use section since it affects the active theme. Anyway these are just my thoughts at the moment.

In any event, I think we'll end up with a really nice set of guidelines with really nice layout and interaction patterns.

First of all I agree with Andrew that we're making great progress in "HIGable KCM design" here!

It seems we mostly agree that the general layout as proposed by Sogatori would be a good way forward, so unless someone points out a major problem that we've missed, I'd vote for settling on this and working out the details.

Now my comments on some of the discussion points:

• Merged current theme preview / editing area: I'm with Heiko here. While I would not say that it doesn't make any sense, I still think the benefit of the more efficient use of space does not outweigh the drawback of a less predictable UI. KCMs are usually not very "dynamic" UIs and therefore users are not likely to expect certain areas within them to change their purpose at some point. I'd say changing section headings dynamically is a no-go, so if a design would require that, it should be reconsidered.
• Position of the add and remove buttons. I'm a bit torn here. On the one hand, I don't see a very clear benefit of grouping them together, since the processes for adding or removing themes are different anyway. On the other hand, I don't see a big benefit of locating the removing button close to the element to be removed either, simply because removing a theme is not likely to be a common action. It's not like in document editing or database manipulation, where one removes elements regularly. I'd say both variants have some benefits, both have some drawbacks, but none of them are game-changers. What I am sure about is that neither of the buttons should be above the list, because even for adding a theme, the usual process is more likely to be "Look whether one likes any of the themes in the list, and if not, add a new one" rather than going to the KCM with the purpose to add a new theme (while that will of course happen, it's not likely to be the majority of cases).

In general, it may make sense to first agree on how frequently we expect KCMs to be used.
My assumption is that KCMs are rather infrequently used, with the implication that clarity and ease of learning are more important than efficiency of interaction. We should keep in mind that when it comes to weighing those two against each other, the priorities are likely much different for KCMs than for regular applications.

Heya,

I updated the mockup based on the feedback in this thread. I also had a fruitful discussion with colomar and anditosan yesterday.
→→→Please click here for an interactive demo ←←←

What I changed:

1. I shortened the amount of shown cursors as requested. We will have to settle on which one to show at some point further in the discussion
   
2. The add and remove button are the same as in anditsan's original mockup
   
3. Clicking the "add" button should open a new window
   
4. I removed the subtext that lists the size available in each theme. I did so because you will see the sizes when you open the "more" section. Simple by default, you know
   
5. The top preview now just shows the currently used theme.
   
6. I went back too the roots with the list of available themes. Anditosan and I had a nice discussion on the problem of the configuration area moving out of the screen when there are too many themes in the list. I condensed the list so even quite a few themes should fit in there without taking up too much vertical space
   
7. The settings are divided into two parts, "global" and "local" settings. "Global" settings is in this case the theme resolution. In other KCMs it could be the windeco button order and so on. Because there's a problem of too long lists too obscuring these "global" settings, they are mirrowed in the "local" settings section at the bottom of the theme list too. Like here:

So, here we go again. After some talking behind the scenes here comes the next iteration.


The Previews are further compressed to allow for more space and the subtext was removed, as it didn't seem to be all that important after all.

An important difference is how we deal with many possible themes to select. I opted for a at max. two row long list which turns into a looped, paged carousel view when more space is required.

Only 2 rows at max to limit scrolling and a paged carousel to minimize scrolling and clicks necessary to see more themes.

The "more" button should reveal the resolution settings as they are currently not theme specific settings and I doubt the devs want to change anything about that.


I put them into the hidden area, because I do not think that people commonly change these settings a lot. I could be wrong though, in which case we could move it to the always visible settings area bellow its current position. Explanation in the picture below.

Picture or it didn't happen

Heiko Tietze wrote:Picture or it didn't happen

Login to the KDE own cloud and you will see them.

Heiko Tietze wrote:Picture or it didn't happen

Ok I tried to fix it. I was able to see the pictures the whole time, but I hope you now can see it too.

Thumbs up, esp. for the explanatory picture which could be added to the guidelines. Some comments:

I'm not a fan of the theme specific (we should use setting/config/module etc. here) setting section, though the reason to tie it together make sense. And on the fly I don't see need for it, no KCM that includes specific settings. Maybe that's because it's not clear distinguished what is specific and what independent. Room for interpretation...

Your preview is labeled Breeze but what do we do when it's tweaked? 'Breeze (changed)' or 'User defined'. Btw, the currently active selection should be reflected somehow in the list/carousel below.

I've never seen a carousel in Qt. Looks nice but might be challenging for devs.

I'd suggest to double check the design with a different, more complex KCM. And maybe a non-visual as well. Started last year with networkmanager (http://user-prompt.com/reprise-of-akade ... k-manager/).