zlacker

What is it about insanely great user experience design that's hard to "open source" in the same sense that engineers are able collaborate on software, like Linux, and achieve massive distribution?

>>bradge+(OP)
Design is artistic and artists don't collaborate well due to art being a personal endeavor? Unless it has a 'decision maker' at the helm like a film or it is intensely personal like a band.

Just a idea to get some ideas from others -- this does not necessarily represent how art or artists feel or operate since I am not one and don't actually know.

>>bradge+(OP)
I dont think UX is "harder". But the kinds of people that can realize a launch like this need to be technically minded, tend to work alone, and lean a lot more on the "Linux" side of this than the UX side. It's like trying to find the perfect Programmer/Artist hybrid to make a game with; it's simply two different mindsets that rarely get taught together.

As an example, look at most of Linux Distro's UX since you brought it up. They aren't meant for the layman the way Mac/Windows was. the deeply technical audience, for better or worse, puts up with a lot of UX issues for their tools. That doesn't work the same way for a general audience website or app.

----

But that's from the "why can't programmers art" side of the argument. Of course, that begs the question "why can't programmers find artists to work with them?"... well, there's a dozen different reasons. Culturally, historically, socially, and so on.

But to list the one big reason; there aren't stereotypes about programmers being short on cash and needing to commissions out programs after their full time job just to get by. (a few) programmers do all that just for their own self-fulfillment or for their own goals, with no expectations of a big payment most of the time. Because many are already financially comfortable.

>>bradge+(OP)
The difference is that you can see it. If you have two highly skilled contributors with very different programming styles, they can still collaborate within the same codebase given a goal and the end-result is the same for your users. When a code contribution is marginally better or worse in its approach than another the difference is negligible to the project as a whole. By contrast, users notice when a single color is different for design elements. And they complain extremely loudly about it.

On the contributor side:

- Visual style guides require much more time and skill to create (relative to style guides for code) and still generally fail to achieve anywhere near the aesthetic unity of a single great designer with total control.

- If you commoditize your design elements to the point where it is easy to contribute them, then it is no more difficult to do it yourself to begin with.

- Delegation of design work still requires that you funnel it somewhere to be judged on qualitative measures, rather than the pass/fail nature of code

Generally the best you can do is collaborate very, very tightly and then funnel it through a single person in the end anyway a la Python's BDFL in a very trial and error fashion.

>>Greed+Ke
The difference is that you can see it. If you have two highly skilled contributors with very different programming styles, they can still collaborate within the same codebase given a goal and the end-result is the same for your users. When a code contribution is marginally better or worse in its approach than another the difference is negligible to the project as a whole. By contrast, users notice when a single color is different for design elements. And they complain extremely loudly about it.

On the contributor side:

- Visual style guides require much more time and skill to create (relative to style guides for code) and still generally fail to achieve anywhere near the aesthetic unity of a single great designer with total control.

- If you commoditize your design elements to the point where it is easy to contribute them, then it is no more difficult to do it yourself to begin with.

- Delegation of design work still requires that you funnel it somewhere to be judged on qualitative measures, rather than the pass/fail nature of code

Generally the best you can do is collaborate very, very tightly and then funnel it through a single person in the end anyway a la Python's BDFL in a very trial and error fashion.