5 ms·

I agree. I definitely the guidance it provides - it helps me to align my interests with open source. Kinda like online dating with an open source project. I was

by gawker 14y ago

I agree. I definitely the guidance it provides - it helps me to align my interests with open source. Kinda like online dating with an open source project. I was enthusiastic to contribute to the Django project but had no clue what to do.

tangue 14y ago
Yes that's the problem. The landing page is pretty good, but when you click you're send in the usual Mozilla's maze. What makes me sad is that they're not looking for content strategists, UI designers or UX specialists.
- kibwen 14y ago
  They do seem to be looking for those, but as paid employees rather than volunteers.[1] Those roles are probably harder to outsource to the community. [1] https://careers.mozilla.org/en-US/ https://careers.mozilla.org/en-US/
  - wolfgke 14y ago
    Can somebody tell me reasons why UI designers or UX specialists are more difficult to outsource? I know that many open source projects have difficulties attracting them, but I really don't know the reasons (any reason designers working in this field gave me also should apply to programmers - thus they also couldn't answer this question).
    - gawker 14y ago
      I'm also curious to know. I think it's a really good opportunity for showcasing work and giving back to the community.
    - kibwen 14y ago
      Are you a UI designer or UX specialist? If so, in what way would you like to use your skills to contribute to open source software?
      - wolfgke 14y ago
        No, I'm just a simple developer whose design skills suck so much, that I don't even try to interfere with the designer's affairs (that's why I can sustain good relationships to designers, since they hate interference of customers; at least, as long as I don't try to come up with ideas like testability of designs ;-) just kidding).
    - rmrfrmrf 14y ago
      1) Visibility. Code isn't visible to the end-user, so it doesn't really matter how a programmer gets from point A to point B as long as it's bug free and efficient. UI/UX, on the other hand are exactly how your users define you, so it's not something you want to potentially leave to the programmer that just installed Gimp and learned how to use the shape tool. 2) Testing. Good UI and UX need to go through several rounds of highly controlled testing. The "controlled" part is the factor here--a group of guys in the basement isn't going to cut it, and there's no way to verify with open source communities that testing was done correctly. 3) Consistency. Design teams are able to churn out more consistent work once they've found their 'style'; multiple disparate designers are more likely to break that style. 4) Preventing design by committee. Pull request discussions for design changes could turn into disastrous free-for-alls that end up turning Firefox's chrome neon blue and each button red because the majority of random devs think it's 'cool'. Design is more successful as a dictatorship than a democracy.
    - thwest 14y ago
      I imagine that the less concrete requirements on the UX make it more difficult to negotiate design decisions via pull requests. Typically OSS code contributions don't include design changes (e.g moving proven core components from shared state to a message queue for aesthetics), but bug fixes or very concrete feature additions which are easy to reduce to tests.
    - crystalbeasley 14y ago
      I started writing a response about my experience as a designer at Mozilla and it got really long and I turned it into a blog post called "Code talks and designers don't speak the language." Thanks for inspiring me to come out of blog hibernation. http://skinnywhitegirl.com/blog/code-talks-and-designers-dont-speak-the-language/930/ http://skinnywhitegirl.com/blog/code-talks-and-designers-don...
      - rmrfrmrf 14y ago
        Fantastic blog post! You have a much more optimistic approach that I could learn from. Too often I find myself saying "Because I said so, dammit! You code, I design!," but the idea of building trust and credibility is a good one. One of the challenges of design education for developers is that developers are naturally geared toward rule sets, which becomes a problem when the designer decides to break the rules for a justifiable reason. Just like devs couldn't teach a designer to code in a day, a designer can't really provide all of the ins-and-outs of good design to devs. Perhaps education needs to be introduced to devs as to the value of UI/UX, rather than the specifics.
      - wolfgke 14y ago
        Good blog post. Concerning point 3: "Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code." Developers also have nasty arguments about what code is correct/the better one etc. ;-) So this argument also should in principle apply to developers - but developers don't seem to have any problem about that point. I don't know whether the reason is simply that developers have less a problem with conflicts? But nevertheless: there are well-established principles to judge which code/software architecture is better (elegance, smallness, extendability etc. (all of these can be judged rather objectively) - which role these play, depends on the project). I think it would help project leaders if you suggested a similar process for judging design decisions. Just an idea. If this is a bad idea of me, suggest a better one.

by gawker 14y ago

tangue 14y ago

Yes that's the problem. The landing page is pretty good, but when you click you're send in the usual Mozilla's maze. What makes me sad is that they're not looking for content strategists, UI designers or UX specialists.

kibwen 14y ago
They do seem to be looking for those, but as paid employees rather than volunteers.[1] Those roles are probably harder to outsource to the community. [1] https://careers.mozilla.org/en-US/ https://careers.mozilla.org/en-US/
- wolfgke 14y ago
  Can somebody tell me reasons why UI designers or UX specialists are more difficult to outsource? I know that many open source projects have difficulties attracting them, but I really don't know the reasons (any reason designers working in this field gave me also should apply to programmers - thus they also couldn't answer this question).
  - gawker 14y ago
    I'm also curious to know. I think it's a really good opportunity for showcasing work and giving back to the community.
  - kibwen 14y ago
    Are you a UI designer or UX specialist? If so, in what way would you like to use your skills to contribute to open source software?
    - wolfgke 14y ago
      No, I'm just a simple developer whose design skills suck so much, that I don't even try to interfere with the designer's affairs (that's why I can sustain good relationships to designers, since they hate interference of customers; at least, as long as I don't try to come up with ideas like testability of designs ;-) just kidding).
  - rmrfrmrf 14y ago
    1) Visibility. Code isn't visible to the end-user, so it doesn't really matter how a programmer gets from point A to point B as long as it's bug free and efficient. UI/UX, on the other hand are exactly how your users define you, so it's not something you want to potentially leave to the programmer that just installed Gimp and learned how to use the shape tool. 2) Testing. Good UI and UX need to go through several rounds of highly controlled testing. The "controlled" part is the factor here--a group of guys in the basement isn't going to cut it, and there's no way to verify with open source communities that testing was done correctly. 3) Consistency. Design teams are able to churn out more consistent work once they've found their 'style'; multiple disparate designers are more likely to break that style. 4) Preventing design by committee. Pull request discussions for design changes could turn into disastrous free-for-alls that end up turning Firefox's chrome neon blue and each button red because the majority of random devs think it's 'cool'. Design is more successful as a dictatorship than a democracy.
  - thwest 14y ago
    I imagine that the less concrete requirements on the UX make it more difficult to negotiate design decisions via pull requests. Typically OSS code contributions don't include design changes (e.g moving proven core components from shared state to a message queue for aesthetics), but bug fixes or very concrete feature additions which are easy to reduce to tests.
  - crystalbeasley 14y ago
    I started writing a response about my experience as a designer at Mozilla and it got really long and I turned it into a blog post called "Code talks and designers don't speak the language." Thanks for inspiring me to come out of blog hibernation. http://skinnywhitegirl.com/blog/code-talks-and-designers-dont-speak-the-language/930/ http://skinnywhitegirl.com/blog/code-talks-and-designers-don...
    - rmrfrmrf 14y ago
      Fantastic blog post! You have a much more optimistic approach that I could learn from. Too often I find myself saying "Because I said so, dammit! You code, I design!," but the idea of building trust and credibility is a good one. One of the challenges of design education for developers is that developers are naturally geared toward rule sets, which becomes a problem when the designer decides to break the rules for a justifiable reason. Just like devs couldn't teach a designer to code in a day, a designer can't really provide all of the ins-and-outs of good design to devs. Perhaps education needs to be introduced to devs as to the value of UI/UX, rather than the specifics.
    - wolfgke 14y ago
      Good blog post. Concerning point 3: "Probably the most daunting question for projects without any design lead that has the trust of the team is, how do the devs know if the proposed design is correct? Without that trust, bugs quickly devolve into nasty arguments. How you build that trust has been the subject of entire books. But the question remains, who and how do you approve a mockup? The code review process works great for just that… code." Developers also have nasty arguments about what code is correct/the better one etc. ;-) So this argument also should in principle apply to developers - but developers don't seem to have any problem about that point. I don't know whether the reason is simply that developers have less a problem with conflicts? But nevertheless: there are well-established principles to judge which code/software architecture is better (elegance, smallness, extendability etc. (all of these can be judged rather objectively) - which role these play, depends on the project). I think it would help project leaders if you suggested a similar process for judging design decisions. Just an idea. If this is a bad idea of me, suggest a better one.