> submitting design and usability improvements to open source projects
What format does this take. My experience is that more often than not, design and usability improvements are abstract (mockups) and requires implementation by someone else. If the improvement is a working update to a QML file that improves the interface, I'd say chances are that it would be received well.
UI design as a discipline fundamentally assumes the person designing the interface doesn't intuitively understand what's better or what's worse— they should investigate, check, and confirm their strategies. Someone posting wireframes is almost certainly looking for feedback to test/refine their approach before they start coding because fixing is a whole lot more work in code than on a wireframe even if they can code. If they can't code and nobody feels compelled to implement it, then that's that— just like any other feature on an open source project.
As an aside, I get flack from other developers when I say designers and their contributions are usually considered less valuable. When I don't, "surely we couldn't suggest existing contributor's spend time on such tasks" is one of the first responses.
Thoughtfully facilitating task completion for humans vs exposing software functions in a UI is like designing good, scalable, maintainable software vs. making functions valid in a programming language that generally work together to accomplish a task. Consider an architecturally unsound project coded by folks with the most rudimentary development skills. Would you try fixing it in bite-sized PRs vetted by the people who made it— none of whom see a problem with the way it is? Even starting such an undertaking would be pointless.
Similarly, the chance of any significant usability improvement being miscible in the standard flow of bite-sized PRs isn't great. If a project is on year 7 of using their undesigned UI, most logical steps between A and Z, even if the code is functional, have broken interfaces. What are the chances of a project going with the flow, there? You'd need to love that software more than your spouse to take that on.
Beyond that, good usability is fundamentally informed by user needs, not architecture, library features, the existence of other elements, or developer preference. Also, UI changes are often fussy, require a ton of testing, and result in a ton of work that doesn't show up in the final code. That's true for all code to some extent, but developer reviewers see it more easily in a clever little algorithm than organizing elements in an input box. That makes them less likely to get the weight they deserve when encountering conflicts, even if the conflict is an uninformed opinion that nobody else around is informed enough to counter. I can't imagine any developer submitting code to a repo where the tables were turned.
> Sorry if this sounds defensive, but
>> bikeshedded into oblivion by people emotionally attached to a bad ui
> doesn't sound fair to me.
Not really sure how to respond to that. People are worse at taking critique for skills they aren't confident in. Ever give a brand new developer a code review? Yeah. That’s about what it’s like critiquing an open source project’s beloved “quirky” interface.
Even users become attached to bad interfaces because they put in the effort to learn how to use it and assume everybody else matches their use case. It's like bad UI Stockholm syndrome. I cite any discussion where people express frustration with the interfaces for git or Gimp. Even implying they aren't on par with the usability of commercial offerings, let alone insufficient for their basic tasks, will get you flamed.
I've seen this hostility many places, but I can think of one moderately popular app in particular that many non-developers come across. It's function requires fast, smooth input, and to facilitate that, has native clients on most platforms (including mobile) and is modestly funded by their very affordable, optional cloud storage service. In their discord board and issues, even contributors complain about clunkiness, counter-intuitive flows and inconsistencies between clients. Responses range from "eh, it's in the docs" to "it's idiomatic in that OS and totally unavoidable," to "yeah, we should really figure that out. It's on the usability project board." Actual usability discussions are rudderless, shoulder-shruggy, and fizzle out with things like conversations about which font people find most readable. I thought it would be a great place to contribute my expertise. I did one more search searching the forum for 'wireframe,' and every. single. thread. started by a designer posting nicely documented proposals w/user flow diagrams or mockups specifically asking to __kick off a conversation__ about how a more thoughtful UI might look was unceremoniously buried with comments like "what do you expect anyone here to do with this information?" and "the X to close that window is unnecessarily large according to X guidelines and XYZ elements are too close together, etc." and "please don't ruin my app by making it pretty."
If they were non-technical people talking about a technical proof of concept you posted, would you take the time to break it down into tiny bite-sized PRs and submit them? If most projects you wanted to contribute to acted like that, how soon would you stop trying? It's just not worth the hassle until design knowledge and labor are more valued, fundamentally.