4 ms·

Become an open source contributor. OSS has some of the worst UX in the world. Look at Inkscape. Look at the GIMP - probably the only piece of software in exist

Become an open source contributor. OSS has some of the worst UX in the world. Look at Inkscape. Look at the GIMP - probably the only piece of software in existence where the name is bad UX in itself. But because it’s open source, you can fix it. You won’t be able to fix all the bad UX in the world. But you could make a massive difference by applying yourself to just one project like this.

throwaway894028 7y ago
That would feel like a drop in the ocean. It's not going to change the frequency of my encounters with bad UX, and it's not going to change how I feel whenever such an encounter occurs.
sdtsui 7y ago
Yeah! It's nice to be able to see the opportunity in bad UX.
open-source-ux 7y ago
"But because it’s open source, you can fix it." You can't fix it really because everyone (understandably) wants a say in the visual and interaction design of the software, but you can't design by committee. Having many participants contributing to source code can work well, but I don't think this model works well for design. It sounds really undemocratic (why shouldn't everyone have their say?). And it undoubtedly contributes to the stereotype of the designer as diva or precious about their work. But can you think of an open source project praised for it's visual and interaction design that was collaboratively developed with dozens or more participants? If you can, it will be an exception, not the rule. When there are too many participants in the design of a program, you end up with a project pulled in every direction and pleasing to no-one. But if you go the opposite route and limit design decisions to a dedicated UX team, you end up generating resentment from contributors or users who feel their input is being ignored.
afarrell 7y ago
One problem with a lot of projects is that they have a poor developer experience for new contributors. For those who are already working on the project, these developer experience problems aren't impactful. So, by selection bias, the project leadership doesn't see them as a priority. The people who do have the necessary perspective to see the impact of the problems are those whom they impede. These programmers don't yet have the project-knowledge to efficiently design a fix nor the relationships with the existing maintainers to persuade them that the fix is worth it. These people could produce a description of the nature of the problem. That takes effort and all it would be is... Whining: Descriptions of problems by those who aren't taking steps to fix them.

throwaway894028 7y ago

That would feel like a drop in the ocean. It's not going to change the frequency of my encounters with bad UX, and it's not going to change how I feel whenever such an encounter occurs.

sdtsui 7y ago

Yeah! It's nice to be able to see the opportunity in bad UX.

open-source-ux 7y ago

"But because it’s open source, you can fix it." You can't fix it really because everyone (understandably) wants a say in the visual and interaction design of the software, but you can't design by committee. Having many participants contributing to source code can work well, but I don't think this model works well for design. It sounds really undemocratic (why shouldn't everyone have their say?). And it undoubtedly contributes to the stereotype of the designer as diva or precious about their work. But can you think of an open source project praised for it's visual and interaction design that was collaboratively developed with dozens or more participants? If you can, it will be an exception, not the rule. When there are too many participants in the design of a program, you end up with a project pulled in every direction and pleasing to no-one. But if you go the opposite route and limit design decisions to a dedicated UX team, you end up generating resentment from contributors or users who feel their input is being ignored.

afarrell 7y ago

One problem with a lot of projects is that they have a poor developer experience for new contributors. For those who are already working on the project, these developer experience problems aren't impactful. So, by selection bias, the project leadership doesn't see them as a priority. The people who do have the necessary perspective to see the impact of the problems are those whom they impede. These programmers don't yet have the project-knowledge to efficiently design a fix nor the relationships with the existing maintainers to persuade them that the fix is worth it. These people could produce a description of the nature of the problem. That takes effort and all it would be is... Whining: Descriptions of problems by those who aren't taking steps to fix them.