[bborud]

I'll bite.

The same could be said for programming: it costs a lot to produce code. In fact, if you run sloccount on Inkscape you end up with about 470.000 lines of code. Whatever way you slice it: that's a considerable effort. Yet people have contributed that for free.

Does this mean that UX-designers aren't interested in working on open source projects? Or does it mean that it is hard for them to collaborate with open source developers? If so: what are those problems?

The reason I'm wondering this is that if I were a UX designer wanting to make a name for myself, making some piece of open source software UX really good would seem like the best possible way to promote myself.

[mikekchar]

I think it's a slightly different issue. A UX designer usually does not have the ability to run a project independently from the beginning. A programmer can, even if it results in a crappy UI.

Successful open source projects don't usually start with teams. They start with programmers with an itch to scratch. It's hard to get investment in a group of people. Everyone is always keen at the beginning, but drift away as the realities of the daily grind kick in.

So if you are non-programming UX person, you are dependent on a programmer who might not stick around. Then you are shopping around for programmers (which never show up). If you are a programmer who wants a UX specialist, the one you start with usually wanders off and then you are shopping for a new one (which never shows up).

The result is that programmers develop a culture of building these kinds of apps and UX designers don't. Even if a UX designer shows up late in the process, they now have to fight all the programmers who have gotten used to making the decisions. And one of the perks of running your own project is not having to listen to other people. If you want to do what other people tell you, you can get paid a lot more ;-).

[simonh]

I have a theory. There's a much weaker positive feedback loop. If a commercial product is nicer looking and easier to use, more people will buy it so there's more money to fund development. Management will demand redesigns and improvements because that creates more revenue.

With open source, the feedback loop from users to developers is much weaker because it's not powered by money. It turns out changes in cash flow are a valuable signaling mechanism. I think this is an issue with many aspects of Open Source development, not just UI.

I'm not in any way saying this is an unresolvable issue or that it dooms OS projects, or anything like that. I just think it's a factor.

[dom0]

My two cents:

- UX designers that are actually good at their job seem to rarer than good programmers

- Hence the pool that would or could contribute to FOSS is smaller

- Getting UX changes in is likely something that maintainers don't really like, because it's harder and more time consuming to review (eg. the code you can just look at, but to review a .XML UI you need to apply patches, compile/build, play with it etc.), also UI changes will almost certainly require a bunch of code changes, so if you're changing a ton of lines to "improve UX", then it's not really a great incentive for a maintainer to invest his time into merging that (because it's "just UX").

UX also tends to be opinionated, the guy who wrote the interface originally probably has no issues using it himself, but is probably somewhat opposed-by-default to changing it (works for me™).

Also, if the UX human isn't also a good coder she probably needs to find someone who works with her to make the necessary code changes to support her UX changes, which would be quite challenging in many projects. (Why would I invest a lot of time to work with someone - that I don't know, has no reputation in the project - on something where maintainers will probably not give some sort of "yeah we'll merge that"-waiver?).

- Good UX has a lot to do with consistency. So fixing up an inconsistent project will mean tons of changes, exacerbating all the issues above. It might be as big a change as porting to a different language or framework. How likely is maintainer acceptance for such changes?

So unless there is a process for doing UX in a project, and all the project maintainers back the process, and the process is actually somewhat sane, it's unlikely that it'll work out. This might mean things like having an UX review queue and UX review for new interfaces. Imposing strict UX guides on code/feature contributions might also deter contributions. So you also have to balance these things.

[WorldMaker]

«to review a .XML UI you need to apply patches, compile/build, play with it etc.»

That's also assuming that you have an XML or designer friendly UI toolkit at all. A lot of Open Source is built with GUI toolkits that use essentially 100% code and don't have good designer-friendly tooling (because the programmers were busy scratching other needs first). That definitely narrows a lot of designer input to designers that also can code.

A lot of people give Electron flak, but if there is one benefit to Electron becoming more common in the wild for open source projects, its the relatively much more designer friendliness of HTML/CSS(/SVG/etc) as opposed to classical C++ macros and duct tape UI toolkits.

For that matter, and bringing things a bit more on topic, I'd think Inkscape could be a good application to "dogfood" their own tool and own code a bit further and build more of their UI/UX elements in SVG itself. (Maybe even in a way that others could piggy back off of for future applications.)

[uabstraction]

"Don't have good designer-friendly tooling (because the programmers were busy scratching other needs first). That definitely narrows a lot of designer input to designers that also can code."

This is essentially the case with GTK+. Glade, though it has potential, is practically useless in it's current state. I've searched far and wide to find a mature project using it - so I can learn how to use it on the next level - and came up empty handed. There is no next level.

As far as it goes with GTK+, the only people designing UIs are programmers. It's all either hard coded in C or Vala (or sometimes C++), or defined in XML using tons of features that aren't implemented in Glade at all, and require an intimate knowledge of the GTK+ API.

As a free software enthusiast trying to work on a GTK+ application, I'll be the first to say, things could be (need to be) much better here! Beyond a couple trivial examples, the reference, and a couple dated books, documentation is extremely scarce. The tooling is incomplete, and it seems that the majority of people working in GTK+ have either grown used to working like this, or moved to another UI stack. Making GTK+ programming more accessible doesn't seem to be a priority (and adding more language bindings, or entirely new languages don't help nearly as much as a couple solid books on GTK+/GTKmm and a first class Glade would).

The only way to really learn the ropes seems to be by meticulously dissecting dozens of free software projects. No one will ever invest their time do this commercially when they can hit the ground running with Qt. It only seems remotely possible for stubborn people who write software as a hobby, and people who have matured to the point they can sell their knowledge. For a UX designer to end up here, they would have developed much more valuable skills in the process.

[robin_reala]

Two things:

- Consistency. A good UI requires consistency throughout, which requires a good understanding of the entirety of a piece of software, and a willingness to work at a high level. For open source packages there’s rarely a UI standard to hold individual problems up against.

- User testing. UX design doesn’t work in a vacuum, it requires user testing to be effective. This costs a lot of time and effort to organise, and isn’t something you can hack on for a few nights. It’s possible to to A/B testing to gain data of course, but then you have to persuade your friendly developers to implement a testing framework and have some place to store data while waiting for the results to analyse.

[mark-r]

The easiest way to get consistency is to have a single person in charge of the UI. It doesn't need to be a UX designer specifically, just someone with a strong sense of style.

For a contrary opinion on the cost of usability testing, see "hallway usability testing" at https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

[jasonkostempski]

Part of good UX is consistency and getting that kind of requires a consistent team or an all-knowing overlord. My guess is that's why it's hard to get to and keep a good UX in OSS. Once the UX is good there shouldn't be much work for a designer to do and they're not gonna sit around, not getting paid, just to make sure someone doesn't mess it up, that is boring.

[TeMPOraL]

I'll add another potential reason - culture. Many (most) developers grew around open source, or at least interacted with it in significant ways during their (work and/or hobby) career. Many if not most of the tools they (we) use for programming come from open source too. So we're kind of used to this environment of collaboration. You see a project you like and have some spare time, it's natural to contribute.

I doubt UX specialists live in such a culture. I might be wrong, but from my experience with artists and designers, it's much more of an individualistic culture with stronger commercial interest. I.e. "I do it for myself" and then "want my work - pay me".

If that is true, then there's simply much less UX specialists with spare time and interest in open source than there are such developers.