There is far too much 'walking on eggshells" in #OpenSource, mostly because the power lies with the people that are the most easily offended. I've been clobbered for saying the "#UX of opensource isn't great". The advice is always the same:
Go slow
Don't rock the boat
Make small changes
That is great advice, for a dysfunctional relationship. To be clear, I'm NOT saying be dictatorial! I'm saying we can't fix a system that doesn't want to be fixed.
1/2
@scottjenson I'm not disagreeing with you, but I wanted to share based on my own experience. On multiple occasions, somebody with UX ambitions will come into the project, guns blazing, with a bunch of changes they want to make. The problem is, they don't have the context of why the project UX is the way it is now, and all the different variations and conversations that went into it in the past.
So I usually do have to say "go slow" because to work on improving UX you need to understand the features, requirements, users, context and more before you can start throwing out changes. You can't just start randomly making changes because you prefer how it looks but have no idea what it needs to do.
If you want to remove dropdown X and replace it with control Y, and move image Z around, it's important to know why they are there in the first place before improving them.
And in most cases, when I ask them, "Can we take a moment to have a conversation about this first? I'd like to tell you about how X works and some requirements of its UX" that person is gone.
So I'm sure they hate the idea of slowing down and having a conversation. But I'm not going to let somebody drop in and randomly make changes based on a whim, and lack of product knowledge.
@gabek That sounds like a junior designer to me. It's irritating as hell and frankly, isn't even doing #UX right.
My point is that even when you DO go slow, things often don't work. UX work usually cuts across parts of the product, so affects a broader code base. Or worse, it's asking for a change someone has recently checked in and they don't want to touch that code ever again.
Just saying the "go slow" mantra needs more support in order to work for UX
Case in point: https://bugs.documentfoundation.org/show_bug.cgi?id=160290 is an example where I (& the project's own lead designer too) have had to wrestle endlessly with some sealioning strawman argumenter in a report about what clearly is a UI bug (in LibreOffice Calc), not something you'd find debatable in any UX-centric project. It's exhausting.
Good Design must at least start with the maintainers. Designers can't "PR our way" into a good design, pushing design into project that doesn't really want it.
I agree with the advice above! We can go slow. I'm just saying it has to be done JOINTLY. The maintainer/core team has to want UX before the PRs come rolling in.
2/2
One last point: I'm not saying ALL #OpenSource software has bad UX! There are lots of positive examples. I'm just saying that, as a culture, it has some maturing to do. The very old and very tired advice of "go slow and try a small PR" works great for engineering (and documentation). I'm just saying that doesn't work for UX, which requires a more coordinated, shared teamwork approach.
@breadbin at a high level, people don't want bad #UX of course. But there is just so much "you're doing it wrong" combined with "but I don't like that" that it makes progress very hard.
Great UX comes from teamwork, both sides working together. But that requires some homework and shared understanding so the conversations can be productive.
If teams don't want this type of discussion, we can't do much from the outside.
"Go slow" works for personal development. If you set your goals too far, you will give up before you reach them.
It doesn't work in the political system. Before and after elections, the political process comes to a standstill. Every now and then, a conservative party wins and development is stopped again. Progressive parties need to take ten steps at once, if they want to bring society further.
Design is a concept. You can change small parts of it. But for a new design, you need to change the whole thing systematically. With everyone involved.
I remember early access games (e.g. GolfIt!) with a horrible UI. When they come closer to release, you can see new designs, which are way different and make everything matching and consistent.
Never seen any "go slow" on such changes.
@paninid@scottjenson no it's just plain wrong. Is UX even a word fitting for open source? Open source is a concept and not a program/app. Can a concept have user experience? If you say oss UX is bad you are generalizing everything written with this idea/ license, which might be true for a big part or even a majority but saying everything open source had bad ux is plainly wrong. Also why not fork instead of getting your PR in? Make a fork, make your UX improvements be happy if origin uses yours.
@SomeAnoTooter
I never said that. There are excellent examples of great UX in OSS, it's not doomed, there is a tendency for engineering-lead teams to overly focus on the functionality.
This can be improved. That's why I made this post, I strongly believe OSS can have great UX design. I'm just tired of some maintainers in OSS telling me that it's entirely MY responsibility to package up my work into tiny bites so it's acceptable to maintainers that don't really want a better UX.
@scottjenson you wrote: "for saying the "#UX of opensource isn't great"", so yes you at least wrote it here. Yes you are correct with the engineering focus.
I find it hard to say anything about responsibility in the space of open source. The beauty of the freedoms kind of free maintainers from any demands. So I can totally understand when they get annoyed by demands that might be camouflaged by legitimate criticism. I think what you are talking about is also a reason for toxicity with Linux.
@SomeAnoTooter I'm not trying to make a large categorical point. I'm just trying to say that there MIGHT be a better way to improve UX in #OpenSource other than "just do a small PR". Let's start with:
Have the maintainer want better UX (not hard)
Discuss the changes ahead of time so everyone is on board (hard)
Create a list of small PRs needed
THEN start with the individual PRs
That's a process that will get the work done and hopefully have everyone in sync
@scottjenson@SomeAnoTooter I think it is this part 2 which is a problem here. A lot of UX stuff is highly subjective and about creative control, and this is where the design-by-commitee that is a cornerstone of OSS might not work. Or at least I've yet to see it work except in very few cases
@julik@SomeAnoTooter sorry for the late reply but I have to disagree with you. Good #UX is seen by many programmers as "arbitrary" but to those of us trained in it, there is strong rationale. This is actually one of the core problems with #opensource, programmers have strong opinions without much experience.
I'm not at all against discussion and of course "not all programmers..." I'm just saying it's exhausting for UX people to defend even the most basic UX improvements.
Add comment