My girlfriend tried to design an icon for an open-source app she uses, but the experience hasn't been really great. I think the way developers in open-source projects communicate doesn't really work with designers.
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.
Yes, version control definitely seems like one of the biggest gaps. The communication between developers and designers have to improve, and the developers will have to realize they can't ask every designer for commits, but they can probably ask them for .zip files.
On the other hand, maybe we should make designers want to use Git.
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.
What Git really needs is a few tools like Versions and Cornerstone were for SVN: simple apps that didn't require any command line use at all. Git Tower might be there, but I haven't used it so I can't say that 100%.
Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git.
I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.
(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)
Most git actions don't need a deep understanding of Git nor a full GUI to function. I think git gui and gitx probably are enough to get a designer going.
Yes, I just picked up git for Windows, and it is atrociously unusable. Brutally atrocious. It's not like Windows is a popular operating system - git shouldn't support it as a first-class citizen. ;)
I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.
git gui works wells for me on Windows with msysgit. It's ugly, and there are a good number of small issues, but it definitely provides a reasonable user experience.
And of course, the command line option through msysgit is great.
Source control is also not part of a designer's natural workflow because the options aren't that great (usually backups on a NAS is all there is and a few proprietary snapshot plugins from Adobe. Kaleidoscope looks the most interesting). Also, svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai" when they want to backtrack or compare current "in the running" designs.
I'd love to see the OSS community develop better source control software targeted towards designers. :)
> svn branch numbers or git hashes don't make nearly as much sense to designers as "HiFi Mockup iPhone4 Right Aligned Inbox.ai"
That's what the commit comments are for.
BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)
Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.
What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?
And the most important thing: How to display that in a way to be easily understood by non-technical people?
For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.
"merge"
Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.
So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.
However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.
Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.
I don't think image comparison is the problem here. The problem is that designers works in rather different flows. To us a file can be many different states at once.
Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.
In other words the document have many states at once depending on what you make visible or not.
Git and similar tools are designed to track multiple revisions of a file. Imagine the history feature (undo/redo) from your favorite editor, but for saved files, and with the ability to point to two arbitrary versions and ask, "What changed between these?"
On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.
> 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.
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.
You’re missing the point. If an open-source project treated a programmer with the same lack of respect, I wouldn’t expect any different a response. There’s no “contract” that says I have to volunteer my time to someone who won’t even appreciate the donation.
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.
I understand what you're saying…but as an open-source contributor I certainly expect that my code can be modified for various reasons.
I guess a “work of art” would feel more personal, and (unless given a tight spec of elements that must be included) is more of a candidate for either rejection or admission as-is. For changes I'd certainly expect a request “can you add a wizard hat on the ninja?” rather than someone modifying it themselves.
That said, I don't think it's a one-way street (and good design is sorely lacking). The designers should have or take an interest in the general operating procedures just like they would for any paid work.
Actually the whole mentality that this was just a work of art is the problem.
When you do design for applications there are functional and conceptual components to the design. If people are taking your work and buggering up your intent, that's a problem, just the same way it is when someone takes code and alters its behavior without consideration for the code's intent.
The experience the designer had, and this conversation just belies the remaining gulf between the two groups.
I don't disagree, and I don't see why you think I'd consider it a good idea to muck about with things without understanding the intent – but the perception of the intent (and its fitness for purpose) can vary. A work of art, in the sense I was using it, could be “intent realized”. A piece in its final form.
I won't speak to this particular anecdote; I've found making judgements on intents based on a vague second-hand retelling of a one-sided account isn't useful. It sounds like communication was a total failure, probably on both sides.
Imagine you wrote a piece of code and then spent a couple of hours optimizing it to remove various bottlenecks etc etc.
You submit the patch, it sits there for a couple of days, then a designer (bear with me) comes along, takes a look, cuts out your optimisations to "simplify the code" and applies the patch.
Indeed, it's also a matter of actual vs imagined competency. What is the point of contributing to a project if someone with an outsized notion of their range of skills can come in and botch up previous work?
The issue is whether the person modifying or reiterating a work is competent to do so; We hear all about it with programming, but there is such a thing as "cargo cult design" too.
Also, I don't see it as whether a specific design contribution is "a work of art", with all its associated assumptions of involubility; in this context design is ever changing according to the evolution of a project.
I just noticed a patch I submitted a year ago was accepted this week. While the patch was sitting there gathering dust in bugzilla (or whatever), I was using my version locally and enjoying the benefits.
If I had designed and submitted a nice new icon instead of code, my experience would have been roughly the same.
Bottom line is that I didn't need to have my work accepted by anyone to validate my efforts. What I needed was to have the code run 20% faster for a rare use case; mine. And thanks to the project's authors choosing to go open source, that's what I got. Then, the authors accepted my patch, further lessening my work load by saving me from re-patching future versions.
So, do designers really get what 'open' implies? Would they enjoy being able to modify the splash screen for their own Eclipse install, even if nobody else would ever see it (they can btw)? I think having a headless mode is a much better feature than anything design-related ever could be. But that's me - other people want different things, and that is kind of the idea...
The other guy hit the nail on the head. Most developers aren't designers, and in fact they tend to think in ways that are the opposite of aesthetically pleasing. It's why there are so few developer/designers (I'm one of them).
The problem with design is that it is something that is not easy, but it SEEMS easy, because everyone has an opinion, and they think it's just as valid as anyone else's, even a professional designer. This isn't true. The people who designed the first 15 years of Linux interfaces should have never been allowed to design anything.
It's like the other guy said - if you optimized code and a designer came in and ripped out everything you did, rewrote it to be more "aesthetically pleasing", you would be pissed. If it happened twice, you'd throw a fit, and if it happened again you'd be done.
There needs to be a distinct process in place for contributing that doesn't include a programmer redesigning things before they get put into place. If the developer was competent to design, there would have been no need for the designer in the first place.
For you and ErrantX, I think you're reading too much into my parallel: I was just replying to a statement made in the parent. Obviously I'll expect that someone making changes to my code is qualified to do so. It's presumably parallel for interactions between multiple designers on the same project – one can make reasoned changes to the other's work.
In the described event, there clearly wasn't communication but we don't really know anything more about it.
Here's a question, though: let's say you're designing something, say a logo, and there's been a fairly clear idea/requirements laid out, there's some sort of a feedback loop etc. Do you at some point settle on a finished work that you'll offer up and that's it? Or if the client keeps asking you to add more ninjas and make that T red &c., will you acquiesce whether or not it works for you?
Edit: or if there's a second designer who has a slightly different idea of how the finished work should look, how is that resolved?
The designer's feedback loop compares the client's request to the initial design brief and the nascent work on the logo, branding, etc. If the requested changes contradict or diminish these, you kindly explain how...
In this potentially dicey scenario the ability to communicate with credibility is key; Everything we humans create has inherent connotations that can be interpreted and explained, and a designer should be able to justify how every mark on the page contributes to the experience of the end user.
Your "logo" example is too contrived. What is more typical is to get a design for something like a form, that has made no consideration for user interaction (space for error messages, error icons, disabling/enabling buttons, etc.) This is where user interface programmers really stand apart from everyone else... Their designs actually work.
I'm sorry if it's contrived (I felt it somewhat related to the anecdote above); what I was trying to get at is whether designers have a point where they can't further deviate from their vision without compromising it, even if requested to by a co-designer or the client.
You negotiate a price based on (x) number of designs and (x) number of modifications.
Otherwise the person will just keep draining you, because everyone thinks they can design, except they can't. So they dilute your work to the point that it's a terrible mess if you give them a chance.
"The problem with design is that it is something that is not easy, but it SEEMS easy, because everyone has an opinion, and they think it's just as valid as anyone else's, even a professional designer. "
No, the problem with design is that every designer has a different opinion, and believes that their opinion is 100% correct, and there is no sway room at all. It has to be done that way, or no one will come to the site, even though it is exactly opposite as every other designer, who also has such strong opinions.
Design is subjective, but designers really believe it is not, that is the most important thing ever, and do not listen to anyone else.
You must have been working on really shitty teams. Design is not merely subjective. It is measurable and in fact the subject of many A/B tests. Often involving designers. Who does not believe they got it right the first time, or they wouldn't be doing A/B testing.
Of course design is subjective, but my skill isn't operating photoshop. It's an understanding of the subjective forces in a way that I can interact with skillfully. Any random joe blow can have(and does) have an opinion, but it's not equal to mine. That said, there are definitely designers who are better than me, and who I would be in a similar position with.
The problem is that coders and the designers are in a different world.
If contributed code to a project, I'd expect another coder who knew what they were doing to change it.
But what happened is more as if someone contributed code and then, say, a tech writer changed so it wouldn't compile and then checked the code in.
I suspect it's not so much that a designer want to have their design never change. Rather, they want someone reasonably competent change it. The programmer often doesn't even know that they've "broken" the design by changing a few pixels.
but wait, it says the developer 'botched the output' -- shouldn't i be able to presume as a designer (who knows how to create proper output) that my contribution will not be botched by someone who may be a really fine coder, but lacks a good understanding of how to optimize images and deliver good output for the screen?
But how, as a design idiot armed with a recently downloaded copy of Gimp, do I tell whether or not my fine edit has "botched" your design or not?
Here we come to a fundamental problem of FOSS economics. There are three forces which protect the software from the work of well-meaning but clueless people:
A) Physical reality. The software has to work. If I take an ax to the internals of Apache it will quickly become apparent that I screwed up when the web pages don't load. There are automated tests. There are well-defined criteria for performance: specs, stopwatches, size of memory footprint, number of crashes in N hours.
B) Community. Patches don't get accepted without buy-in. If you make a mistake that is bad enough you won't get enough other hackers to sign on to your patch. It will get debated to death until you make the community happy.
C) Governance. In any FOSS community, all contributors are equal in the eyes of the gods, but in practice some contributors are more equal than others. If everyone but Linus Torvalds likes your patch, your patch still might not make it into Linux.
How do these map to design?
A) One problem with design is that, almost by definition, it is the part of development that can't be done by a machine. You can't write automated tests. You probably can't even define "wrong" in any objective manner. Trying to do so will drive your designers straight up a wall:
So to answer the question "hey, did my nifty new color scheme screw up the design?" you really have no choice but to ask a design team member. But:
B) The problem with design is that it doesn't scale well; it depends on a consistent vision and a consistent sense of taste. It is very hard to get more than three people on the same page here, and that's if they are trying to cooperate; mix in a saboteur and you are in big trouble.
So the right size for a design team is small. Small, and select: You need to earn your way onto the team. Add more members, or more voluminous input from nonmembers, and the team quickly spends more time bickering than building; if half those members are volunteers who have no experience and haven't read the style guide you are doomed to perpetual gridlock.
The established way to break this logjam is:
C) from the top. What color is the Ubuntu default theme? Ultimately, it is what Mark Shuttleworth wants it to be. And Shuttleworth has some taste, thank god.
Unfortunately, very few project leaders have taste - not just in FOSS but anywhere; this is why every piece of gear I own is gradually being replaced by a box with a little Apple logo on it. And if you are one of the rare people with excellent taste and the ability to lead a big technical project you probably have much more lucrative things to do than FOSS. Unless you are an idealist and independently wealthy, like, ahem, Mark Shuttleworth. There are precious few such people. It's a problem.
I can define "wrong": Wrong is using the square image stretched to fill a rectangular space, instead of using the rectangular image I provided. It's mis-aligning elements intended to be shown on a grid. Or attempting to convert that PNG with a complex alpha channel to a GIF.
You relinquish copyright of your contributions to the project as a whole.
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.
I agree, developers and designers must learn to communicate and work together. I dont think this problem only applies to open source, i think a lot of companys have the same problem internal.
It would be great to have some type of easy non tech integration to git (github?) for designers to use.
That experience sucks indeed. I guess there are two lessons to be learned:
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.
That really sucks. I'm sorry that she had such a poor experience.
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.
This would kill it for me. I've spent my whole adult life learning to use graphite and charcoal, oil paint and clay. Having my entire effort refused because I don't know what a GIT is just doesn't work for me.
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.
Because developers greatly benefit from participating in open source projects, designers usually don't. That said, developers also make more money than designers do and in a tech centric world, there are more needs for devs than designers. That's why.
For most OSS devs, the benefit is having a more interesting portfolio, especially skills they don't get to use in their day job. Wouldn't this work the same way for designers?
Not unfair at all. The vast majority of developers get paid for their time. It's only in Open Source that you see people volunteering their time with no hope of monetary reward. Even within that tiny minority, most of them are doing it for some form of compensation, even if it's just to get their name attached to something and build a reputation.
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.
> Don't -ever- expect anyone to contribute for free. When they do, treat them special instead of taking them for granted.
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.
While I don't think you should thank for them every patch directly, I think there should be praise for their work occasionally.
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.
Open source works great for developers for many reasons. On the flipside, rarely does it benefit a designer (although not always true).
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.
It's definitely easier for developers to contribute to open source projects, they can just dig into the code and easily contribute patches.
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.
I'm sorry but I strongly disagree (btw, I'm not the one that downvoted you; I don't have that option).
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.
Designers should contribute to projects they care about and use, adding the project to their portfolio should not be the sole reason to join the project. If you care only about portfolio, then designing a killer wordpress theme might be the way to go.
1. Ask for help - I'm a designer that reads HN everyday and I wouldn't know where to look if I wanted to participate in an open source project. Is there a list? The problem is most OS software aside from GIMP/Inkscape doesn't make its way in front of designers often.
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!
I remember the Haskell community actually sat down and had a community discussion about laying down design guidelines for the entire Haskell ecosystem (all packages should use so and so a color scheme, this is our logo, this is our font, etc.). I find Haskell sites almost always aesthetically pleasing, and it was probably due to conscious decision by the community to establish design standards.
I think OSS in general could benefit from giving a designer such broad-brush authority over an entire ecosystem.
They've had something going since at least February '07 (going by the refresh wiki edit history), but I don't see any sign that it's produced a tangible product.
I love the right-click interface in GIMP because it makes almost everything I need to do immediately available. But why on earth don't they sort and/or categorize the tool palette icons?
I have not really seen any evidence of GIMP being that poor of a UI. The biggest complaint is the multi-window interface for which single-window mode is currently in alpha and should be out in a few months or so.
It's a little clumsy if you're working with two images on one screen (especially when drawing/painting with references). A single-window interface has a menu option that lets you tile them.
I'll be happy when the single-window version is released.
There's a lot of duplication (Colors, Tools>Color Tools; Brush in Toolbox & as Dockable window), things that are out of place (View>Show Grid, Image>Configure Grid), common workflows that require more clicks than in other editors (Select-Copy-DeSelect-Paste), odd choice of defaults (When resizing canvas, choose "resize all layers" instead of "None"), and other odd design choices (Toolbox can't be a dockable window, Toolbox needs scrollbar if vertical Resolution<1024) that make GIMP occasionally frustrating to use, despite being an otherwise awesome tool.
Which is strange because any app that can operate on more than one document at the same time opens a separate window for each document on OS X. Even Photoshop. This works well on OS X because of how OS X manages applications. Let's for a moment consider GIMP if it was a native OS X application.
First, to switch between different applications, OS X just uses application switching whereas Windows and GNOME/KDE use window switching. IMO, window switching is a terrible design decision because it clutters the application switcher and the taskbar/dock and breaks operations that should logically apply to entire applications (quit, hide, Exposé etc.) Another desktop OS that uses application switching instead of window switching is Haiku (a BeOS descendant). Anyhow, if GIMP ran on OS X, you wouldn't need to sift through a bunch of separate windows when you wanted to focus on GIMP. You'd just switch to GIMP the application instead of separately bringing each of GIMPs eighty seven windows to the front first.
Second, when a document based application loses focus, OS X will hide all floating toolbars and panels and all you will see are your document windows. In Exposé, too, all floating panels and toolbars are hidden. This would mean GIMP's myriad tool windows would become invisible when you switched from the GIMP to another application, or when you viewed GIMP's windows in Exposé. No more needles visual clutter!
Third, OS X has a top menubar. This means each of GIMP's windows wouldn't need to have a separate menubar. The global menubar would enable and disable menu entries as you focused on different windows.
The biggest complaint is that things that should be easy and obvious are buried in counter-intuitive places. The second biggest complaint is that it looks really weird on Windows. The whole mutli-window vs singel-window is a minor argument in comparison.
On that note: I thought that Inkscape was really cool until I tried Blender. The UI experience for Blender is hundreds of times easier because many of the things that you have to do regularly (like scrolling back and forth) are shortcuts.
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.
Thanks for resolving that particular cognitive dissonance; I tried Blender once, then gave up in bewilderment after a few hours. I may have to give it another shot.
Sorry for not being clear. Blender is by no means an example of a superb UI. The learning curve is exceedingly high and even after hundreds of hours behind the controls there are many things I do not understand. Much of this is because the UI controls do not make sense. Of course, with the release of 2.5 there were some improvements, but it is still not that great.
That being said, one thing they did EXTREMELY well was put shortcut keys on all of the things that you do frequently. After doing Inkscape for a while I get really frustrated by the lack of easy navigation.
brilliant answer. Moreover, there is no GIT for designers made from the ground up (I'm envisioning a gui for past drafts).
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.
On the flip side: I'm a developer, and I have no idea how to even find designers, let alone try and get them to help out. If there is a list, I'd really like to find it.
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.
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.
As a designer I like your counterpoint. If I could work with developers like you're describing I'd be interested. I'm nervous about offering help to a project though, because I'm getting the impression that developers are expected to navigate the community solo and I don't know if I can learn the ropes of the community while making a good design for a project.
I've been thinking that maybe a buddy-system might be appropriate for attracting designers.
I think that's a brilliant idea. ABSOLUTELY brilliant. With a buddy, developers would be able to:
A: Get some greater insight into the reasons workflow is performed like it is.
B: Get some insulation from the "Here is the Github. Go, be fruitful" nature of a lot of projects.
C: Have someone assist with VC.
The developer would get:
A: Exposure to ideas about design
B: Experience in how to effectively communicate with developers
C: Experience in HCI and usability
You, sir, have given me an EXCELLENT IDEA. TO THE INTERWEBS!
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?
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.
I think you've hit the nail on the head with your final point. As programmers, you can point to your Github repo as your resume. In the design industry, they don't care about your Github repo (or will even understand it), and they'll bug you about some part of the program that you didn't even contribute to or were responsible for.
I've just heard about 37 signals this past month or two and am thinking about putting out a portfolio for them. Would they actually care about OS projects as a designer?
Sometimes, I think that the only way to integrate them into a FOSS project is to have one lead designer who has ownership over the design and to have the coders work with that.
Adding on others (lack of recognition/respect, very difficult to submit changes if you're not a dev, etc).
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).
They need control over the portion of the project they're working on, and these portions should be larger rather then smaller. There shouldn't be a committee trying to design something.
OK, I'll bite... The article states that the only way to improve the user experience is to bring in a Designer (loosely defined as somebody who doesn't code.) I'd argue the opposite: Having a programmer who really understands user interfaces and user interaction is the critical, missing piece.
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.
Replicatorblog's response made very good points. Though I think the FLOSS community should start by appreciating the huge differences between developing code and developing design.
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.
Thanks :)
I'm actually working with illustrator Galia Offri on another project along the same line as this thread. It is called Wikipedia Illustrated (http://WikipediaIllustrated.org) and is trying to address a similar question: "Illustrators, how do we get you guys to contribute to Wikipedia?"
I guess the first thing to do is to actually care about it to begin with. I have tried submitting suggestions for improving UIs (and even more trivial bug reports like some element is not centred properly or a text box is 1 px too tall) and it seems like many developers simply don't want to hear about it. They don't have an eye for it, they don't think about how other people might approach the interface, so it just doesn't bother them. They consider your criticisms and suggestions to be nit-picking or pedantry and they either get defensive or they just dismiss them outright. Even if they don't resent them, they often consider them to be so low-priority that they're not worth putting much effort into.
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.)
Make the project appealing to designers.
For instance let the application have themes/skins and have a marketplace where designers can sell their themes on their own.
That way designers dont have do deal with the developers and can work on a complete consistent design.
Wordpress and others are doing similar things.
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.
The same way you get developers to work on OSS -- have their high paying corporate job either order them to do it or ignore their participation in it during work hours.
Maybe it would be a good idea to put some donations together and actually hire designers on contract. That way, you are less likely to run into the problem of developers overwriting design changes willy-nilly, and you get a higher quality of design work that can last for several rounds of iterations.
Many reasons why this is hard.
1) UI design needs to be understood and implemented as a whole. This does not sound good for most of developers. I don't know why.
2) Of course, good UI designer (I wish I am) can create bite-sized chunks - divide UI plan into small parts that are more manageable from the development perspective. UI designer still has to be able to say what parts need to be there before the overall improvement is justified - in other words, when the resulting UI can be evaluated.
3) Developers have always an opinion what is good UI. Many features that make something very good to use for non-tech-people, or easy to learn, do not match into developer view of good UI.
4) Development environment tools, vocabulary and tools are not UI-designer friendly.
5) Dealing the above issues in daily work does not leave energy to have the same problems at free time.
I think that in order to critique design objectively, you need a set of standards and guidelines for design, like the Apple iOS Guidelines. These can be open-sourced themselves, and forked for various projects.
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++.
I would also like to point out that when the design is orthogonal to the development, there's lots of beneficial open source design out there.
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.
I am someone who has got a foot in both of these worlds. Though, I code slowly and I can't really draw either.
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.
I disagree with some of this. I think a designer should have the skin to take some criticism, even from a programmer. When my programmer co-founder critiques me, I sometimes think, "shit, I must've really screwed up for him to mention something." And yes, I do think it results in better work as long as there is justification. I think that generally, one cannot be too precious about aesthetics unless there is a clear vision with core principles.
I really wish I knew how to get great designers...
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...
This brings up the same recurring theme: lack of understanding or correct communication between the "art" and "science" departments. I am not an expert on the matter but two things I've noticed about a working designer-programmer workflow are:
* "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.
Great designers are in demand. Time is their most valuable asset, so in order to get a piece of this asset they must be offered a form of compensation. They clearly do not need to be designing for "would look great on your portfolio" nor they are likely to be enticed by the "gratitude of the masses". The only non-monetary compensation that works is to make them genuinely interested in helping -- and that if you think about it is the exact reason why devs give free time to open source projects. If it's not interesting, they leave.
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.
I would go so far to say you don't need a designer. You need someone who's passionate about multimedia applications and is working on a HCI project that relates very much with VLC. Someone who is thinking about future UIs, and things like that. (You need to give to this person, which likely is still non recognized, the biggest project recognition of his/her time).
Except for a few things (like the conversion feature, which is really hard for non-technical people), me, and those I know use it, find VLC pretty usable.
My problems with VLC go beyond the interface, but its hideous UI is a major reason why i don't use it (i'm on OS X). I have seen many many people online try to work around this problem, at least aesthetically, by skinning or editing NIBs or whatever -- have any VLC developers attempted to court those people? Have you considered just asking them if they'd be willing to help? Or if they would be OK with having their NIBs incorporated into the official project?
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.
OS X version of VLC is unmaintained, because the mac community doesn't care about it...
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...
> OS X version of VLC is unmaintained, because the mac community doesn't care about it...
Do you mean the Mac development community, or the Mac user community? Because based on my admittedly anecdotal research, i would say that the latter almost certainly do care. Why none of the developers have stepped forward, i don't know -- maybe they feel like their talents would be wasted given the past administration of the Mac client? Maybe they think it's a hopeless cause? Have the VLC team made it clear what sort of developer they're after? Do they want someone to just expose their functionality changes to the OS X version, or do they want someone to take charge of the OS X version, in the same way that Transmission's Mac UI team take charge of their OS X version?
> Editing a NIB and not making it open source, is near useless for the community...
Of course it is. But why do you think people do that? If they felt that the work they were doing anyway could influence the design direction of the official VLC project, wouldn't they jump at the idea? Almost certainly they would. They don't because they feel like no-one at VLC cares about their work. (And given that the OS X version is unmaintained, i guess that's true.) They don't know that they have the opportunity to use their talents to make more meaningful contributions to VLC.
> 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?
There is a well-known path for developers to submit their contributions. Everybody knows it, it's understood, it's easily accessible for people who do their sort of work. A designer is less familiar with these processes.
Not only that, but a designer can't implement their changes on their own. Any random developer can look up a bug on a tracker and write a self-contained patch that gets merged with the trunk and then boom it's fixed. That's not how interface design works. A random designer can submit mock-ups or image files to a bug tracker, but they require another person -- a developer -- to actually put their ideas into action. This is a much larger barrier to entry.
> Finally, about the transcode part, this is not a designing issue, but a usability issue...
It is not an aesthetic issue, no. But the work flow -- the steps you need to take to complete an action -- is another aspect of interface design.
I'm a interface designer and a VLC user. I'd love to help. How? Who's the key decision makers? If the interface needs alot of code to get right, will this be prioritized?
Providing forms of communication other than IRC and mailing lists (and issue trackers) is probably the first step towards getting designers participating.
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?
Much better. The VLC design on OSX has bugged me for a long time. In my opinion all the platforms should move towards the model where the only visible window by default is the player and the controls are temporary overlays over that player. One should always strive towards simplicity in design and optimize for the most used features. Most people will be using VLC to play one video at a time so including things like the video queue in the display by default is just time consuming and distracting.
P.S. Not just being a spoilsport here -- I do contribute to VLC, just through libavcodec.
I don't understand the move to one window. I don't think the confusion is due to two windows, but rather because your library window looks like a player by default.
There's a 90/10 rule - only put the stuff you use 90% of the time in the UI. The other 10% goes in the drop menu.
In the case of your mockup, I doubt people are EQing every movie they watch. They don't really use the library, so prev/next/loop/shuffle and lib are all unnecessary in a player view. I expect in most cases people use VLC to play a single video, something that a native player won't.
Further, your time display doesn't show total time - only position. Most players show current position and a total time/countdown toggle. The best include an end clock (i.e. your movie will finish @ 1:32am).
What new type of user are you trying to attract? Once you know that, it's pretty obvious what to do. Ping me if you wish to discuss (radley@ cloud.tv / vj.tv). I'm a big fan of VLC and build/design UI/UX & media players for a living...
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[...]
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.
|Most times, when I team up with some designer they'd want to make pretty icons...
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.
> I'm terrified of working with you guys but am starting to feel like maybe I should get over that and lend a hand.
You shouldn't be terrified.
My advice: start with a small open source team (not small project) on a project you like. Maybe do not start with your real name (it will be easy to change aftewards). Come on one IRC channel of a project ( like #videolan on freenode) and propose your services. See how people react.
If you like them, go on, if you don't, move along.
> 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).
The same question could be asked about documentation writers. Most of the reasons given here as to why it is hard to get designers apply to documentation writers, too.
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.
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.
Thanks -- I'm going to apply! I have always had a Linux flavor on dual-boot on my PC for learning and tinkering. I'm more about end-user and customization documentation rather than admin/install, but hopefully they can use me!
Reframe the question: How would you get designers to start open source projects? The open source world is pretty much structured around serving the needs of those who can code.
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.
That's an interesting question. I also wonder how you would get designers to start open source projects without getting the opposite of a "developer-centric" project where developers are the second class citizens.
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.)?
That a tough one - it's always easier to identify a problem than craft a solution. Here's a shot:
* 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.
Yeah, I know what you mean about solutions. Actually solving the problem at hand is a whole different world than finding the problem.
I know that I've been guilty of not making/updating screenshots very frequently - they tend to be a pain. Something to keep in mind for the future, though.
A collaborative design environment is a hard one. I've found it really useful for code in the past but as you said, that doesn't help a whole lot on the design front. The only practical thing I can think of at the moment is sending links to static images back and forth over chat, but that doesn't get over the barrier to entry on chat.
The only other things I can think of there would be screencasting (which usually costs money and tends to be a little more one-way) and VNC but that requires a lot more trust than I have for strangers (or than I would expect them to have for me).
Team structure might be a hard one. I can't speak for all developers but I generally don't like having a formal team structure if it can be avoided. Do you think that the role part is important or just discrete, specific tasks? If you were thinking of more of a control thing, that might be even harder. Unless I'm the only developer, I generally don't expect to have much control over a specific area. Then again, I also wouldn't expect people to be jerks and completely change something I did without at least talking about it first.
As far as rapid prototypes for web applications go, I LOVE wicket (http://wicket.apache.org/) because your templates are pretty much CSS and HTML (none of that pseudo-code in templates crap) and you have pretty much complete control over your javascript. You can mock up an entire site in HTML and only need minimal changes to get it working with backend code.
I don't have as much experience with desktop applications but I wonder if rough HTML/CSS might also work for the interactive parts. I'd have to think about that one and it might be an excuse to try mocking up a desktop app I've been thinking about.
I don't know if you'd be interested or if it would work, but I'd be up for at least talking about less uncertain ways to get your students involved in open source.
I have a couple of ideas for projects that I'd love to get design help on as long as I'm not completely left out of the design loop. Getting more people (and especially non-coders) involved in open source and helping in education would be bonuses.
250 comments
[ 3.6 ms ] story [ 323 ms ] threadShe 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.
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.
I use Git, and its a wonderful piece of software craft indeed, but it does not have Windows/Mac clients, that designers often use, as their base OS.
A decent usable frontend for Git, on platforms other than Linux too, needs to be developed, for it to be usable by designers.
Edit - I meant to say officially supported frontend and support for other oses by git.
Since the target group were designers, the presenter used a Mac, and tried to do everything using a GUI client for Git. I don't remember which one he used, but it ran natively on the Mac and it looked quite nice.
(Still, the presenter sometimes struggled with that GUI. He was obviously more used to the command line.)
GitX is available at https://github.com/brotherbard/gitx/downloads (Get the experimental branch)
Git Tower is available at http://www.git-tower.com/
Textmate has a GIT Bundle at https://github.com/jcf/git-tmbundle (It's quite good, but maybe not for designers).
And Giggle (http://live.gnome.org/giggle).
Windows is the only OS lacking a good client, but I use GitX for Mac every day, as do the less technical "devs" at our Startup.
I've been using the whatever default Windows port that is linked from Git's download page for several months bow and there is nothing atrocious about it. It works well and it does differ much from the Linux version. (edit) The command line version that is.
I use TortoiseHG and I expected parity.
Given that git was created for hosting the Linux kernel, it should be obvious why it's not a first-class citizen.
And of course, the command line option through msysgit is great.
Git Extensions (http://sourceforge.net/projects/gitextensions/) is actually really, really, good. The UI is well-designed and fast. Wish more people knew about it.
I'd love to see the OSS community develop better source control software targeted towards designers. :)
That's what the commit comments are for.
BTW, programmers also prefer reading commit comments, commit dates and author names. They don't read hashes. (Although they sometimes copy&paste them because they are short and unique.)
Both problems seem "hard but solvable" to me. Isn't there software doing that already?
Simple pixel-by-pixel "diffs" are of course possible, but only useful in trivial cases.
What if someone changed the color scheme (which affects almost all pixels)? What if someone moved some part of the image to another part? What about resolution/size changes and multiple layers? What about vector graphics?
And the most important thing: How to display that in a way to be easily understood by non-technical people?
For hard-core techies, there is of course the option to use a text-based image format. For raster graphics, the "plain" variants of PNM come to mind. For vector graphics, SVG or EPS might be good choices. Then, a good (indention-aware) textual diff should produce sensible results - especially if only details were changed.
"merge"
Automatic merges are only useful if they aren't too "clever". That's important for text and especially important for graphics.
So if two distinct areas of an image are edited, a simple merge can and will work. But overlapping changes or even global changes should always result in a conflict.
However, if only trivial merges are desirable, most changes will cause conflicts, which would be not much different from the current situation.
Also, that kind of merges will already happen automatically with the current (text) merge anyway, provided that formats like PNM, SVG and EPS are used.
http://www.kaleidoscopeapp.com/
Too bad it's not Free Software ...
Kind of like a developer would have 10KLOC but be commenting the 8K of them in and out all the time.
In other words the document have many states at once depending on what you make visible or not.
On top of this, Git added the ability to merge changes together automatically. Imagine that one person changed a bunch of stuff in the first paragraph in a document, and someone else changed a bunch of stuff in the second paragraph, and the computer could automatically merge those changes into one document.
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.
I guess a “work of art” would feel more personal, and (unless given a tight spec of elements that must be included) is more of a candidate for either rejection or admission as-is. For changes I'd certainly expect a request “can you add a wizard hat on the ninja?” rather than someone modifying it themselves.
That said, I don't think it's a one-way street (and good design is sorely lacking). The designers should have or take an interest in the general operating procedures just like they would for any paid work.
When you do design for applications there are functional and conceptual components to the design. If people are taking your work and buggering up your intent, that's a problem, just the same way it is when someone takes code and alters its behavior without consideration for the code's intent.
The experience the designer had, and this conversation just belies the remaining gulf between the two groups.
I won't speak to this particular anecdote; I've found making judgements on intents based on a vague second-hand retelling of a one-sided account isn't useful. It sounds like communication was a total failure, probably on both sides.
Imagine you wrote a piece of code and then spent a couple of hours optimizing it to remove various bottlenecks etc etc.
You submit the patch, it sits there for a couple of days, then a designer (bear with me) comes along, takes a look, cuts out your optimisations to "simplify the code" and applies the patch.
You'd feel pretty rejected.
The issue is whether the person modifying or reiterating a work is competent to do so; We hear all about it with programming, but there is such a thing as "cargo cult design" too.
Also, I don't see it as whether a specific design contribution is "a work of art", with all its associated assumptions of involubility; in this context design is ever changing according to the evolution of a project.
If I had designed and submitted a nice new icon instead of code, my experience would have been roughly the same.
Bottom line is that I didn't need to have my work accepted by anyone to validate my efforts. What I needed was to have the code run 20% faster for a rare use case; mine. And thanks to the project's authors choosing to go open source, that's what I got. Then, the authors accepted my patch, further lessening my work load by saving me from re-patching future versions.
So, do designers really get what 'open' implies? Would they enjoy being able to modify the splash screen for their own Eclipse install, even if nobody else would ever see it (they can btw)? I think having a headless mode is a much better feature than anything design-related ever could be. But that's me - other people want different things, and that is kind of the idea...
Also, obviously better 'things' (code, design, whatever) will sometimes take forever for no reason at all. Like this, for instance (the couchdb-python the logo is terrible): http://code.google.com/p/couchdb-python/issues/detail?id=126
Just remember not to worry: things tend to work out OK.
The problem with design is that it is something that is not easy, but it SEEMS easy, because everyone has an opinion, and they think it's just as valid as anyone else's, even a professional designer. This isn't true. The people who designed the first 15 years of Linux interfaces should have never been allowed to design anything.
It's like the other guy said - if you optimized code and a designer came in and ripped out everything you did, rewrote it to be more "aesthetically pleasing", you would be pissed. If it happened twice, you'd throw a fit, and if it happened again you'd be done.
There needs to be a distinct process in place for contributing that doesn't include a programmer redesigning things before they get put into place. If the developer was competent to design, there would have been no need for the designer in the first place.
In the described event, there clearly wasn't communication but we don't really know anything more about it.
Here's a question, though: let's say you're designing something, say a logo, and there's been a fairly clear idea/requirements laid out, there's some sort of a feedback loop etc. Do you at some point settle on a finished work that you'll offer up and that's it? Or if the client keeps asking you to add more ninjas and make that T red &c., will you acquiesce whether or not it works for you?
Edit: or if there's a second designer who has a slightly different idea of how the finished work should look, how is that resolved?
In this potentially dicey scenario the ability to communicate with credibility is key; Everything we humans create has inherent connotations that can be interpreted and explained, and a designer should be able to justify how every mark on the page contributes to the experience of the end user.
Otherwise the person will just keep draining you, because everyone thinks they can design, except they can't. So they dilute your work to the point that it's a terrible mess if you give them a chance.
No, the problem with design is that every designer has a different opinion, and believes that their opinion is 100% correct, and there is no sway room at all. It has to be done that way, or no one will come to the site, even though it is exactly opposite as every other designer, who also has such strong opinions.
Design is subjective, but designers really believe it is not, that is the most important thing ever, and do not listen to anyone else.
If contributed code to a project, I'd expect another coder who knew what they were doing to change it.
But what happened is more as if someone contributed code and then, say, a tech writer changed so it wouldn't compile and then checked the code in.
I suspect it's not so much that a designer want to have their design never change. Rather, they want someone reasonably competent change it. The programmer often doesn't even know that they've "broken" the design by changing a few pixels.
Here we come to a fundamental problem of FOSS economics. There are three forces which protect the software from the work of well-meaning but clueless people:
A) Physical reality. The software has to work. If I take an ax to the internals of Apache it will quickly become apparent that I screwed up when the web pages don't load. There are automated tests. There are well-defined criteria for performance: specs, stopwatches, size of memory footprint, number of crashes in N hours.
B) Community. Patches don't get accepted without buy-in. If you make a mistake that is bad enough you won't get enough other hackers to sign on to your patch. It will get debated to death until you make the community happy.
C) Governance. In any FOSS community, all contributors are equal in the eyes of the gods, but in practice some contributors are more equal than others. If everyone but Linus Torvalds likes your patch, your patch still might not make it into Linux.
How do these map to design?
A) One problem with design is that, almost by definition, it is the part of development that can't be done by a machine. You can't write automated tests. You probably can't even define "wrong" in any objective manner. Trying to do so will drive your designers straight up a wall:
http://stopdesign.com/archive/2009/03/20/goodbye-google.html
So to answer the question "hey, did my nifty new color scheme screw up the design?" you really have no choice but to ask a design team member. But:
B) The problem with design is that it doesn't scale well; it depends on a consistent vision and a consistent sense of taste. It is very hard to get more than three people on the same page here, and that's if they are trying to cooperate; mix in a saboteur and you are in big trouble.
So the right size for a design team is small. Small, and select: You need to earn your way onto the team. Add more members, or more voluminous input from nonmembers, and the team quickly spends more time bickering than building; if half those members are volunteers who have no experience and haven't read the style guide you are doomed to perpetual gridlock.
The established way to break this logjam is:
C) from the top. What color is the Ubuntu default theme? Ultimately, it is what Mark Shuttleworth wants it to be. And Shuttleworth has some taste, thank god.
Unfortunately, very few project leaders have taste - not just in FOSS but anywhere; this is why every piece of gear I own is gradually being replaced by a box with a little Apple logo on it. And if you are one of the rare people with excellent taste and the ability to lead a big technical project you probably have much more lucrative things to do than FOSS. Unless you are an idealist and independently wealthy, like, ahem, Mark Shuttleworth. There are precious few such people. It's a problem.
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.
It would be great to have some type of easy non tech integration to git (github?) for designers to use.
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.
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.
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.
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.
Just in this context of getting people to 'contribute', we're explicitly referring to projects where the developers do not get paid.
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.
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.
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.
WordPress is designed to easily accept design products like themes.
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!
I think OSS in general could benefit from giving a designer such broad-brush authority over an entire ecosystem.
Lots of pretty mockups though.
I'll be happy when the single-window version is released.
window management should be handled by the window manager, not by each application.
First, to switch between different applications, OS X just uses application switching whereas Windows and GNOME/KDE use window switching. IMO, window switching is a terrible design decision because it clutters the application switcher and the taskbar/dock and breaks operations that should logically apply to entire applications (quit, hide, Exposé etc.) Another desktop OS that uses application switching instead of window switching is Haiku (a BeOS descendant). Anyhow, if GIMP ran on OS X, you wouldn't need to sift through a bunch of separate windows when you wanted to focus on GIMP. You'd just switch to GIMP the application instead of separately bringing each of GIMPs eighty seven windows to the front first.
Second, when a document based application loses focus, OS X will hide all floating toolbars and panels and all you will see are your document windows. In Exposé, too, all floating panels and toolbars are hidden. This would mean GIMP's myriad tool windows would become invisible when you switched from the GIMP to another application, or when you viewed GIMP's windows in Exposé. No more needles visual clutter!
Third, OS X has a top menubar. This means each of GIMP's windows wouldn't need to have a separate menubar. The global menubar would enable and disable menu entries as you focused on different windows.
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.
Granted it's fantastic once you know how to use it, but good luck with that.
That being said, one thing they did EXTREMELY well was put shortcut keys on all of the things that you do frequently. After doing Inkscape for a while I get really frustrated by the lack of easy navigation.
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 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.
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.
I've been thinking that maybe a buddy-system might be appropriate for attracting designers.
A: Get some greater insight into the reasons workflow is performed like it is. B: Get some insulation from the "Here is the Github. Go, be fruitful" nature of a lot of projects. C: Have someone assist with VC.
The developer would get:
A: Exposure to ideas about design B: Experience in how to effectively communicate with developers C: Experience in HCI and usability
You, sir, have given me an EXCELLENT IDEA. TO THE INTERWEBS!
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
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).
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.
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.
Where are the open source designers? copywriters? information architects? interface designers?
http://thenerdary.net/articles/entry/the_open_source_designe...
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
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.
Designers are simply unable to work in committee as stated by others here...
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++.
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.
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.
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
* "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.
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
Except for a few things (like the conversion feature, which is really hard for non-technical people), me, and those I know use it, find VLC pretty usable.
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...
Do you mean the Mac development community, or the Mac user community? Because based on my admittedly anecdotal research, i would say that the latter almost certainly do care. Why none of the developers have stepped forward, i don't know -- maybe they feel like their talents would be wasted given the past administration of the Mac client? Maybe they think it's a hopeless cause? Have the VLC team made it clear what sort of developer they're after? Do they want someone to just expose their functionality changes to the OS X version, or do they want someone to take charge of the OS X version, in the same way that Transmission's Mac UI team take charge of their OS X version?
> Editing a NIB and not making it open source, is near useless for the community...
Of course it is. But why do you think people do that? If they felt that the work they were doing anyway could influence the design direction of the official VLC project, wouldn't they jump at the idea? Almost certainly they would. They don't because they feel like no-one at VLC cares about their work. (And given that the OS X version is unmaintained, i guess that's true.) They don't know that they have the opportunity to use their talents to make more meaningful contributions to VLC.
> 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?
There is a well-known path for developers to submit their contributions. Everybody knows it, it's understood, it's easily accessible for people who do their sort of work. A designer is less familiar with these processes.
Not only that, but a designer can't implement their changes on their own. Any random developer can look up a bug on a tracker and write a self-contained patch that gets merged with the trunk and then boom it's fixed. That's not how interface design works. A random designer can submit mock-ups or image files to a bug tracker, but they require another person -- a developer -- to actually put their ideas into action. This is a much larger barrier to entry.
> Finally, about the transcode part, this is not a designing issue, but a usability issue...
It is not an aesthetic issue, no. But the work flow -- the steps you need to take to complete an action -- is another aspect of interface design.
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.
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
P.S. Not just being a spoilsport here -- I do contribute to VLC, just through libavcodec.
There's a 90/10 rule - only put the stuff you use 90% of the time in the UI. The other 10% goes in the drop menu.
In the case of your mockup, I doubt people are EQing every movie they watch. They don't really use the library, so prev/next/loop/shuffle and lib are all unnecessary in a player view. I expect in most cases people use VLC to play a single video, something that a native player won't.
Further, your time display doesn't show total time - only position. Most players show current position and a total time/countdown toggle. The best include an end clock (i.e. your movie will finish @ 1:32am).
What new type of user are you trying to attract? Once you know that, it's pretty obvious what to do. Ping me if you wish to discuss (radley@ cloud.tv / vj.tv). I'm a big fan of VLC and build/design UI/UX & media players for a living...
(Except maybe the fact that the playlist's default setting always goes back to "shuffle" for some reason.)
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.
You shouldn't be terrified.
My advice: start with a small open source team (not small project) on a project you like. Maybe do not start with your real name (it will be easy to change aftewards). Come on one IRC channel of a project ( like #videolan on freenode) and propose your services. See how people react. If you like them, go on, if you don't, move along.
VideoLAN makes VLC. VLC is one of the best video players in existence, it's also fairly ugly.
Those are some great points, they're discussed in this book: http://producingoss.com/en/communications.html#writing-tone
And yes, too many people forget usability for prettiness.
VLC is usable (not all parts, true) but isn't beautiful.
But as far as I know, they don't do so. So we have a contradiction.
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.
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.
I know that I've been guilty of not making/updating screenshots very frequently - they tend to be a pain. Something to keep in mind for the future, though.
A collaborative design environment is a hard one. I've found it really useful for code in the past but as you said, that doesn't help a whole lot on the design front. The only practical thing I can think of at the moment is sending links to static images back and forth over chat, but that doesn't get over the barrier to entry on chat.
The only other things I can think of there would be screencasting (which usually costs money and tends to be a little more one-way) and VNC but that requires a lot more trust than I have for strangers (or than I would expect them to have for me).
Team structure might be a hard one. I can't speak for all developers but I generally don't like having a formal team structure if it can be avoided. Do you think that the role part is important or just discrete, specific tasks? If you were thinking of more of a control thing, that might be even harder. Unless I'm the only developer, I generally don't expect to have much control over a specific area. Then again, I also wouldn't expect people to be jerks and completely change something I did without at least talking about it first.
As far as rapid prototypes for web applications go, I LOVE wicket (http://wicket.apache.org/) because your templates are pretty much CSS and HTML (none of that pseudo-code in templates crap) and you have pretty much complete control over your javascript. You can mock up an entire site in HTML and only need minimal changes to get it working with backend code.
I don't have as much experience with desktop applications but I wonder if rough HTML/CSS might also work for the interactive parts. I'd have to think about that one and it might be an excuse to try mocking up a desktop app I've been thinking about.
I don't know if you'd be interested or if it would work, but I'd be up for at least talking about less uncertain ways to get your students involved in open source.
I have a couple of ideas for projects that I'd love to get design help on as long as I'm not completely left out of the design loop. Getting more people (and especially non-coders) involved in open source and helping in education would be bonuses.