Make the Window Decoration themes' Configure buttons more obvious
ClosedPublic

Authored by ngraham on Mar 10 2018, 4:51 AM.

Details

Summary

As documented via bug reports and online support requests, many users have difficulty learning that window decorations are customizable, because they don't notice or understand the little icon-only button in the bottom-left corner of each theme preview.

This patch centers the buttons and adds text including the theme name , making it obvious what the buttons are for.

Also, clicking on one of the buttons now automatically selects its corresponding theme, because configuring an un-selected theme doesn't make a lot of sense and could lead to user confusion once this UI is more obvious and widely-used.

BUG: 390245

Test Plan

  • Clicked on the configure buttons; each one selects its parent theme and opens its configuration dialog

Diff Detail

Repository
R108 KWin
Branch
more-obvious-configure-button (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham created this revision.Mar 10 2018, 4:51 AM
Restricted Application added a project: KWin. · View Herald TranscriptMar 10 2018, 4:51 AM
Restricted Application added a subscriber: kwin. · View Herald Transcript
ngraham requested review of this revision.Mar 10 2018, 4:51 AM
ngraham edited the test plan for this revision. (Show Details)Mar 10 2018, 4:52 AM
ngraham added a reviewer: cfeck.
ngraham edited the summary of this revision. (Show Details)Mar 10 2018, 4:55 AM

Personally I think this area too much clutter to the UI.

Fuchs added a subscriber: Fuchs.Mar 11 2018, 2:46 PM

Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.

In either case the button looks like it is part of the preview and not really a button to press.

So I wonder: does it even make sense to have a configuration button for a theme you are currently not using? Wouldn't it make more sense to have the configure button not per preview / theme but rather in the UI below, where the other buttons that are clearly buttons are?

Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.

In either case the button looks like it is part of the preview and not really a button to press.

So I wonder: does it even make sense to have a configuration button for a theme you are currently not using? Wouldn't it make more sense to have the configure button not per preview / theme but rather in the UI below, where the other buttons that are clearly buttons are?

Yea, that sounds good.

abetts added a subscriber: abetts.Mar 11 2018, 4:09 PM

What do you think of having the configure button have the blue highlight and be in the middle of the window instead of a border? This can help to make a more odd placement and make it stand out.

What do you think of having the configure button have the blue highlight and be in the middle of the window instead of a border? This can help to make a more odd placement and make it stand out.

Something like this:

Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.

In either case the button looks like it is part of the preview and not really a button to press.

So I wonder: does it even make sense to have a configuration button for a theme you are currently not using? Wouldn't it make more sense to have the configure button not per preview / theme but rather in the UI below, where the other buttons that are clearly buttons are?

+1

Whilst I like the labeled one more than the current one, I can't say I'm a huge fan of either.

In either case the button looks like it is part of the preview and not really a button to press.

So I wonder: does it even make sense to have a configuration button for a theme you are currently not using? Wouldn't it make more sense to have the configure button not per preview / theme but rather in the UI below, where the other buttons that are clearly buttons are?

+1

This same thought came to me yesterday!

+1

ngraham planned changes to this revision.Mar 12 2018, 4:19 PM

Yeah, I'm going to work on moving the button outside the preview.

KDE 4 (and early KDE 5?) used to have all the buttons in the bottom. I'd say I'm a fan of how it used to be.

Or... we can follow the idea I have been meaning to make true and use something like a mouse hover with controls that appear on demand:

https://phabricator.kde.org/M112/415/

I think that would be pretty cool

Honestly I'm not a fan of invisible controls that appear on hover because they're user-hostile: on the desktop, you can miss them if you're not in the habit of randomly flinging your mouse all over the place, and on a touch UI, they're completely inaccessible because there is no concept of "hover".

What's wrong with a good old fashioned always-visible button with text? No need to re-invent the wheel every 5 years IMHO.

Honestly I'm not a fan of invisible controls that appear on hover because they're user-hostile: on the desktop, you can miss them if you're not in the habit of randomly flinging your mouse all over the place, and on a touch UI, they're completely inaccessible because there is no concept of "hover".

What's wrong with a good old fashioned always-visible button with text? No need to re-invent the wheel every 5 years IMHO.

Well, you have to think that mobile interfaces do have a form of hover when someone rests their finger on there. I feel you are tailoring too much to mobile when we know that there will be different versions of this and we are not building a mobile version at the moment. Also, "invisible" is not a word I would generally associate with hover. Plus, you are basically trying to give configuration power to something that isn't even enabled, which aligns with "powerful when not needed."

I think it is a mistake to think that design does "not" need to evolve. Just because it was done like this 5 years ago, doesn't mean it is liked currently. Design is something that is constantly evolving and one way to make sure that users feel vibrant about your work is to provide them with design changes that feel like, and this sucks, but it's true, the rest of the current UIs they are using.

Design needs to evolve when something new comes along that's genuinely better. Design does NOT need to evolve simply to keep up with the latest UI fashions. I feel very strongly about this. We can and should evolve our designs to be better, but we cannot afford to change our design every few years just to "keep pace" with other changes in the wider world. It drains already scarce resources in the FOSS world and usually becomes the blind leading the blind, because very few of these changes that we might otherwise want to emulate are actually any better, just different. It's just change for change's sake, and users hate that.

True beauty requires confidence, but trying to keep up with the latest fashions signals precisely the opposite.

Fuchs added a comment.Mar 12 2018, 5:35 PM

Please definitely no hover. Whilst I agree that some things get way too tailored for other form factors, this is not one of them. I just very recently discovered that the plasma theme chooser has a preview button that magically appears on hover, so I agree with that being hard to discover and user hostile.

As for evolution: evolution, by definition, means that things get better. I still don't see the advantage of a per-theme button that is somehow "hidden" in the preview, so unless I am missing something here (feel free to tell me) I fully agree that going "back" to having it outside, with the other buttons, is the best and most user friendly solution.

Options are on the table. Now we need to move forward with this patch. Is there more discussion needed?

Not really. I'm going to change the patch to put the configure button outside the previews. Just need to actually do the work!

rkflx added a subscriber: rkflx.Mar 13 2018, 10:01 AM

-1 for hover in the config dialog. Hover should be used only in very rare cases where there are alternatives or it is 100% obvious it will be discovered (e.g. Gwenview's hover buttons).

I can see where the idea to have it inline comes from (different config dialogs per theme), but I'd say external buttons are easier to work with (e.g. keyboard navigation is totally broken with the current approach). To solve this dilemma, I'd put the name of the selected theme on the external configure button, e.g. Configure Breeze, Configure Plastik etc.


Design needs to evolve when something new comes along that's genuinely better. Design does NOT need to evolve simply to keep up with the latest UI fashions. I feel very strongly about this. We can and should evolve our designs to be better, but we cannot afford to change our design every few years just to "keep pace" with other changes in the wider world. It drains already scarce resources in the FOSS world and usually becomes the blind leading the blind, because very few of these changes that we might otherwise want to emulate are actually any better, just different. It's just change for change's sake, and users hate that.

True beauty requires confidence, but trying to keep up with the latest fashions signals precisely the opposite.

+1, you should put that up on some virtual wall ;)

Just adding a note to the suggestion by Fuchs: we used to have this in the KDE 4 times, it was highly confusing, users didn't understand that the button acts on the current theme. Due to that in the rework we changed and added the config button to the decoration list. IIRC it initially was outside the preview area but was moved in later on.

Perhaps an outside-the-preview button's text could say "Configure active theme"?

Perhaps an outside-the-preview button's text could say "Configure active theme"?

And what does it mean? The currently selected or the currently active theme? That was exactly one of the problems we faced with the button not grouped with the previews.

richardbowen added a comment.EditedMar 18 2018, 12:46 PM

How about adding a"Configure Theme" or "Configure..." button within the "Theme" tab at the bottom left, adjacent to the "Border size" dropdown? (Around where the cursor is in the image).

I wanted to summarize our thoughts visually so far. I added a 4th idea of mine at the end of this image.\

What's box header in your mockup?

What's box header in your mockup?

Just the theme title. This is only the theme window. It is intended to represent the list of themes.

How about adding a"Configure Theme" or "Configure..." button within the theme tab at the bottom left, adjacent to the "Border size" dropdown? (Around where the cursor is in the image).

How about "Configure X" button at the very bottom where "X" is the currently active theme? If someone selects a new theme but does not apply it, when the configure button is clicked you can prompt "Continue, Apply and continue, Cancel" and if it matches well it does not prompt at all. That about covers all the cases.

What's box header in your mockup?

Just the theme title. This is only the theme window. It is intended to represent the list of themes.

I see, so a small visual change. In your mockup I would prefer the last variant.

I wanted to summarize our thoughts visually so far. I added a 4th idea of mine at the end of this image.\

Great, thank you.

Personally I prefer the second one, because every one where the button is part of the preview might confuse the users, as they might not see it as usable control, but rather part of the preview.

zzag added a subscriber: zzag.EditedMar 20 2018, 11:52 PM

+1 for putting configure button at the center of each window(the first row in the wireframe)

Personally I prefer the second one, because every one where the button is part of the preview might confuse the users, as they might not see it as usable control, but rather part of the preview.

In KDE 4, I discovered decoration settings button after using Plasma for about half a year. Even though most of that time I was afraid to change settings because it could crash my system, I saw decoration settings "tab" quite often (I still was discovering plasma. ;-)
As you see, the second one has some problems with visibility too.

... And I doubt that we can get 100% visibility and recognisability at all.

and the gear won't change situation too much because it's practically the same as icon in the bottom left corner.

... and buttons in the titlebar(CSD) are not so common in Plasma.

ngraham updated this revision to Diff 30175.Mar 22 2018, 2:11 AM

Center the button within the preview and give it text to match the theme it will affect

All right folks, how about this?

ngraham edited the test plan for this revision. (Show Details)Mar 22 2018, 2:12 AM

If folks don't like it, I can work on putting the button outside the content area, but that's going to be a lot more work to figure out on my own, so there may be an extended delay.

zzag added a comment.EditedMar 22 2018, 2:24 AM

All right folks, how about this?

+1 for this

All right folks, how about this?

I'd still prefer it outside of the preview, but if either not feasible or not with reasonable effort, I like the idea.

Button content: not sure how / if that would break on long theme names, mind. (breeze-dark-transparent or whatnot) and if thus a generic "configure (this) theme" would make more sense.

Center the button within the preview and give it text to match the theme it will affect

It's a good compromise, I like it.

Nevertheless, I imagine some users might now have problems switching between options, because they might not realize they have to click besides the button to do so. They'll click just in the middle, a dialog opens and they accept, however nothing was changed yet at this point.

Would it make sense to also switch the selection as soon as the Configure button is clicked?

+1, ...and just for extra relevance, can the centered buttons have a shadow? A shadow on hover or something that brings attention to them and make them stand out?

Nevertheless, I imagine some users might now have problems switching between options, because they might not realize they have to click besides the button to do so. They'll click just in the middle, a dialog opens and they accept, however nothing was changed yet at this point.

Would it make sense to also switch the selection as soon as the Configure button is clicked?

Excellent point, I'll do that.

Long theme names may make buttons quite large. How would this work for a theme name like "Phabricator", or a two word theme name "Hydrogen Next"?

Long theme names may make buttons quite large. How would this work for a theme name like "Phabricator", or a two word theme name "Hydrogen Next"?

The theme's name is already in the preview's window title. That's a generic problem of this selection dialog (another being that for small window sizes this is quite fiddly to use), so nothing for this patch to solve IMO.

Long theme names may make buttons quite large. How would this work for a theme name like "Phabricator", or a two word theme name "Hydrogen Next"?

The theme's name is already in the preview's window title. That's a generic problem of this selection dialog (another being that for small window sizes this is quite fiddly to use), so nothing for this patch to solve IMO.

The patch title is valid as the current icon for configuring the setting looks like a decoration and is not so clear. I like this approach:

How about adding a"Configure Theme" or "Configure..." button within the "Theme" tab at the bottom left, adjacent to the "Border size" dropdown? (Around where the cursor is in the image).

What do you think @rkflx?

I like this approach:

How about adding a"Configure Theme" or "Configure..." button within the "Theme" tab at the bottom left, adjacent to the "Border size" dropdown? (Around where the cursor is in the image).

What do you think @rkflx?

I don't mind that approach myself, but it suffers from the issue that Martin brought up, and it's also something I don't know how to do without a lot more digging. ...Which is possible of course, but energy and motivation wanes the longer the discussion goes on without convergence towards a solid plan.

rkflx added a comment.Mar 22 2018, 9:42 PM

How about adding a"Configure Theme" or "Configure..." button within the "Theme" tab at the bottom left, adjacent to the "Border size" dropdown? (Around where the cursor is in the image).

What do you think @rkflx?

I already stated in D11201#224492 that I'd prefer external buttons. However, I know very well that having a good solution is better than not having the perfect solution. Therefore in D11201#231440 I was okay with the current proposal.

As for the width of the button: Please provide the name of the theme with the longest title to date. Then Nate can try it out, and we either go with the title on the button or we leave it out. No need to over-engineer this.

ngraham updated this revision to Diff 30260.Mar 22 2018, 10:30 PM

Select the theme corresponding to the clicked button, to prevent user confusion

ngraham edited the summary of this revision. (Show Details)Mar 22 2018, 10:45 PM
ngraham edited the test plan for this revision. (Show Details)

Thanks Nate. Tested this, works great for me (but did not look at the code). Long names are just elided (both in the title and on the button), which is fine in my book.


OT here, but perhaps for a follow-up patch: After opening the KCM, the current theme should be selected and scrolled to. Currently (at least for me) nothing is selected at all, and only when I resize the window so the layout switches to two rows the current theme gets suddenly selected…

@graesslin, any comments? This is ready for review. UI-wise, folks seem okay with this.

graesslin added inline comments.Mar 23 2018, 5:21 AM
kcmkwin/kwindecoration/qml/Previews.qml
120

Why a rectangle? Just use an Item

ngraham updated this revision to Diff 30309.Mar 23 2018, 1:23 PM

Use an Item instead of a Rectangle

ngraham marked an inline comment as done.Mar 24 2018, 8:10 PM

Friendly ping!

graesslin accepted this revision.Mar 28 2018, 5:21 PM
This revision is now accepted and ready to land.Mar 28 2018, 5:21 PM
This revision was automatically updated to reflect the committed changes.
urohan added a subscriber: urohan.Jun 15 2018, 6:54 PM

I think adding a theme name to a configuration button text is a bad idea (it looks not very good when theme has a long name). Sorry maybe it is not a properly place to comment or make a suggestion (I am still not very familiar with Phabricator).