A lot has been said in the last couple of years about HCI and UI design in free software, most of it damning.

While such criticism has basis in fact, it has usually been written from the designer's side. The purpose of this article is to explain the way I, see things, which is, of course, different.

First, since this is my perspective, let me explain you where I come from.

I am an amateur. I enjoy programming. That's what amateur means.
In a scale of programming productivity, 0 being no code, 9 being Torben Weis in 1997, I am a 4 at best.
In a scale of programming knowledge, 0 being a lawyer, 9 being Donald Knuth, I am maybe a 3.
In a scale of programming skill (ie: producing pretty code), 0 being dada poetry, 8 being Matthias Ettrich, I am a solid 2.5.

So, why would my opinion be worth it? Well, let's put it this way, those who have a greater magnitude in their programming vector [1] are probably not going to bother writing something like this, because they are busy, and they assume it's obvious [2].

My theory is that basically two groups of well meaning people are talking past each other and driving both groups mad in the process.

So, with that out of the way, let's get down to business.

The UI designer's case, as well as I understand it:

Free software's UI design is poor, because it doesn't follow modern or adequate UI design guidelines.

In other words, because the UI is not designed by skilled UI designers, but by skilled developers.
Since UI design has to be implemented in code somewhere, the coder should follow the designer's instructions without arguing (at least not much), because it isn't practtical to argue everything, specially since the designer has a core of knowledge on the issue the coder lacks.
When a UI designer tries to redesign such UI, or post an article explaining the issues he finds, he usually is ignored or flamed.
Usually, this will lead to said designer either growing increasingly bitter, or make him decide that free software coders just don't get it. In both cases, usually the designer goes away, or becomes a heckler.

As far as I can see, that reasoning is 100% correct.

The coder's case, as well as I understand it:

Writing free software is an incredible amount of work, usually for no material gain.
A program with a poor UI is better than no program at all.
A program can be hard to use and still be better than an easy one [3].
Being told what to do is no fun.
So, when someone tries to tell the coder what to do, he usually snaps a little, or ignores the noise, and continues to produce his suboptimal-interface programs.

And, of course, that reasoning iss 100% correct as well.

So, what?

In the famous words, what we have here is a failure to communicate. As well as two groups of people with larger than average egos.

The coders have large egos because they create stuff out of nothing. That does that to you. I know it.

The designers have large egos because they usually see other people implement what they think. It's almost the same syndrome.

So, how can we get around this? I will just say what I think, I am probably coder-biased, although I am trying to be fair. So, if you disagree, just comment, and try to be civil.

On the coder's side

We don't know as much about UI design as the designers. It's true, live with it. At least for good designers. We only have empirical data, they studied the issue. Respect that. We are not lawyers, accountants, and we are not designers.
Accepted industry practice is usually right. So, don't try to get too creative on UI. Bland is good.
When a designer tells you about what's wrong in your UI, it's not personal. If he's being polite, try to engage him in constructive argument. If he is not, then all bets are off, of course ;-) Sometimes simple changes do a lot. Ask him to help you fix the easy parts first.
UI improvement will make your app better.

On the designer's side

You are a latecomer. The app has a history, the UI probably reflects some internal stuff that can't be changed. So, don't expect that you can change everything. Try the small stuff first.
There is a big emotional investment in the application. I know it's not personal, but please, be extremely polite and careful! This has to be emphasized: you will spend maybe 40 hours checking the app, the guy who wrote it may have spent 4000.

Don't put down his work, make it better! Be positive! say "the app is nice, but if this was changed to that, it would be better"
Fundament. remember the coder is not a designer. He lacks a core of knowledge you have. On commercial code, that doesn't matter because management says they ahve to follow your guidelines. Here, you should give references, however broad to accepted industry practice whenever you can.

"Hey that's bad" is bad. "What you do there is bad because it doesn't follow principle X" is better.
You don't know as much about coding as the coder. Even if you know how to code, you know little about this code. Respect that. You are not a lawyer or accountant and you are not a coder.
Start small. Suggest simple fixes, not huge overhauls. Gradualism is good. Sometimes changes that would provide a better UI would make the code much worse, and that will hurt the app's value.
Get involved. If it's a KDE or Qt-based app, learn designer, get the .ui files, and try to hack it to look and work better without changing the elements. then you can try to produce a btter design with fewer or different elements. That will be only a mockup, but it can explain your point of view better than words.

In a future, perhaps you can help from the beginning of the app, instead of joining late. Since the designer work is less time intensive, you could be UI designer for a dozen apps, while a coder hardly has more than three projects.
Be patient. The other guy has worked on that thing for five years, you can wait a couple of months for him to follow your leads. Read a book in the meantime!
Don't be bossy. You are not his boss. You are his helper.

In the commercial world, the designer rules. Here the coder rules, because you lack means of coercion. Not even stuff like "noone will use that UI" works. [4] If he goes away, who's going to implement your stuff?

Other related issues

It has been said that the reason why the dog wags the tail is because the dog's smarter. That's only part of the truth. The other part is that the dog has about 50 times the mass of the tail.

In the free software world, developers outnumber designers probably by three orders of magnitude. So, designers sometimes feel a need to be shrill in order to be heard. While comprehensible, it's not something that will lead where you want to go. Developers can be as shrill as anyone you know.

On the other hand, coders perceive designers as bossy, and tend to dismiss them as unproductive fuzzy artsy types. While understandable, it's stupid. They are skilled in other ways than us, and are worthy. In fact, because of the rarity of the free-software-involved designer, they are to be cared for.

Coders tend to see some designer suggestions as simple because they are easy to implement. How important can it be if it only takes changing a constant? Well, if it's so easy, why not do it?

Designers tend to see some coders reticence to change as stubborness. Why doesn't he change that constant? Well, have you told him why he should? And no, "because I say so and I am a designer" is not good enough.

Now, all this article sounds suspiciously like "why can't we all just get along?", and that's partly true. However, why can't we? really? I think I mentioned some of the reasons. Hopefully we can.

[1]	Nerdy way of saying: better programmers

[2]	One of the most annoying habits of programmers is overestimating other people's knowledge of their mental process. It's because they understand themselves.

[3]	The reason why a designer usually disagrees with that is pretty simple, they define better in different ways.

[4]	I am the happy author of 4 apps that have no users whatsoever beyond me. Happy as a clam!