I am a bit confused by this "Human-Centered KDE" goal.

On the one hand it presents itself as trying to put more value on "human-centred design". Human-centered design is about community involvement in all stages of the process among other things. This is already a core pillar of the KDE community and front and centre in KDE's code of conduct. I would have assumed this goal was about guiding users to self-organise and contribute to design effectively.

On the other hand the goal constitutes that "the vast majority of people, including in KDE, don't really understand what usability is, what it does and doesn't impact, how to apply best practices to keep interfaces usable, the basics and importance of what usability research does for an interface, and other things.". This kind of sentence is the antithesis to human-centred design because it excludes people that are not "in the know" of being able to participate. It is however a popular stance among some schools of thought in design.

It is then explained that facilitating usability research is at the core of what this goal is trying to accomplish which also sounds to me like this is not about human-centred design and more about "experts" conducting studies and evaluating what usability changes should be implemented.

"One of the biggest potential challenges is simply: old habits die hard. People will need to get used to thinking about the end user and usability in more tangible ways" is implying that we haven't been trying to do this for many years even though the "Usability & Productivity" goal is being worked on since 2017.

Can you clarify how you plan to put usability research at the core of human-centred design and how this is different from what we have been doing?

I am kind of worried that this kind of focus on research will impede us when doing human-centred design in its original sense because empirical data tends to be understood as an objective source of truth while some people fail to realise the human aspect of it (like making mistakes in validity, reliability, objectivity, etc. in testing; many scientists being unable to identify wrong results from data; or applying results in wrong contexts).

On the one hand it presents itself as trying to put more value on "human-centred design". Human-centered design is about community involvement in all stages of the process among other things. This is already a core pillar of the KDE community and front and centre in KDE's code of conduct. I would have assumed this goal was about guiding users to self-organise and contribute to design effectively.

This seems to be confusion stemming from another meaning to "human centred design" that I wasn't aware of, and either way, debating about exactly what a title I thought of to be kinda catchy and Close Enough:tm: means will be kinda pointless, so yeah i'm going to not.

On the other hand the goal constitutes that "the vast majority of people, including in KDE, don't really understand what usability is, what it does and doesn't impact, how to apply best practices to keep interfaces usable, the basics and importance of what usability research does for an interface, and other things.". This kind of sentence is the antithesis to human-centred design because it excludes people that are not "in the know" of being able to participate. It is however a popular stance among some schools of thought in design

I don't really get how "there is a knowledge gap that I would like to see filled" is exclusionary in any way, other than that some people have more and others have less. The intended purpose is to help promote more knowledge of a "subject that seems close enough to common sense that most people don't really dive into the details but actually there's much to be learned" subject to everyone so that everyone can be better informed about this sort of stuff, not just designated experts.

It is then explained that facilitating usability research is at the core of what this goal is trying to accomplish which also sounds to me like this is not about human-centred design and more about "experts" conducting studies and evaluating what usability changes should be implemented.

If the most of the post being about promoting tools that make it easier for people that aren't part of a professional firm that can pay for expensive products to do user research (a fancy word for "seeing how it actually works on real people instead of assuming how it might work") and me explicitly saying that I don't see professional help being a component of this goal doesn't get the point that this is not about a designated group of Experts:tm: across, then honestly, I'm not sure what will. I may be having a bit of an overestimation moment though, so I will try and revise to better compensate for my nerdery on the topic.

Can you clarify how you plan to put usability research at the core of human-centred design and how this is different from what we have been doing?

yes

I am kind of worried that this kind of focus on research will impede us when doing human-centred design in its original sense because empirical data tends to be understood as an objective source of truth while some people fail to realise the human aspect of it (like making mistakes in validity, reliability, objectivity, etc. in testing; many scientists being unable to identify wrong results from data; or applying results in wrong contexts).

"Research" in a usability context is a different thing from "research" in an academic context. The primary thing is "see how actual humans react" rather than being super indirect academic-style for sake of producing The Perfect Data.

I'm not a fan of Steve Jobs but he had the right idea here I think:

“Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.”

The good thing about an OSS projec is that its developers are also some of its most dedicated users. So developers should feel doubly comfortable stipulating what *they themselves want to use*, then asking the wider community for additional input. Gnome took took this to an extreme, I think to the point where even they even violated this principle (because how could anyone, even the developers, get by using mostly Gnome software?). But there should be some median between their way and KDE's "no user left behind" approach.

For clarity it should be mentioned here that the champion of this goal has left the community, so unless someone else picks it up, this goal is not actionable.

I feel I should pitch in a little bit on this, because I have had some very frustrating moments with some KDE software that's been changed recently to be 'more user friendly'. I know this isn't exactly what the proposal is about, but I've seen the sorts of people who do promote this type of thing also making the same sorts of decisions in other software.

Sometimes, software is complicated because what it does is complicated. There's only so much you can do to simplify the workflow before further simplification backfires. Yes, it might look simpler and easier to digest to someone who sees it for the first time — which, incidentally, tends to be the focus of research that watches how people use software and measures usability — but becomes a hindrance to usability in the long run when a user has seen it many times already and just wants to be able to use it quickly and efficiently.

This goes beyond 'too many features, hide advanced ones behind an advanced panel'. For example, the new settings page for configuring KWin rules is much simpler and more consistent in design, and for adding one rule to a single program every so often will become significantly easier for people who are new to KDE. However, it is atrociously slow to add multiple rules to a single program window, because the subwindow for selecting a property to change completely closes after setting every single one. I've seen some people who even assume you can only set one per window type, which isn't true.

The new design has every feature the old design had, but it's significantly slower and more tedious to use than the old version. For anyone who makes frequent use of those settings, it's an absolute nightmare. The old design might have been uglier, more cluttered, and initially more confusing for new users... But it let you do a bunch of stuff all at once before closing, was still fairly consistent, and after a short while it was comfortable to work with.

The old design would not pass usability tests when sitting new users down in front of it, and the new design might... But usability tests like that are far from indicative of how software is actually used by people who frequently use it.

In T15613#279100, @tfella wrote:

For clarity it should be mentioned here that the champion of this goal has left the community, so unless someone else picks it up, this goal is not actionable.

Indeed. Someone else will need to step up to be the champion of this goal before we can move it to the "Ready for voting" column.

because the subwindow for selecting a property to change completely closes after setting every single one

Thankfully that's like a one-line change. :) Feel free to propose it in the form of a merge request or a bug report.

In T15613#279133, @ngraham wrote:

because the subwindow for selecting a property to change completely closes after setting every single one

Thankfully that's like a one-line change. :) Feel free to propose it in the form of a merge request or a bug report.

The subwindow in question acts as a drop-down list menu of properties. You click the property you want, the window disappears, and then you set the specifics for that property you just added.

The drop-down menu is implemented as a sub-window instead that covers everything else up so you only have a rough idea of what you've already done, the act of choosing which property to add was turned into a major step with its own dedicated subwindow (which cannot be moved because it's not really a window per se, just a UI element that covers almost everything up and darkens everything it doesn't), and that's not even the main thing I'm complaining about.

What I'm complaining about is the entire design of the new workflow, not a specific design choice with regards to one aspect of it. The entire fundamental idea behind how one uses the new UI is flawed. It was 'ugly' before having all of the properties visible and choosing which ones to apply by clicking a checkbox and changing values from several drop-down menus... But lets compare the workflows themselves:

• Old way:
  1. Insert matching data (unless right-clicking a title bar and choosing 'Configure Special Application/Window Settings...'). This is all on one tab of the dialog box.
  2. Go to next tab.
  3. Click all the checkboxes for settings you want to control.
  4. Change all the drop-down parameters how you want, as well as any other settings for the relevant items.
  5. If any items weren't in that tab, go to the next tab and repeat steps 3 and 4.
• New way:
  1. Fill in basic matching data. If you need to match by role, title, or hostname, that's now part of step 2.
  2. Add a property to change.
     1. Click 'Add Property...' to bring up the subwindow.
     2. Scroll through the list to the property you want, and click on a property to change, closing the subwindow.
     3. Change its drop-down property, as well as any other controls available to it.
  3. Repeat all of step 2 for every property.

Going by the numbers, that looks like '3 easy steps' until you realize one of those steps has 3 more steps in it, bringing the total to 5. So, on paper, the two seem just as easy, as both require the same number of steps.

However, consider how easy and quick it is to group a bunch of similar actions together. Clicking a bunch of checkboxes all at once? Easy! Don't even need to separate them out as individual steps. Changing a bunch of drop-downs? Just need to hover the mouse over them and use the scroll wheel of your mouse (which, by the way, doesn't work that great in the redesign because it constantly has 'tooltip-like' bits of advice pop up at the top of the screen almost every time you change one of the drop-down values.. Which scrolls them all and makes your next scroll click change the wrong drop-down).

You could say that one can mostly replicate that older workflow in the new one by just adding all the properties first. But even that takes longer than it should, since there's a lot more mouse dragging between the list of properties that opens in that fake subwindow, and the 'Add Property...' button.. Not to mention the need to search through the list for each item. While the list is organized, with related items placed near each other and even grouped within the subwindow's list, the position you scroll to is not preserved between entrances into the subwindow, which makes it an entirely moot point.

In short, there is no way to optimize one's interactions with the new UI. It is inherently, by design, slow and painful to use. Nothing can fix it except to completely replace it, because it is built upon a flawed view of how people interact with it.

Edit: I suppose if the subwindow stayed up until manually closed, one could just add a bunch of items, and then change the properties.. But why have a subwindow list at that point? Why not choose properties in a similar way you choose window types, with a normal drop-down menu that has checkbox items?

At that point, that's a significant enough change (especially since there'd need to be many other changes in addition to that, such as moving role/title/hostname matching back up with the rest of the window matching features, removing the 'Add Property...' button, etc.) that it might as well be considered another redesign.

In T15613#279133, @ngraham wrote:

because the subwindow for selecting a property to change completely closes after setting every single one

Thankfully that's like a one-line change. :) Feel free to propose it in the form of a merge request or a bug report.

Answering by reference here, although I highly doubt this is the right place for discussing this issue :P:

There is the long standing https://invent.kde.org/plasma/kwin/-/merge_requests/1954, which I had mostly forgotten since we couldn't agree on a suitable icon :)

Notes from the refinement session:

As Janet seems to be no longer with the community, the Goal will not move to the next phase of the process. If any other person would like to step in, the possibility can be discussed.

I think this is a very valid goal, and I think it totally deserves to be voted. I'm willing to focus on this if it gets selected, so I'll step in to make sure it gets its chance. If Janet wants to come back to the community and lead this goal in the future I'll be happy to shift this to her anytime.