A lot of times, like in this case, I wouldn't even consider the product because of its bad UI/UX, even if the underlying technical implementation might be slightly better than the closed source alternative.
A lot of times, like in this case, I wouldn't even consider the product because of its bad UI/UX, even if the underlying technical implementation might be slightly better than the closed source alternative.
* Improvements to open-source projects come primarily from developers scratching a personal itch.
* User interfaces are first and foremost a way for the application to communicate to the user what is possible and how to achieve it.
* If there's a problem with a user interface, it therefore most adversely impacts a user who does not yet know what is possible or how to achieve it.
* To fix a problem with the user interface, you must learn enough about the application such that you now know what is possible and how to achieve it. Hence the problem no longer affects you as much and is no longer a personal itch. So the problem doesn't get fixed.
I'd add to it that developers are the ones birthing these projects, and they (or we, I should say) don't like to be bottle necked by UX.
My comment is intended more as a step-by-step argument rather than a list.
* There is usually no clear way for a UX designer to contribute. Note with this example, under 'Contributing - Tasks I could work on' it doesn't mention UX, and the only way to become a committer is to "show us some of your patches, or solve some issues" - none of which involve UX.
* There is a slight obsession in the open source community to use only using open source tools, while the majority of modern UX practice is developed on proprietary tools (e.g. Figma).
* Design by committee is the most frustrating and slow process, and great UX design comes from strong decisions by great designers rather than community votes.
* There is an underlying assumption that if you contribute UX designs and put them in the Wiki they will be ignored, so there is no point. It's not the same as code where there is a one step process (i.e. commit), the whole team needs to embrace the UX and then work to commit it to code.
While true in some aspects, it's not true in others. Most of todays "modern" open source ecosystem live within GitHub which is not open source, using services for development and infrastructure that is also not open source. While many developers local tools tend to be open source, the rest of the infrastructure we use tend to not be open source. Even many of the biggest package registries for open source are not open source themselves.
I'm not saying 100% of the open source community leverages these services, but a lot sure do.
I agree with your top most point the most though, there is no clear path for designers to actually contribute. And if there is, it's a pipeline of "come up with requires -> design -> code", whereas contributors are not as excited about the last point if someone else did the steps before. Hence we see more code contributions than design ones.
Open standards might have been a better term. The example in this project would be the use of "Pencil Project" for UX design rather than Figma / Sketch / Adobe XD (which to some extent may be for licencing and cost reasons too).
Figma, because of the cost (or lack off) and availability, seems to be the only tool realistically available for doing open source design today. Unfortunately neither the format nor the editor is open source itself, but sometimes the means justify the end I guess.
I doubt the click-through presentation stuff can be exported in any way, but basic design work could be persisted and collaborated on by multiple people with different tools if that approach was used.
Currently for my open source project, we all just work directly in Figma then export the design to a website via the tool we're building. Works fine for now, but not doing anything too complex. Project is https://github.com/instantwebsite in case you're curious.
This affects not only UX. I'm sure I'm not the only one who has spare infrastructure and ops skills that I'd love to contribute to open-source projects - hosting CI/CD, repo mirrors, staging environment, website, chat server, SMTP gateway, for example. It'd be nice to play a small part in decentralization, for one thing.
I'm sure I'm far from the only one. I'm also sure there are open source projects who would benefit from it.
There's no process for us to match and it seems just culturally abnormal. I'd love to hear ideas.
Whats needed is first and foremost UX people, not graphic designers drawing a pretty UI. That is the final touch. But making good UX is hard, and need a good understanding about how the software is used, and what's technically feasible. All this takes much involvement and speaking to multiple people and back-and-forths over time.
My day-to-day involves a UX person discussing a feature with me, and us arriving at some rough sketches for how it should be. I will often start implement, and find an edge-case not considered or something, which will trigger a new discussion. My point is that UX isn't something someone can do in a vacuum on their own, or as a complete rewamp. It needs to be continuous in the process for every user-facing feature, and thus involve everyone.
Attracting UX people to that kind of long commitment is the hard part. While for a developer I often feel it's them just making a feature to scratch their own itch, with no consideration for the whole.
With most projects already stretched pretty thinly on engineering resources that's the natural outcome even if it would be better to have less features, but easier to use for a beginner or regular person before building out the whole thing.
How would UI/UX contribute? Would you want them to do a pull request with wireframe mockups?
With UX, however, the contribution itself isn't the proof that the contributor actually knows what they're doing. I've been excited about getting a UX contributor in the past, but then with all due respect what they turned up with was even worse than what I could've done - and this was not just a matter of taste and expertise. But it's rough to turn it down after the work's been done.
If the work suddenly turned up with zero iterations and input, this is UX work being done wrongly.
See also the open source design site, some of the jobs there are even paid:
- Adding good UX to an existing project is a huge undertaking. To do a good job you probably want to touch just about every piece of the UI. This can be a hard sell as a new project member.
- Many designers don't have the skills to implement their design. This means that the best they can do is basically propose that other contributors do a lot of work. It is a lot easier to just merge a PR that works then implement a design.
- The maintainers of projects are probably more familiar with accepting code patches. They know how to evaluate code but don't have a strong ability to review UX proposals.
I have a bunch of small tools that I maintain and that occasionally get code contributions. But I know that they have terrible UX. I would be thrilled to get some support in that area, however if someone without frontend experience just proposed the end result. I don't know if I would have enough motivation to implement it myself. Of course I suspect that a skilled UX Designer with frontend development experience would be a very welcome contributor to many projects.
Well, presumably they'd want to be paid.