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:
Mastodon
Outline
Krita
Gitlab
Basedash
Baserow
Nocodb
Grist
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?
I guess they have the best management/coordination for non-code stuff. A small project like tilde or some single-person-written-in-delphi-tool can have a great UX, but usually does not have…
A team that prioritizes UX (but a single person that does prioritizes it mainly for themselves)
Documentation onboarding new people (because it is basically one main person who occasionally might take patches)
Which would actually match well with the idea that collaborating on code has some advantages that other forms of cultural collaboration do not enjoy; additional work is needed to make that work.
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.
As far as I know, they all have paid designers, paid PMs, and function more like modern software teams than strictly all-volunteer efforts. Several are relatively small teams.
Thanks Daniel, that’s very helpful. What I’m finding (reluctantly) is that the teams with the most mature UX practices tend to be smallish teams that are funded with dedicated PM and UX teams. This shouldn’t be a surprise but it begs the question: Why do ‘classic’ FOSS teams struggle with PM and UX teams? It’s not that they can’t achieve big goals but it more that they all have some painful story about “how they want to work”, e.g. GIMP, Linux Desktop (as a group), or even graphic editors like Krita all have some type of UX team but there is almost always drama around history and culture that make UX, if not very very slow, at least problematic.
The goal of my talk is to focus on positive examples and NOT shame any specific team. My point is that it appears the most, if not all, of the positive UX examples are these type of small focused (and funded) teams. It’s a bit hard to avoid talking about that (which I know will likely blow up in my face)
Let me add Cockpit here.
Cockpit is a web-based graphical interface to administer Linux servers.
From my impression, they have some good practices:
establish a clear product vision,
communicate the vision in clear words,
tackle one common problem in Linux server administration: use a simple GUI instead of hard to learn Linux commands, but anyway have a Linux terminal in the browser if you need to work with Linux commands
have a “Design first” approach
explicitly use design drafts (created with Penpot etc.),
run usability tests,
iterate and release often.
One thing that makes me a bit sceptic are the targeted users: everybody from Linux layman to expert admin, which is IMHO a bit too unspecific.
However: I used it for a while and like it. To be honest, I run it on an OpenMediaVault 5 host, but I prefer Cockpit over OMV because of its ease of use. I don’t know how it compares to OMV 6 with its revamped GUI now.
Cockpit is a Red Hat sponsored free software project and AFAIK the project is run by Red Hat people.
Sometimes it is interesting to look at adjacent communities. I found that tools in game creation communities are an interesting case:
Like open source software, they are for a community of people the creator is part of…
…but they are often focussing on end users/non-programmers
Like open source software, there is an emphasis on creation, creativity…
…but not in code, but via music/graphics/animation.
Most likely, these apps don’t have dedicated roles like designers, an explicit roadmap and other indicators of “good” design practice.
Interestingly, some of the free tools share their source code, but not all of them do. I guess, in a community with a large proportion of non-programmers, it might not be that interesting. The tools seem also created by single creators; the collaboration that FOSS promises might not be as useful to them and/or pose a significant overhead. (Seems this community’s view on licensing is also different, even for the creative works in graphics and music; the similar-to-FOSS Creative Commons Licenses are rarely used; instead a brief paragraph stating creator’s wishes about commercial use and attribution are common)
I want to add to this - as a designer in the industry for a very long time now. It never really occurred to me to be a FOSS Designer. I always just thought of open-source as a developer world. Literally the other day, was the first time I thought “I wonder if designers can contribute to open-source and how that works?”
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.
as @jcklpe said here too - I really wonder how they will prioritize; but I guess it would be just the same with code contributions. In the end the ‘owners’ of the product will implement if they see fit.
So perhaps its more of a requirements to contribute. For example - if you want to contribute design there needs to be a fully clickable prototype, notes, and documentation on the changes you are making and why. The design needs to be open so that anyone with the link can also access any assets available (or also upload new assets to the pull request)
In the end, if it gets implemented or not would be really up to the “PM” of the project.
Perhaps if we created a simple framework for people to understand how to contribute, more people would be willing to do so.
Designers may not know the language, but if they have an interesting contribution, the owner can definitely reach out to them to discuss more so they can allocate time to implement if worthwhile.
As I’ve talked to other FOSS projects it’s clear that those with the most effective UX are just more organized. They plan, they have roadmaps, they prioritize. This is the world in which UX is very helpful.
The smaller repos with little UX experience are MUCH harder to work with. I’m very empathetic to their pressures. But many don’t understand what UX can do, and how it can save them time.
There really are two UX paths here: 1) To introduce UX into a repo that doesn’t understand UX well and 2) Work for team that appreciates UX and knows how to prioritize it. Both are reasonable goals. The risk with #1 is that they may not want it and honestly, there may be little anyone can do.
This is why I’m trying to call out the teams that do great UX to show that it is happening, get the community to know it can happen and get people to say “more please”.
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.