1. Communication. Developers use a completely different language than designers. If I come in talking about alignment, developers are thinking 'right left or center justified?' When developers start talking about recursion, I go to sleep.
2. Attitude. Often developers seem to think of designers as 'artsy' types, and design as 'nice-to-have,' which is to imply not necessary.
3. Attitude. Designers often get emotionally attached to their work and get discouraged or give up when someone disagrees, has a different idea or wants to go another direction.
4. I can do it myself. A LOT of developers - particularly less experienced ones - think design is something they can, and are, successfully doing themselves. After all, it's just pixels on a screen, who needs photoshop, right?
5. Small changes. Developers often make small changes to designs. 5px extra padding here, no margin there. Blue is blue, right? We'll just use that 10x10 icon the designer did for that page for this 25x25 icon we need on this page. This drives designers insane.
6. Eyecandy. This goes to a lack of understanding of the design profession; many think design is just slick icons and pretty colors. Developers who have worked with talented designers know that designers can improve entire systems, helping streamline work flows and adapt the system to actual users.
7. Bad designers. Oh yea, there's -a few- of us out there that just picked up GIMP yesterday and think a 600 x 600px favicon should be fine. Even designers capable of really good work may not understand why a 2400x1600 image cannot be used thumbnail-size on the page. This is sad, but I've seen it.
8. Lack of trust. Developers may have worked with bad designers in the past. Most likely they have, actually. They'll likely limit the designers interaction to making icons and css rather than involving them in the system design and planning. Designers may not give as much as they could because they don't trust the developers to value their input or even understand and execute their contributions well.
Of course, that's not to say all projects are this way, and in fact, when I've been involved in projects from early-on, this is very much not the case.
However, I've run into the above issues in my professional career more than once, working face-to-face with people. Trying to make the relationship work online, in projects as distributed as OSS projects are, that's very difficult.
But I think it can be done. For distributed design to work, designers need to be brought on board from the beginning, in the planning phases. The initial designer or designers would have to be responsible for creating a clear vision, clear guidelines, and a well-documented style for future contributors to follow. All contributions would have to adhere to those guidelines, and developers would have to be as adept at spotting violations as designers.
Part of the problem here is also making designers aware of projects to work on. Designers generally join different message boards (if they join message boards at all), read different blogs and generally don't run in the same circles as developers, possibly with HN being one of the exceptions. I'm not sure how to change that...
http://www.amazon.com/Non-Designers-Design-Book-Typographic-...
It's a quick, easy read and the concepts can really apply to any kind of visual design. Any of her other titles are also excellent.
> 7. Bad designers. Oh yea, there's -a few- of us out there
> that just picked up GIMP yesterday and think a
> 600 x 600px favicon should be fine. Even designers
> capable of really good work may not understand why
> a 2400x1600 image cannot be used thumbnail-size on
> the page. This is sad, but I've seen it.
re: 4) As a developer, I recognize that I am not the best at everything and don't pretend that I could design an awesome Wordpress theme if my life depended on it but as you point out, design is not just the "eye candy". At the same time, I am not just an codemonkey. I want to participate in making something awesome, I want to learn and I want to work with people who know more than I do (I learn more that way and will probably come up with a better result).
In my mind, there is a difference between working together and saying "developers can't design, just go over there and write some code to make my vision come true" (I realize that I'm exaggerating a bit here). Any hint of a "just shut up and color" mentality makes my hair stand up in ways that I just don't have words for.
I don't think that either extreme (designers are the only people who can design or 'I can do it myself') is the right answer in any projects where volunteers are involved. As you pointed out, the trick is finding a happy medium and some way for people who stereotypically think in different ways to find common ground.
Now I have some thinking to do about how I can help reach that common ground in the projects that I work on and will work on.
* Edited formatting because it was hard to read. I'm new here and learning.
http://www.000fff.org/uploads/code_alignment.png
Alignment is everywhere. When you start analyzing interfaces you will often find that great interface design attempts to have as few alignment lines as possible.
Obviously text on a line is alignment too (horisontal).
And then there is optical alignment which is especially important in typography.
The most important function of aAlignment is to communicate what belongs together.
Having objects align also makes for a “calmer” design. Imagine that each new place any object has a beginning or an end adds an invisible line to your design. These makes the design more chaotic. Aligning objects is a way to “re-use” the lines so that you don't end up with too many of them.
(Designer here, although I will not claim to be an expert on it.)
When I had the chance to work in the cakePHP website they were 100% hands off and just let me run wild and do my thing. That has not happened again in my career and I think that continues to be the major highlight in my portfolio (apart from the exciting stuff I'm doing nowadays :P)
Many sites are heralded as an example of 'no design necessary' because they lack the eye candy. However, the minimalism of these sites, the layout of results by date (as opposed to alphabetically or something else) the categories they are arranged by, all are part of the design of these sites. Was a designer involved in this? Hard to say, probably not, but were these decisions made intentionally by someone considering alternative choices? absolutely.
I'm not saying designers are the only people who can design. Just that designers are trained and have experience making decisions like the ones I mentioned above. We can - and do - provide value to software.
Design isn't necessarily about embellishment, but aesthetic choices. Good typography and color scheme choices don't have to be paired with elaborate graphics for a design to be good.
But more to the point of what you're saying, design is NOT optional. It is the essence of how people interact with your website/product. There are certainly some exceptions to the rule, but generally people flock to a more attractive product because it is attractive. Look at any Apple product for a perfect example of this. iOS is far less usable and powerful than Android, but people like it more because it's visually pleasing. OSS is never going to win unless it has that similar level of sex appeal in its products.
The problem here is your very definition of design. If you were a designer, you'd be the bad kind that equates good design with over the top graphics. The best design is subtle. It doesn't call attention to itself or say "look at me." It just is. To paraphrase from the movie Helvetica, good design shouldn't make you say oh look how nice this design is—it should make you say well of course it's this way, why would it be any other way?
Take this very comment page, it's not flashy but I wouldn't say it's bad design at all. It knows it's audience isn't looking for bells and whistles. Everything lines up in a pleasing—and more importantly, logical—way. The typography is decent and there's enough differentiation between the comment and it's meta data. I could go on.
Basically, just open your mind. Bashing someone's profession without hearing their side is never smart.
The way there are upvotes and downvotes on reddit is an important part of the design. It has deep repercussions on the user's dynamics, the way posts get popular or are ignored, etc.
Now, purely font-choosing 'design' is not that important, but if you think that's design, you are misguided.
And this comes from a guy who just codes and does SQL queries all day.
VLC is a product, that is widely used, usable (not the mac version, though), but it is extremely ugly.
It is quite hard to get designers to help us (redesigning all the buttons for example) for quite many reasons. The biggest reason is that we don't speak the same language.
Many designers don't understand the criticism that usually comes around with each modification in open source project. Many developers don't understand how to speak to designers in a polite way (they think they speak normally, but it isn't perceived as such).
Also, many (not all of them) designers don't understand the difficulties of usability, and sometimes mistakes it with "shiny". Usability of a desktop application is way more complex than a website, and the current trend of "removing functionalities" is not always welcomed by developers...
However, I don't loose hope :D
So as harsh as it may sound the answer to your question is that you just cannot get great designers. There's virtually nothing you can offer them in return. If you do manage to get someone on board, do shield them from the "community". Work one on one and put all your weight behind his designs when they are made public. Leet hackorz that are so vocal on many O/S forums and mailing lists can easily demotivate even Mother Teresa in a matter of few replies.
HTH, feel free to vote me down now :)
(edit) On a second thought VLC might be one of few projects that can attract a designer because of its high-visibility nature. Yet the point remains - designers are easily demotivated, way easier than developers, so retaining them is a major challenge.
VLC is quite visible, but that isn't enough, I am afraid :D
* "Glue" team members. The company I've worked for always had at least two staff members who were a bit of both, and could basically plan out and convey ideas from one team to the other. * Assumption of expertise. Each group would trust the other when it comes to both design and programming and no doubting would take place. In case of a conflict, a programmer could tell the designer why a certain design would not work out well citing particular technological reasons; similarly, given a question by the programmer, a designer would explain why a particular design is laid out the way it is, why the buttons are blue etc. Given the conflict resolution scheme, a product builds up based on mutual trust and communication of ideas between the two parties.
Key decision makers on that part of VLC is 2 or 3 people at max.
If the design is there, the code will follow, believe me.
edit: Another problem that i didn't think of when i wrote the above is that, since VLC is a multi-platform application, any SERIOUS interface changes -- changes to work flow, arrangement of options and menus and the like -- need to be copied over to the other platforms.
For instance, VLC's transcoding function, whilst very featureful, is incredibly irritating to use, interface-wise. Suppose i had the solution to this, and i provided it to VLC. That's step one, but in order to get that actually put into the product, not only do i need to have done my part, but then you need presumably multiple programmers to actually get it implemented in the Mac, Windows, and Linux versions.
Editing a NIB and not making it open source, is near useless for the community...
Not to mention that the developers don't have to court those people, it should be the other way around... They should propose their design. This goes for everyone, developers, translators, technical writors... Why would designers be different?
Finally, about the transcode part, this is not a designing issue, but a usability issue...
Heh. Obviously as VLC's developer you know better, but FWIW I've been using VLC on Mac OS X extensively, as my primary video player. I don't think it's unusable, or ugly at all.. I can't be the only one, can I?
I've been working with a designer to try to do this mockup: http://www.jbkempf.com/~jb/VLC_mac.png
(Except maybe the fact that the playlist's default setting always goes back to "shuffle" for some reason.)
Those are some great points, they're discussed in this book: http://producingoss.com/en/communications.html#writing-tone
I think usability is a blend of user experience, usefulness and intuitiveness. I have a hard time associating the latter with either the programmer or the designer.
My experience, as a programmer working often with designers, is that many of them (not all) are more concerned with the visual appeal of an interface and to a lesser extent its intuitiveness and usefulness.
For example, I've built quite a number of web management systems. Most times, when I team up with some designer they'd want to make pretty icons. However, I've come to the realization that we get more praises when the client can just look at his system and recognizes what he asked us to build and can easily guess where to go next. And that more often happens with text buttons. I believe that visual cues have their place, but I also think that many graphic memes have gone beyond useful, which probably doesn't help the relationship between programmers and designers.
On the other hand, I remember a time when I would build some quick ass functionality, but presented in such a convoluted way that only other programmers could understand the prowess and usefulness of the feature. You had to get up up early to get me to change them!
Programmers tend to be very minimalist, whereas designers are often very expressive. I think there is an effort to be made on both parts to reach a middle-ground. Designers need to learn that pretty doesn't necessarily mean useful. And programmers need to realize that just because their work is useful doesn't warrant that it's usable.
There's hope though. In time I've learned and now strive to make features as intuitive as possible. I now also favor very pretty, text-only, icons.
[...]and the current trend of "removing functionalities" is not always welcomed by developers...
In my not so humble opinion, graphic interfaces should be designed with the Pareto principle as a guideline (80-20 rule http://en.wikipedia.org/wiki/Pareto_principle). Is the feature useful? Yes. Will it be used often? No. Lets put it in the "nice to have" list.
If the application caters to a broad audience with varying levels of expertise and usage, it should present interfaces with varying degrees of complexity. I've seen this applied in real life successfully (e.g. in Ubuntu: dpkg >> apt >> aptitude >> Software Center). I definitely agree with you though, that too many software nowadays try to make things too easy without offering a way to go beyond the basics.
The designer should know enough to you visual symbols that have real-world equivalents to convey the meaning of the button visually. Envelopes for mail. phones for contact button. Thumbs up to like, thumbs down to dislike.
This is my first time learning about the open source project (never been on hacker news before). Can anyone provide a link to what you would call a typical open source project in need of a designer. I'm terrified of working with you guys but am starting to feel like maybe I should get over that and lend a hand.
And yes, too many people forget usability for prettiness.
VLC is usable (not all parts, true) but isn't beautiful.
She sent the photoshop source file and a png to the mailing list, but was told to send in a patch instead, which meant she had to learn how to use git to check out the repository, add the icon to the repo, and then generate a git patch. Only after that, she was told that they couldn't use the photoshop source file because they didn't have photoshop. Finally, one of the developers imported the file into the GIMP, changed some stuff on the icon without discussion, botched the output and then added that to the project. That was enough for her to not try doing something like this again.
1) try to lift the technical burden from the designer. If the designer sends a file as a mail attachment, just add it to a branch of your repo yourself (with permission, hopefully)
2) when programmers see a small bug in a piece of code, they often fix it. Don't assume you can and should do the same with designs. Talk to the designer.
Having communication barriers like this absolutely would stop me from participating. I have no problem with being asked to redesign a logo over and again. I would love to feel like I belonged to a community and that I mattered. But having a developer jack my work and screw it up because it was easier than asking me to do it would completely scare me away from open source projects.
This might be not as crazy as it sounds, as I recently learned:
A few weeks ago, there was a short presentation about Git, targeted at non-programmers such as graphics and web designers. After the presentation, one of the designers (who apparently already knew about Git) stood up and criticized the presenter for not going deeper into branches and auto-branching.
Of course, the presenter intentionally left that topic out, in order to not confuse all those Git newbies.
However, the designer argued that this is what would make Git interesting for designers. He said that all this diff/commit/push/pull stuff was boring for designers where a "diff" between graphics files is neither readable nor meaningful, and where automatic merges are impossible anyway. But branching has the power to reflect the natural work-flow of a designer who permanently goes back to previous versions in order to try different variants. Reflecting this via "Save as ..." (and naming files accordingly) is very cumbersome.
Although I personally think this guy overrated the power of branches, this might change once the Git user interfaces becomes simpler to use, more targeted to designers (rather than just software developers) and better integrated into graphical tools like Gimp, Inkscape or even Photoshop.
It would be great to have some type of easy non tech integration to git (github?) for designers to use.
Isn't that part of the "contract" of FOSS? You relinquish copyright of your contributions to the project as a whole. (I can see how this can bite designers who don't know much about the FOSS movement.) I suppose in this situation it's a good thing they use a version control system for designer contributions.
It certainly is bad practice to change something major with no discussion, but when you contribute something, expect it to be changed.
On the other hand, I’m not sure it’s fair to indict all open-source projects based on one side of a single story. I’d be interested to hear more of the details in this case; sometimes people walk away angry about simple misunderstandings and mixups.
That's called 'Copyright assignment' assignment and is not the norm in FOSS. You usually have to release your work under a suitable open source copyright licence, but you still retain ownership of the code.
Most of the large corporate sponsors of open source require copyright assignment. Most small one-man-on-guthub projects don't.
A designer's portfolio is based on visuals, which, if changed by someone other than the designer, no longer follows their intent and may not be representative of their design capabilities. While it may be contributed to the project, there is a definite need for those visuals to remain in a stable state for an extended period of time.
A developer's portfolio is based on projects, which typically either continue or stagnate, but do not vary enough from intent that their contribution is not discernable. Or, the contribution is to the project as a whole and that itself is the portfolio item.
It may sound like an ego trip, but this is a very real thing in the design world. You have to show your work, in production. It's one of the reasons I can no longer get a job as a designer - I've been a developer for too long and my past visual works are no longer used in production and I have nothing to show that I was actually ever a designer.
TLDR: It's not enough for the designer to say "I contributed to the project". They have to show visual proof because they are being hired or retained for their viewable work. A change in that design means it is no longer "their" work.
On our project, we've been working really hard to meet designers (and developers and users) where they are. Most of the time when someone asks how to contribute, we list the:
* Ideal way, easiest for us;
* Less ideal way, maybe a good middle ground;
* Difficult for us way, still possible, but likely to take longer to get incorporated;
It doesn't always work but it usually gives people a starting point. Also, on the plus side, it leaves little trails & tips all over the place on how they could contribute better.
My 0.02.
2. Make it discrete - What needs to be designed? The entire UI and workflows? The application icon? The internal navigation glyphs? Redesigning an entire app that has tens or hundreds of contributors can be daunting, but getting someone started with something small can be a gateway.
3. Leave it alone - One of the other commenters mentioned how a designer contributed something and then it was overwritten and ruined. Typically you don't want to have dozens of designers all working on a project unless there are fairly strict guidelines to work from. Have a working group at the beginning that can set the UI tone and create guidelines from that. Also a small review committee to review changes is smart, just as they do for code.
4. Version Control for Dummies - Put together a short explanation of how to use the version control system of choice, assuming no knowledge beyond Photoshop. Or find someone on the technical side who can be an intermediary/GIT trainer. The human part of this is very important.
Do those things and you should see prettier projects in the future. I know I'd love to get involved, but have no idea where to get started!
Lots of pretty mockups though.
Not to derail the conversation too much, but Inkscape also needs some improvement where UI is concerned, many things that should be easy are not.
Also, there are no standards for schools of design. There is no professional course that teaches the basics of ergonomics for the web the same way architectural web development can be taught. Most of the people like myself just follow a few major blogs.
I know many designers who would love to donate to open source projects.
There are schools that offer courses in interaction design. In addition many visual communication courses offer interaction design in addition to the usual print oriented design.
I think OSS in general could benefit from giving a designer such broad-brush authority over an entire ecosystem.
I feel like a second-class citizen around developers. And I don't want to venture in to the lions den. After all, I "just make things pretty", right?
I hate politics. Many open-source projects are a power-struggle with entrenched developers guarding against change.
Design is all about visual relationships. Making a change to one small aspect to the design effects everything else. This is very frustrating in an open-source environment, where parts of the design can be changed by the masses compromising the integrity of the whole.
Our industry doesn't appreciate it. Employers don't care what open-source projects we've contributed to. It's all about paying clients.
Thank you for giving me a jumping off point for one of the points I want to make (and please excuse the tirade, which has nothing to do with you).
I have a certificate in GIS. We were taught that a good map will be visually appealing in a way that makes other people comment on that appeal but a pretty map isn't necessarily a good map. A good map is one that present information effectively and efficiently. Doing this well gives you an attractive piece of work in the way some well-engineered thing has a certain visual appeal. In places where the GIS is done as a separate thing and is not properly integrated, the GIS department becomes a "map shop" and they become all about making pretty maps. And it's broken. It's a sign that something is very wrong.
Coders need to get over the idea that designers "just make things pretty". I saw an HGTV show where the stager talked about his goal of drawing people down the hall, past the icky kitchen and out to the amazing views of the main living area. That was the selling point but you had to get people to physically walk past and largely ignore less attractive features of the place. "First impressions" are big in real estate. So finding a means to get them to literally get past those items and get to the good thing was like making magic.
Coders need to understand that design is like that -- or good design is, at least. It can be. And it can add real value. And what I am not seeing in this discussion is where those two pieces meet -- where do the coders communicate their vision or design needs to the designer? I am not seeing that at all.
I think I have decent "taste" but I am not good at website design. I got free assistance from someone way more knowledgeable than I was. I got lots of free assistance for a time with every aspect of my websites from people who valued the content, never mind my many shortcomings. I had a falling out with the person who did the design work and we aren't friends anymore. I still give credit on my sites to their contribution. I try hard to thank anyone who has contributed.
I understand the idealism behind open source. And some stuff wouldn't be created any other way. But the tendency for open source/all volunteer stuff to be tainted with so much bitterness is part of why I am on HN and trying to figure out how to monetize what I do. I will monetize it or go do something else. People have benefited enormously from my unique understanding of some niche topics. People with extremely difficult problems who, in many cases, have been failed by all the paid experts they ever turned to. I don't know yet how to monetize it. To me, that is important. Other people get other types of benefit out of participating in various sorts of "free"/all volunteer projects/settings. Figure out what will benefit the designers. And if you do nothing else, thank them and give them credit. That goes a long way with a lot of people. If you can't figure out anything else to do, do at least that much. Be gracious about it. Being a dick is a good way to make sure people who gave just don't come back. And if you can't do that because you have grown bitter yourself, get the hell out of FOSS and do something you feel is more gratifying/satisfying. I stopped doing some of the stuff I used to do because I was bitter and everyone around me was way more bitter than I was. Downright bitchy and hostile in many cases. And I don't want to live that way. If I can't give it freely, graciously, and with an open heart, then you don't need me pissing in your cheerios. You can just go to Walmart or something and buy some piece of shit without the poison pill to go with it.
/soap box-rant-tirade thingy
In the UK at least, get designers get paid a lot less.
The work they do get paid to do is restrictive and dull.
Designers are generally driven by the desire to create and make 'pretty' things.
Most spend all day in meetings discussing why that shade of pink isn't good for the 99th design iteration of the same icon.
So I highly doubt they would rush to do this kind of work for free.
Most design work open source projects need are quite 'boring' from some designers point of view.
Many open source contributors don't find satisfaction in their day jobs.
The work they get paid to do is restrictive and dull.
Developers are generally driven by the desire to create 'cool' things.
Many spend all day in meetings discussing why that API extension isn't good for the 99th design iteration for customer X.
And yet many rush to do this kind of work for free.
Lots of work open source projects need are quite 'boring' from the technical point of view (documentation, project files, merging, OS integration. etc).
So why do people contribute to open source projects? Because they believe in the product and like feeling empowered.
Don't -ever- expect anyone to contribute for free. When they do, treat them special instead of taking them for granted.
That seems like common sense, but that's what I see all the time when it comes to programming projects, open source or not.
Right, but apply the same measure to developers too.
We often get into the habit of taking some contributor's work for granted, be we shouldn't. Every patch should be treated with the same respect and gratitude. If it's somebody's seven-hundredth patch, you don't have to say "thank you" for every patch, but you should still keep that humble attitude.
WINE's release emails always specified who did what, and that's not quite a 'thank you' but it's definitely more acknowledgement than I sometimes see.
It doesn't even have to be the project leader or other developers doing the praising. A proper bug reporting system will give the users a chance to give that praise as well, thought the leader/developers should also be thankful for the contributions.
It's not easy, and I'm not trying to say it is, but it needs more attention.
If you're developing software for somebody else, they're not paying you, and you're not getting any benefit whatsoever, that's entirely your fault. It's certainly not unfair though.
1. It exposes a programmer's code work for all to see. If it's bad, you get more than just critique. Others can point out what is wrong with the code but even better, they can correct the code or help you see what is wrong. If it's good or great, it makes for an amazing addition to any developers resume for hiring purposes.
The same can not be said of designers. Sure they can get feedback and people can often point out what's wrong, but these feedback are often more vague. Rarely do they get a walk through tutorial of how to do things better, actually having someone go in and show them how to fix their design flaw (something that happens a lot on the coding side). Pointing something out and having someone help you solve your design problem are not the same thing.
2. I don't know about others but to me, a designer benefits more from having their own portfolio rather than something that they may have contribute bits and pieces together for a project. As a designer, I don't see the value over my own portfolio which I can get enough critiques on without having to contribute to an open source project. As a developer, I see a need but think in terms of what designers benefit out of this. Open source designs are not the same as open source software in all cases. As an entrepreneur, I hire designers base on independent skill sets which is extremely hard to measure when people are co-designing small projects.
3. Just a comment but it would seem this is geared towards a developer who can't design and want open source designs but where is the benefit the designer is getting out of this. Surely there is a better argument. For the record, I'm not arguing that designers can't benefit at all. I just don't see it outweighing the benefits a developer would get in the same scenario.
Designing for a project requires a lead to a greater extent to keep the design consistent, whereas programming is more defined and concrete work: "This is wrong, fix it." If the issue no longer occurs after the patch is applied, work is done. Design work is more abstract in that sense.
The designer's benefit would defiantly be in having the project in their portfolio. Additionally I don't think too many projects need an entire design team, for most projects one would be sufficient increasing the portfolio value you are talking about. Most people contribute to projects they use, adding functionality they would like to have themselves. I'm sure that is something that would motivate designers too.
Why should I contribute to an open source project when I can do something like design a simple killer wordpress theme that may gain major adoption and use that as reference for my work than a single open source project catered to a single developers open source work that may or may not get used heavily. That or is only used in parts. There are tons of free designs out there, how often have you or anyone you know hiring designers reference how awesome or widely adopted their one off icon kit has been or something similar? Not happening.
I am a designer and a FLOSS guy and I have actually researched this subject a lot, both in practice, in writing and in teaching. The essay I written for Smashing Magazine a few months ago might be relevant in this context, it is called "The Case For Open-Source Design: Can Design By Committee Work?" http://www.smashingmagazine.com/2010/09/01/the-case-for-open...
I identified three major challenges: 1. Scratching an Itch 2. Granularity 3. Encoding/Decoding
I go through a few interesting positive examples for collaborative design processes and then try to propose some tips to making it work. Finally it's about a mix between leadership and openness, but this leadership has to be respected even if it does not translate to algorithmic metrics (like Google's A/B Testing of 41 shades of blue, more: http://stopdesign.com/archive/2009/03/20/goodbye-google.html)
If you prefer to go through this essay as a 20mins video presentation, you can check it here: http://vimeo.com/18761002
I start at 00:27:50
I realize this is a pretty long and complex answer for what sounds like a simple question, but in my experience this is really revealing the boundaries of the Open Source collaborative process as we know it and it will not change unless we help this model mature.
In the field I work in, designers and developers have equal standing, and need to create a middle ground of shared workflow, technology and design processes that balance development and design.
In most open source projects, there are too many barriers to entry (real or perceived) for designers to see themselves as participants. Everything from version control systems that don't provide any real benefit for visual designers to project leaders that see design as "eye candy" all reduce the appeal to designers.
Remember, too, that designers have loads of options if they want to work for free. You know all those "Build a Facebook clone over the weekend, it will look great on your resume" jobs on Craigslist? Designers get that kind of pitch ("Design us something for free; it will look great in your portfolio") constantly. Open source projects looking to recruit designers need convey some tangible benefit to participating.
In the design world, peer recognition doesn't come out of working on open source projects that their designer colleagues have never heard of. Every designer I know of will jump at the opportunity to do really great work, for free if necessary. Looking at the open source projects I'm familiar with, few of these look like the kinds of places where a designer would expect to create really great work.
Can you (or others) elaborate a bit more on what a place where a designer could expect to create really great work would look like? Is it more of a personal aesthetic thing (something that is personally interesting)? Is it related to some of the other points in this thread (unfriendly tools, gruff face to the community, lack of control etc.)?
* Projects should include screenshots or other visuals (no matter what their state of completion) on project pages. Browsing the usual Github page shows no visuals at all. Not every project is going to be heavily visually oriented, but most of the project pages I see look like a giant "Designers not wanted" sign.
* An environment where design can happen collaboratively. The "design thinking" ethos requires understanding what the problem is before trying to solve it. To really involve designers, some sort of sandbox where ideas can be expressed as something other than code, feature requests, bug fixes or "64x64px.png goes here." Would be ideal - a way to say "I see this working like this..." in a way a visual designer can express. Lots of discussion happens via chat, etc, but pretty hard to access if you're already feeling excluded.
* Something recognizable as a team structure. If projects need a designer, a project page noting an unfilled slot on the team would be ideal, along with some details. Icon designer? UX specialist? Copywriter? What do you need?
* Integrating rapid prototyping tools for design exploration. One of the tough tasks I find in interaction design is to get a feel for how a complex system is going to work without building it. I've see everything from Flash to Filemaker Pro used to build working models, to then be built out in another tool. Photoshop comps are great, but not a great way to simulate a lot of complex interaction models. If designers and developers are going to speak the same language, it's probably not going to be code.
I teach at a university of the visual arts, and I've often wondered about finding a way to engage students in open source projects, but to be honest, I've always been to fearful of what the outcome might be to really push this. My worry is that for a lot of developers, a logo and a few icons is all they are looking for. Fair enough, but not terribly attractive to the types of designers that projects really need.
Finally, designers need to understand what a big deal software is. You almost never see application design (web, desktop or mobile) represented in the big design award annuals, and the types of things that do get in tend to be gimmicky, Flash-driven web sites for consumer products.
For open source games, the same question could also be asked for music composers, and again most of the same answers apply.
It might better to ask why is it so easy to get coders to contribute.
General: http://fedoraproject.org/en/join-fedora
Specific Areas: https://fedoraproject.org/wiki/Join#Content_Writer https://fedoraproject.org/wiki/Join#Designer
One of the proposed long term goals (still going through the approval process) for the Fedora project is to lower the barrier of entry for new members (Not a great link but one of the better ones that I could find: https://fedoraproject.org/wiki/Meeting:Board_meeting_2010-12...)
DISCLOSURE: I do work for Red Hat on the Fedora project but my interest in open source is also personal. I suggested this because it seemed appropriate and I'm familiar with it.
I agree with what you are saying, I don't think it contradicts what I intended to articulate. I was trying to get across that dropping a modular piece of code such as say a Database system(Like MySQL) into a project gives you a huge chunk of functionality which you can then build on top of. I can't think of the equivalent for Art, except for widget sets or something along those lines. Or a grid/layout template that doesn't require you to then go and have to update any existing art to mesh well with the new art.
Now to be fair: you can come up with the equivalent of the MySQL situation where say you start the project with say a widget set and just match it's style moving forward.
I could probably match all my concrete coding examples with a modular art project but I think there are two issues that in general going to come up:
1) A lot Graphic Designers are not to strong at building modular art as it requires a more rigid process. There are exceptions of course, but we are talking about in general why there aren't as many Graphic Designers contributing to Open Source projects. (Wordpress though is a good example of where there are tonnes of Themes provided by Designers).
2) Reusing a popular Design can make your project look more derivate than unique. Where as with code this is less the case. Though with popular Widget sets such as the design by Sofa for Cappuccino (http://ajaxian.com/archives/cappuccino-07-aristo-ui-theme-en...) is a good example of Great design that maybe benefits from this familiarity as it's easier to grasp what widgets do when you've used other Apps using them.
IMHO, designers don't usually feel any importance of open-source projects because most of them/us are used to things that are aesthetically pleasing, and they would not want to burst their/our bubble. If they we're given a choice between free Linux (assuming Adobe Suite works on it) or OSX, they would be getting OSX because it suits to their world, they would be even paying extra if it was to cost more. Also, they want something that just works and don't really care whether they can see or edit the source, since their coding experience usually ends with HTML and CSS, hence the apathy.
I've worked with quite a broad range of websites and the less control I had over my work, the less I enjoyed it. Solution? If you're able to find a designer for your project, make him feel special by taking him as an equal member of the team and give him full control of the design side (aesthetics). More so, let him start from the scratch. Although, arguing about functionality (UI and UX), which has logic in it, should be encouraged, you don't want to offend him by saying his designs look bad, because a criticism coming from a programmer is as bad as it gets. Coder's blogs are usually coloured dark blue or green, that tells a lot. That's also the reasons why most designers hate working for Google. One hour meetings whether a line should be 1 or 2px thick? If you don't really like what he is doing, ditch him.
This shows that you respect their input and are inviting them as a peer to think about the project both visually and on a systems planning level.
I'd also recommend having a design lead who can bring on other designers as needed. The design lead should be responsible for making all design decisions and ensuring consistency. He should also be regularly communicating his decisions and reasoning to the community. (Mark Boulton did great working with the Drupal community, for example.)
When you give feedback to designers, try not to say "Take this out." or "Make this bigger. Or change this color." Tell them why (this is very important) you want something changed, and let the designer come up with a solution. And trust them to make the right one.
But don't ask them to whip together a "quick" mockup, that's considered spec work and is frowned upon in the design community. No design work is both "quick" and good.
Development is modular – pieces can be added, removed, or changed out for other pieces. Several developers can work on the same project at the same time and not step on each others' toes (esp. thanks to modern version control). This works great with the open source model.
Design, on the other hand, benefits from being unified and consistent. The best-designed projects have one designer, or a small group of designers working together closely. This doesn't work well with open source at all.
This becomes pretty obvious when you compare Mac systems to Linux systems.
Until this issue is resolved (by, eg, open source projects bringing on dedicated designers) the symptoms are unlikely to go away.
This is a pretty important point that gets overlooked. I think designers can help make something more intuitive and generally more readible but if we're talking about a cohesive person, it usually has to come from one person with a vision for the project.
Developers have rules. Code has syntax. Everyone follows the same rules and code comes out the same. One developer can pick up where another left off. It's very clean cut. Designers are different. There are "rules" of design, but each designer is different and have their own styles. That's not a bad thing, but when you get multiple (hundreds, even) of different developers with styles and no "strict" rules of design, it can make for a very hodge-podge project that...well...looks like 100 different people designed it
[Not a designer or developer but I work with both and serve as a "translator" between the two]
Designers are simply unable to work in committee as stated by others here...
But as far as I know, they don't do so. So we have a contradiction.
This means that, ideally, the design process comes before the coding process.
It can be very dispiriting for a designer to come into a project somewhere in the middle to find that major design decisions have been made and cannot be overturned. It is common, for instance, to find open-source UI that mimics the data structures of the code rather than the foibles of a human brain.
If a designer were to join an open source project they would be seen as "trying to change everything", "dumbing down" and "trying to take over". Which would, in a way, be true - and probably exactly what was needed.
I've often wondered if we designers could start open-source projects: start designing, publish & document our designs, release our work to the open-source community and wait to see if anyone bites.
I have seen this happen before and it was amazingly successful: Coverflow. Andrew Coulter Enright, a designer and artist, published a design for "how iTunes should work" on his website. Jonathan del Strother, a Mac developer, bit and published an implementation. Cover Flow was purchased by Apple Inc. in 2006.
I'd love to see something similar happen with a larger open-source app. Any designers out there want to join me in starting a site for exactly this kind of workflow?
http://en.wikipedia.org/wiki/Andrew_Coulter_Enright http://en.wikipedia.org/wiki/Cover_Flow
Now that I'm in deep, let me go further... A motivated programmer can learn the basics of interaction design very quickly, and get the user interface to a point where it at least doesn't suck.
The second thing would probably be, like others have said, just to ask -- and part of asking for help is making sure that you are able to actually receive the help. Perhaps partially because of the above, and also because i am not really a programmer (yet!), i have come to be hesitant to even try submitting anything. The process is too complex. I feel very uncomfortable with patches and pull requests and test cases, so please don't make me deal with them. Offer a 'dumbed down' way of submitting our contributions, or, perhaps, make somebody a liaison between people like me and people like your developers.
Large open-source projects in particular -- Firefox, GNOME, KDE -- are ones that i have the most interest in contributing to, but they have extremely high barriers of entry for people like me. (To a relative outsider it kind of seems like the design direction of these types of applications/suites is strictly controlled by some high-up cabal of developers, though, so perhaps that is intentional.)
edit: wording
Designers are always seeking for some projects to do even with no money return. There are several platforms that work based on this sharing skills principles, but often money based. Usually seen as a contest platform where the client requests and users (designers) responds buy uploading their work. Examples of this are Crowdspring www.crowdspring.com and in a smaller scale DesignRider www.designrider.com. Why not build a sharing platform like these for open-sources projects?
For a best results return, the briefing (instructions, guidelines, rules, project intention description, for instance) should be clear and precise. For instance, by specifying the format in which you want your design work will already scan designers skills and give you more to the point results. Of course, conversation is always welcome, a mailing list /forum in such platform to discuss and share knowledge between developers and designers cannot hurt either.
"Designers are scared of developers. Developers speak a foreign language, they are like aliens." Simon Hørup Eskildsen. I don't think is there such a big barrier between designers and programmers or developers. It is time to drop that assumption. A web based platform that gets both working on several open sources projects is a solution to consider and that might bring more responses that you can think of.
Whether a change comes in the form of code fixes, documentation improvement, refactoring, design changes, or infrastructural modifications, the burden of understanding the potential scope of damage and doing the actual work is always, always on the contributor. Convincing another to take on the work on their behalf is always a possibility, but it should not be hard to see why design changes proposed through such a channel will often be pushed to the back of the queue, unless for some dire need.
Designer or coder, there is no excuse for not doing due diligence in making sure a contribution is a good contribution.
Looking at the discussion so far, there appears to be at least some consensus that non-trivial effort above and beyond the (hopefully) expected hand-holding must be dedicated to designers in order for them to become good contributors. And, in corollary, the natural conclusion is that it's unrealistic to expect designers to put in the necessary effort to become good contributors on their own.
Following from the above, the more crucial questions, I think, are "How do we convince projects that they should go out of their way to attract designers", and, "Do you really need designers? Really, really, need them?"
The are two other things that programmers tend to do:
(1) we hate redundancy
(2) if something is obvious to a programmer, he thinks it is obvious to everyone else that that is the way it should be done (despite a simple survey of his peers revealing probably 4-6 different ways of achieving exactly the same result).
Programmers believe that their way is better than everyone else's and that it is intuitive as well (well, it was 'intuitive' to one guy on the team (ie me), and I'm 'smart' so that must be the best and most intuitive way of doing it, right?)
Unfortunately, good UI design has enormous amounts of redundancy built into it, and that if there is only one way of doing something, it is actually anti-intuitive. A design where the user can try 3 things out and the third one works will be hailed as a paragon of intuitiveness. One where it takes 10-20 tries to get the magic combination will be viewed as having a horrible UI.
There is also a relationship between how easy it is to do simple things and how the user perceives the UI. Programs which make it hard (ie go read a couple of hundred man pages in order to figure out the flags you need) even to do simple things are viewed as bad, even if it turns out that the same amount of difficulty can also achieve amazingly difficult things.
Basically what it boils down to is that in order to fix the design of an open source project, you would essentially have to fork it. And having forked it and fixed it, the high priests of the programmer cult will despise your efforts because there is too much redundancy.
Reading the thread here makes me realize that we're all so specialized--and this is a big part of the problem. UX designers need to learn to use a command line, need to learn to do at least some coding. Likewise, software engineers (including open source contributors) need to become more discerning about the basic principles of human-computer interaction and user interface design (not just visual styling). Once both roles start to become generalizing specialists, better collaborations will just happen.
Where are the open source designers? copywriters? information architects? interface designers?
http://thenerdary.net/articles/entry/the_open_source_designe...
Making it hard to contribute can be a barrier, but it's not the number one reason. Designers redesign apps, icons, and sites all the time just for fun, even if they know that their contributions have no chance whatsoever of being used.
Designers want to contribute to something that they care about, and the simple reality is that a majority of open source projects are made to appeal to developers, not designers.
In other words, if you want designers to contribute to your open source project, make it something that they will use and be passionate about.
So, when they called out for help to design their official website I jumped in and they gave me the opportunity to contribute with my design.
As a happy side effect, that design gave me a lot of exposition so I could finally left my dayjob as a print designer and start my career as a freelance web dev. It's fair to say that the link on CakePHP's footer brought food to my table for 4+ years.
One reason designers usually don't contribute to open source, is because they're paid to improve UX/UI on their commercial competitors. If GIMP/Inkscape had the same UX/UI as the Creative Suite, there wouldn't be market for the latter (this is what designers are paid for, unlike developers).
This allows more startup opportunities or companies like Canonical (parent company of Ubuntu) to provide a free and open source product (Canonical actually has dedicated designers).
Too often when I try open source software I see just a default list of options that really makes no sense, or I often see the developers trying to accommodate every need that might exist, resulting in overly complex user interfaces.
It takes someone (a designer usually) with knowledge of human interaction to know when a toolbar with multiple tabs works or when to keep it simple. Without doing this, designers are (in an overly simplistic description) just applying colors to existing boxes.
To get involved, Designers need a clear place to find projects to help on, and a clear way to help on projects -- as designers aren't about to open source code, install it on their own system and then begin work on the project.
I consider myself to pretty knowledgeable in the tech community and work as a full stack designer/developer, yet I have absolutely no clue where or how to get involved design-wise with any open source project. There's no "design" section on github or google code that I've ever seen :)
Obviously this isn't an absolute, and there are exceptions to this rule. The most important thing I can get across is this; End users do not, and will not, think like you do about your software (Read 10x). The reason you must get perspective outside your own is because yours is tainted beyond repair when looking at your own project.
So, what can you do to make your open source project more appealing to a designer?
1) Let go of preconceived bias when it comes to your UI / look-and-feel.
Someone more interested in the visual appearance and usability of your application is going to want to make changes to the workflow. Just as you test your code, test your design to make sure the designer's assumptions hold up. As a president once said, "Trust but verify."
2) Develop a clear understanding of where your designers implementation responsibilities end and yours begin (and vice versa).
Which is to say, know their limits, and know your own. If they don't know how to integrate their work into your project then either help them or find a third party that can. If you don't know how to integrate their work into your project then have them help or find a third party that can. Focus on your strengths. Nothing is more dissatisfying that seeing your work butchered.
3) Check the ego at the door/keyboard/whatever.
This applies to everyone involved in any way, shape, or form. Objectivity is the ideal, but lets be realistic. Personally I know more people who have had bad experiences volunteering / interacting with open sources projects than good (including myself). While this is anecdotal I think it's still important. Don't mistake popularity with success, and don't let popularity become validation for your lack of social skills. The people at the other end of your emails, IMs, IRC channels, etc are just that... people. The golden rule gets turned up to 11 when someone decides to take some of their free time and donate it to your cause.
This is hardly comprehensive, but I think it touches on a few points in ways I have yet to see in this thread. Keep doing your good work.
If a designer has created multiple layouts he could also make one for free to get people interested in the other "premium" ones, so its not that every design has to be a payed one.
As a developer, I've already helped a few opensource projects.
What's missing? A centralized location for designers to meet developers. github is unfortunately designer-unfriendly. It's developer oriented, and code-centric. Fixing github into having a design aspect will surely repair this.
I once tried to help out interpals.net. The usability of the site is non-existent, and the visual elements look like they were made by a four-year-old. Thus, I've come up with sketches and UI elements and gave it to the founder. He was amazed and seemed eager to work with me. At the end wanted someone more experienced. By that, he meant someone who can code, not only design. He wanted a developer. At the time I wasn't one.
Beggars can't be choosers. His site continues to be dead-ugly.
I really want to help anything because I need to exercise design as much as coding.
Just my humble, but designers, like programmers, can grow as their knowledge and experience encompasses more techniques. From drawing to composition to color theory to typography to XHTML to CSS to Javascript to PHP to Perl to ASP.NET/C# etc, et, al.
So what kind of designer were you looking for?
BTW, from a visual design point of view, the classic education is to first use a monospace typeface at a single size, then use other typefaces and multiple fonts and weights, then get to the fancy curves and Photoshop bullshit. But honestly if the designer couldn't make it work in Courier, they may want to consider another career.
So there you go. Did you want gratuitous eye candy or did you want a talented and educated artist who also knew booleans, conditionals and how to hit up a database?
Designers work in different environments: personal discussions, meetings, illustrator, photoshop, other web communities (like dribble and obscure sections at flickr).
If you ask a designer to add stuff to your repository, you're asking him to adapt to your way. Most designers aren't going to learn git.
To embrace designers means that you include them in your processes and tools. And let them in on strategic discussions - that's where good design is most often lacking in OSS.
If you continue with a Codeocracy where only check-ins are valued and the guy with 100k lines of written code is king, you're not going to convince many designers to help you with their free time.
It's easy to say that designers are needed, but anyone who has spent time in a design community of any kind would know that there are loads of designers out there that would love to get their stuff out there. I'd love to do design work for a decent open-source project while I get used to the code base to help with the development; I'm willing to bet that many others are in the same boat.
As a developer, you can contribute small patches, bits here and there or step in deeper and create new features or improvements within the current feature set.
As a designer, the bits and pieces option really is no option. Design can't be applied like that. It needs to be applied to the entire project in a consistent manner. Both visuals and user experience thinking. This makes it a far bigger commitment, something I imagine not everybody is willing to do.
I think the appeal of working on an OSS is that a developer gets to hone their skills and work collaboratively. It's a way to contribute (give back), to gain experience and to gain kudos.
I don't think the same collaborative aspect works as easily for design - because design problems are perhaps less easily worked on iteratively as a group.
UX, as a discipline, involves problems which can be solved collaboratively - and lends itself to team work. Design that's born from UX research tends to solve problems which have been more clearly defined from the outset.
If an OS project assigned a Creative Director, that may help lead the way for other designer to join a project.
Also, Source Forge and GutHub and the like aren't going to cut the mustard for Designers. There needs to be somewhere like them, but tailored for design.
I often use icons with GNU or CC licenses, for example. If only I could find a site with website designs like I can for icons (iconfinder.com, findicons.com) that would be great! I'd get a professional designer to use the open source design as a base and just tweak it.
Without these guidelines, it will be as tough to tell the designer what to do as it would explaining an obscure C++ error without any reference to C++.
