What is it about open source that it can't attract UI/UX designers to try and contribute? Are most open source projects just unwelcoming to that kind of help? Missing tools/platforms for it, or something else?
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.
My longstanding explanation for this has been as follows:
* 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 agree with the above, and also would add the following:
* 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.
> * 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.
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.
> slight obsession in the open source community to use only using open source tools
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.
> While true in some aspects, it's not true in others.
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).
Funny enough, Pencil Project in itself is a testament to how badly open source software needs better/more designers who know good UX/UI. Try putting a modern designers coming from Figma/Sketch in front of Pencil Project and watch them puke colorless rainbows while trying to figure out how to do the most basic of operations.
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.
Figma is able to import and export svg files pretty well (for my purposes) - I wonder if that's sufficient for a good number of workflows/projects?
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.
Yeah, SVG import/export for smaller elements works fine but once you get into larger files, design systems or designing entire applications in Figma, import/export of SVGs becomes untenable. Otherwise you just have the .fig file format, which is also proprietary as well.
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.
On design forums I've often seen people using their spare time to create an alternative design for various services / programs. They often look very sleek, and people will comment "wow, they should make it like this" or "I would use program X if it looked like this". The problem is that these mockups are often useless. They are just drive-by. No substance, no thought of a user-journey or how to accomplish tasks. Mostly all functionality has been hidden and some pretty colors added. (And these mockups never reach the projects anyway, just shared with other designers)
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.
My guess is always that if a designer comes along and suggests a new interface or creates design components that can be used that maybe need some engineering resources the priority will always be on "let's make it work first and support all these edge cases we programmers like to think about".
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.
To whomever downvoted this: I'd assume that you misunderstood this comment. How I understood this comment is that there's no easy or defined way to contribute UI/UX improvements. For code improvements it's pretty clear, but the whole issue/PR workflow can't be applied 1:1 to the UI/UX process works from what I've seen. So I'd definitely agree with that sentiment.
An additional challenge is that, if I get a PR of which I don't like the specific way it's been done, I can patch it up myself. And if it's a feature I don't want added at all, I can already turn it down at the proposal stage, before any code is written.
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.
Sure, but just delivering the first iteration is already a significant step up from just reporting an issue describing your proposed approach, which is how it would work for writing software.
Actually I'm a UX Designer and tried to contribute to open source projects, but it seems that it's always about graphic degin. Anyway, I'd be glad to contribute to some projects that need UX, if you know some, let me know!
I split my time between front end development and UI/UX design. I believe this is because achieving a good UI/UX requires a holistic knowledge of the entire software suite, and detailed information about who is using the product and for what. This kind of thing takes a ton of research, and it's the kind of thing that only a BDFL working side-by-side with a talented UI/UX designer can achieve. Basically, it takes a small group of people with a vision, who know the product and the user very well, and can afford to spend dozens or hundreds of hours on it. This is not something that most open source projects have, unfortunately.
I can think of a couple of issues that may add some friction:
- 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.
I don't think that's the full reason, there's a lot of designers on Twitter / Dribble / Producthunt that build side projects or share free resources just like programmers.
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.