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.
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.