…we simply don’t get many designers showing up. I think a source for this is the persistent–and successful–urging in the art & design communities of “don’t work for free!”
Yea, I’m sure this is a part of it. The fact is that programming is not devalued in the way that design is, so the nickel-and-diming, “competitions” and spec-work that is endemic to creative industries, almost to a systematic degree, just never occurred with programming work at even close to the same level. Plus, designers that use GNU/Linux are like hen’s teeth; most have no idea that professional design work is even possible on a FLOSS stack.
…in general the designers we get in KDE tend not to be experienced professionals… it becomes easy for the devs to ignore them.
This is fair. Even professional designers often don’t help the perception of the industry — I feel like what many designers really want to do is make art for a living, which is not what design is, so they don’t prioritize usability like they should.
Ultimately I think we probably need to hire a professional designer if we want to level up our design capabilities.
I agree; even if just to develop some guidelines / design tokens. That said, there’s no harm in asking individuals for contributions like that first.
Unfortunately, a number of them went deep into the core of how KDE designs apps. For example he pointed out that in Kirigami apps, toolbar content is context-sensitive, but the unified “tools area” visual styling of the toolbar makes it look like the buttons are grouped with the titlebar–which is global in scope–rather than the page beneath it. As a result the context-sensitivity is contradicted by the visual cues in the UI.
Yea, the fact that designers should be brought in to help decide how these things are structured rather than brought in to style them afterwards is a tough nut to crack in FLOSS when things often begin as solo-dev projects.
On that particular case: I wonder why people feel that it looks better? One bugbear of mine with many KDE applications is the over-reliance on rules / lines to indicate grouping and hierarchy. I remember reading yonks ago that it’s best to use as few indicators as you can get away with, because extraneous indicators don’t actually help and just increase cognitive load. I wonder if it had something to do with that, or maybe there was inadequate whitespace or something?
This was obviously correct, but hearing it felt very depressing to me because I led the effort to unify the titlebar and toolbar contents visually. The obvious conclusion was “well, that was wrong, revert it” and I felt bad.
This stuff is hard to hear for sure, but god knows everyone makes mistakes, and the fact is that designing software is very very difficult. I’m an old-school designer; I started designing for print at a print brokerage years ago. I still mostly do print; the same basic principles apply to print and design for digital interfaces, but lord, the digital stuff has so much more to consider for all kinds of reasons. But besides that, KDE software is more usable than ever, and honestly, the fact that you’re able to accept input and change your view on something is a tremendously valuable skill, so I wouldn’t feel too bad!
).
- some things should be known already, especially by old-timers - 
)
)