“Getting UX to work in FOSS” has been discussed quite a bit here! So many folks want to focus on tools, roles, or process improvements. Many of these tend to assume there is some magic combination that will make UX and FOSS 'just work".
I’m coming to a much different hypothesis: this is a deeply cultural issue that is more management than technique. Some projects are just never going to have good UX no matter what we suggest. But instead of throwing shade, let’s make this a positive conversation: Which FOSS projects are doing great work in UX? What can we learn from them? I assume there are at least few? What are the “Apples of Open Source” Which groups are doing inspiring work?
Projects like Audacity come to mind as it is managing what so many would like to see, a reworking of the entire UX of a 15 year old project. They are navigating huge tech debt and a baroque and very old UX. It’s fascinating to see how they are doing this.
What are others? If you do list a project, please add why you think they are good (e.g. dedicated team, strong leadership, etc) My goal is to interview these teams and collect the a few of the things that seem to have the most impact. I’ll write this up and share it with the community.
And yes, Apple isn’t exactly inspiring in every way. I hope you see my basic point: Apple has for decades been the poster child of good design. Which projects are people saying “we should have more of them?”
They have in common that most (but not all) have solid funding and can afford to set priorities.
While adding Handbreak I remembered that Multimedia is one of the instances where non-hacker-ish users get into contact with FOSS often – see VLC, which does not have a stellar UI but is (or was?) widely uses.
Something to consider is that UI is not simply GUI. There are lots of open source TUIs and fundamentally code is itself a user interface. Writing “good” code that is well formatted and human readable is good user interface. The syntax design for a programming language is a user interface concern.
So why doesn’t better user interface get made? Someone who can design elegant object oriented framework for other devs to use is probably not going to be literate in visual design. Both are concerns of user interface but the tools are different, the audience is different. It’s a bit like asking why there are no well translated English street signs in France, or asking why a racecar doesn’t have a trailer hitch.
That’s compounded in FOSS because it’s DIY. If a designer has input into a FOSS project it’s going to be hard to get that implemented because they may not know the language that the particular project is written in. They have to rely on other volunteers being willing to help them implement their recommendations. And everyone has their own recommendations. Everyone has opinions. And some people are going to like the old way of doing things better (I tried to volunteer for a Thunderbird UX overhaul project in 2019 but gave up after the endless backlash by ancient graybeards who didn’t like the idea of increasing the text size because they personally liked having the max information on screen even if it hurt general readability).
This is where UX normally comes in, in a corporate setting. UX is a means of building consensus through empirical research. “Dev X and Dev Y may disagree on what size the text should be but we can show that 75% of users preferred 16px.” End of argument… usually. Anyone who has worked in a corporate setting knows that things are rarely that easy.
Another way to build consensus is Design Systems. That systemization of UI is more congruent with how devs already approach things and I think the proliferation of Design System thinking is a big reason why user interfaces have become more broadly user friendly.
Aslan, you’re correct, there are lots of ways the UX is hard. But so it managing tech debt, organizing coding standards, unit tests, A11y, and much more. UX is just one of many responsibilities that teams have to face. Why is it they have the time and energy for one and not UX?
I’ll got back to my fundamental point: UX works in FOSS teams that 1. Understand UX and 2. Prioritize it. It’s really that simple. So much of the discussions we’ve seen around this topic tend to be “things the UX designer should do to try and fit in” (You’re not saying this, it’s just a common refrain)
While UX designers can clearly be tone deaf, the bigger point is that the FOSS team is UX deaf. There is nothing you can do for a certain category repos. That’s why I’m trying to find projects (both well funded and less so) that are making it work. Let’s not guess, or provide ‘guidelines’. Let’s point to teams that are making this work. (and stop asking UX designers to ‘just try harder’)
I’d also like to add Visual Studio Code to the list (yep, funded).
I can speak for Taiga6 but it feels a bit dated. That’s why we’re redoing the whole UI (making it 100% accessible in the process, btw) for TaigaNext, but yeah, that’s also a funded project. Taiga made non-tech people enter the agile/lean world back in 2015 with ease. Opinionated and powerful product design. So much that people didn’t care of Taiga was FOSS; they cared about the UX.
I also love GNOME’s Screenshot tool, it works like a charm, fast and manoeuvrable. I love GNOME in general, TBH. It makes my desktop experience superfluid and productive.
On the web side, Jupyter Notebook for Python makes interactive code/output for your research and publishing very fast and elegant.
Also, wouldn’t you agree that Wordpress, running ~40% of websites in the world has a pretty decent UX?
Finally, Gitlab or Mattermost seem quite decent in UX. True, they traverse familiar territory but still.
Scott, you know what I think about UX and design in general when it comes to FOSS, and so yes, I think there’s a cultural thing going on even if there’s nothing “fundamentally” anti-UX in FOSS.
Note: I understand we are discussing here UX as in “visual” UX, not “text-based” UX, where FOSS can show amazing examples in “in-app” developer experience.
I will say that I think A11y stuff is an area where open source projects still have difficulty.
But yes I agree there is also an unfortunately tendency to put the onus on designers.
For why some teams do it better than others, besides funding and prioritization, I think it’s the ability to systemize the design work. Fundamentally I think we should look at design work as being about building consensus.
As for FOSS projects that I think are doing well with UX here’s my contributions:
The commonality on a lot of these is that there are well known closed source versions. So the issue of consensus becomes easier because there is an established pattern to work off of. (Blender might be a good example of that too. Prior to 2.8 it was routinely criticized for it’s UI. I personally liked it but many people didn’t because it varied from industry standard software. 2.8 they brought their UI into line with the industry and since then they’ve had a much better rep. )
Another possibility aside funding: A developer/designer as project lead in a small project where they produce the large part of the code and mainly collaborate with others on bug fixes. This is similar to how a lot of 90s Delphi projects worked: Mostly single creators, importance of a GUI driven tool.
Caveats, history of ideas
Not all 90s tools written in Delphi had a great UX, only a few were open source; the idea here is having a developer-driven, non-corporate model of software creation that provides an alternative more aligned to the personal computing ideas in the tradition of PARC rather than the timesharing/Unix/C/-descending idea of Open Source as we have it today (And if you look at that the origins of that culture, you actually get anti-UX ideas in despising “lusers”)
Thank you for all the suggestions! I’ve tried to look at them all and nearly every single one is a fairly big project with solid funding. That’s fine, but it seems to be almost forcing me to concede that it has to be a well funded FOSS project before it takes UX seriously? That actually makes sense, teams that make money have a much stronger incentive. If so, that seems a bit sad.
The only project on this list that didn’t seem to have an obvious funding model was Jupyter Notebook. Are THEY the team I’m looking for? I just can’t believe there are no small FOSS projects that have a mature UX practice. I want to be wrong but the fact that you all can’t come up with any seems pretty clear…
I just can’t believe there are no small FOSS projects that have a mature UX practice.
I guess “mature” is tricky here. If it means that there is research, written goals, evaluation, roadmaps etc. then it almost forces maturity to be only found in big projects, since all these tools are helps in coordinating bigger teams.
If it means “software that has few obvious usability flaws and is well liked by a community at least partly consisting of non-developers” it becomes at least possible to find projects that are “mature”.
Here are some small ones that could match that category:
You’re correct “mature” is likely too strong of a word. I just meant that I’m looking for a small team that doesn’t put the poor designer through the wringer for any change. So instead of mature how about:
Encourages UX contributions
Discussed them openly, considers alternatives
Helps pair an engineer to help implement it
Even this seems like asking a lot as most FOSS teams don’t really even have the concept of “pairing” as that implies some sense of central coordination
Another example that I like is the tilde editor. Admittingly, it is an editor for people on Unix, but still: “Tilde is a text editor for the console/terminal, which provides an intuitive interface for people accustomed to GUI environments such as Gnome, KDE and Windows.”
The rest of the text on its website is a great model how to write a description of design goals and choices derived from that – its short, useful, avoids jargon and shows examples.
Tilde also has a “Design Principles” section on their “Development” page which is a positive.
I was hoping to find an example of a project that specifically calls out UX design as a key part of their process. For example Mastodon has a decent UX but basically ignores all UX input. Krita has very little on their contributions page but does have a UX designer as part of the core team. Outline has contributors page that calls out features that need attention and they use “Good first issue” as a tag in issues.
Baserow hires ‘front end devs’ but has zero UX mentioned anywhere in the onboarding, submissions, or getting started docs. This doesn’t mean it’ UX hostile, but doesn’t make it easy to get started.
I love all of these examples and they do appear to have solid UX design. I’m just surprised by how hard it is to find examples like PenPot and Audacity, which have very positive UX processes in place.
Is what you refer to a process or rather something like UX principles/guidelines? (I could only find the latter for Audacity)
Processes and Formalization in FOSS
Processes (as in formalized path from idea to final design) seem to be very rare in FOSS (and might be mainly political in non-FOSS contexts, too); The non-existence is not limited to UX. Developer questions like “How to contribute patches” are usually treated more as a technical how-to rather than an abstractly defined process – see Penpots contribution guidelines.
Fair point. I think I’m asking for two separate things:
An internal team that understands and prioritizes UX issues. This shows up in mostly social ways: how they interact with the community, ask for input, preview problems, ask for help, and accept submissions. Audacity and Figma do this well.
Documentation on the repos that makes it easy for newbies to find out what to do, understand what the team has already decided, and get started in the Issues section. Very few repos do this well (which is too bad as there are some easy things to do here)
I’m basically writing my FOSSBack talk in real time here It’s becoming clear to me that the tiny repo with a single overworked maintainer has a VERY hard job. It’s the funded projects that have the best UX, and for good reason. They have a coordinated team.
This isn’t meant to say small teams can’t have good UX! It’s just understanding WHY funded teams have better UX and how can smaller projects learn from that?
Very well put! I want to make it extra clear that I don’t think small solo repos have bad UX (you certainly didn’t imply this, I’m just being clear)
It’s more that ANYTHING related to a bigger, more ambitious project (e.g. one requiring unit tests, refactoring, eliminating tech debt, and yes, UX) does require more management and that isn’t well discussed.
Again, not saying bigger open source projects can’t have great UX, but it is not the norm. For example, I’ve heard for more than 1 person that tech debt is a PAIN in Open Source. Of course, it happens in proprietary sw just as often, but there is a stronger social structure in place to clean it up.
This point was specifically what I took issue with in the Cathedral & the Bazaar section that claimed this WASN"T necessary, Open Source doesn’t need “project management” yet at the same time putting all the responsibility on a “strong central figure” which is still “project management”.
I noted another interesting point when reading about power and professions: The most prestigious positions within an ecosystem of professions are usually the ones that deal with other professionals rather than with the public : It is far more efficient (your collaborators know how to act “professionally”) and allows to maintain a self image of how the profession should work like (as less of the messy outside world seeps in.
Look at an issue tracker of an open source project where devs work for devs, and most issues seem to be about technology, solving programming problems, improving code; all nice tasks to work on (even for a lay-dev like me they make sense or would make sense if I would read the code more deeply). However, on many somewhat successful end user directed projects the issue tracker is full of, well end-user stuff like feature requests, issues that are not always reproducible, glitches due to systems being too new or too old… all thing that are not the “core” of development work and thus are probably not great to work on, similar to these “can you fix X, no time, not budget, maybe test with joe from the other team”-requests in UX.