Email or username:

Password:

Forgot your password?
Top-level
Graham Spookyland🎃/Polynomial

@baldur there are examples of projects that have made a concerted effort to solve these problems (KiCAD comes to mind, running user surveys and then acting on them rapidly) but they are a minority.

my personal view is that this is an endemic cultural issue that has plagued FOSS for decades, but I don't have the energy to get into this because it inevitably leads to tedious reactionary defensive responses.

10 comments
Sven Slootweg

@gsuberland @baldur Don't know that it's worth much, but if it helps: I agree on all of this, and it has been frustrating me for over a decade.

(And I've experienced the same active resistance to changing that culture, too...)

Graham Spookyland🎃/Polynomial

@joepie91 @baldur the core problem, as I see it, is a culture of code being lauded as the be all and end all. writing code is directly equated with creating software. if you're good at writing code, you're smart, you're useful. if pushed to explain what else is involved, folks will mention documentation and maybe community management. if design is mentioned, it's exclusively about architecture, not about experience and usability. as a result, well-designed user experiences are vanishingly rare.

Graham Spookyland🎃/Polynomial

@joepie91 @baldur this also led to the long-standing cultural problems around generally awful people being tolerated, accepted, and even glorified, but that subject has been talked to death.

TSRBerry

@gsuberland @joepie91 @baldur could I ask you what I as a contributor/developer for OSS projects can do to improve things (even if that change might only affect a tiny amount of people)?

Graham Spookyland🎃/Polynomial

@tsrberry @joepie91 @baldur the answer to that heavily depends on what kind of project it is, who the users are, and what scale it operates at. if it's a small CLI tool developed by one or two people and used by a handful of linux sysadmins you probably aren't running into many UX design pitfalls. having really good docs is nice, having error messages provide context and guidance helps, being welcoming towards contributors and not needling them with endless style changes is very helpful.

Graham Spookyland🎃/Polynomial

@tsrberry @joepie91 @baldur if you're operating at a larger scale (especially on gui tools) then running annual community feedback campaigns is a huge winner. make it a simple survey form - minimum friction, maximum response rate. people will tell you all the things that have been bugging them but never got around to opening an issue for. commonalities in responses will help you direct your efforts and make a lot of users happy with relatively low effort.

Graham Spookyland🎃/Polynomial

@tsrberry @joepie91 @baldur but ultimately at that scale you need input from actual designers - people who really know how to make a good UI/UX, and who can tell you what you can do better. that can be direct, by getting designers to come help with the project and help come up with better approaches and workflows, or it can be indirect feedback. and be humble. don't get defensive because you're attached to the project or it'll be work to fix the issues. it's hard work to do it right!

Sven Slootweg

@gsuberland @tsrberry @baldur One thing I'd want to add to that is that if it's not feasible to find experienced designers (funding reasons, community politics, whatever reason), it *is* possible to just learn how to do this stuff yourself on-the-fly as a maintainer, but it makes the "be humble" part all the more important, and to make that work, you *need* to have an attitude of "if a user complains about something, that means there's a bug, even if it's not where the user thinks it is" (eg. it might sometimes be a documentation issue instead of a UX issue, but as long as people complain, there's *a* bug somewhere).

@gsuberland @tsrberry @baldur One thing I'd want to add to that is that if it's not feasible to find experienced designers (funding reasons, community politics, whatever reason), it *is* possible to just learn how to do this stuff yourself on-the-fly as a maintainer, but it makes the "be humble" part all the more important, and to make that work, you *need* to have an attitude of "if a user complains about something, that means there's a bug, even if it's not where the user thinks it is" (eg. it...

Sven Slootweg replied to Sven

@gsuberland @tsrberry @baldur Also, related to the 'user surveys' point - it's surprisingly helpful to just enter your project name into a search engine every once in a while, and read every blog post, Reddit thread, and rant you come across. Those tend to be *full* of things that never made it into 'properly filed' issues, and give a good impression of the general atmosphere around your project, because people tend to speak more freely and directly.

Of course that does mean that you should refrain from responding to them unless you are absolutely 100% certain that you can do so non-confrontationally, because seeking out confrontation with people talking in their own spaces is (deservedly) a very quick trip to the trash pile. Better to just take notes and work on fixing their complaints in the background.

(Bonus points: you can do this one as an 'unaffiliated' contributor with no formal power within the project. Whereas a proper user survey, although it can have better coverage, tends to require speaking formally for the project.)

@gsuberland @tsrberry @baldur Also, related to the 'user surveys' point - it's surprisingly helpful to just enter your project name into a search engine every once in a while, and read every blog post, Reddit thread, and rant you come across. Those tend to be *full* of things that never made it into 'properly filed' issues, and give a good impression of the general atmosphere around your project, because people tend to speak more freely and directly.

TSRBerry replied to Sven

@joepie91 @gsuberland @baldur Thank you both, this helped a lot! :D
I'll note these down and try to do my part!

Go Up