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.
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.
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.
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.
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.)
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.
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.
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%.
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.
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.
> 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.
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...
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.
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?
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.
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.
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.
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.
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.
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.
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.