Monday, December 12, 2005

The Tyranny of The Developers

I was recently involved in a discussion on kde-devel mailinglist. Somehow the discussion turned in to discussion about place of the developers and others in designing the overall system. One specific quote is quite telling of the situation:

"Coders may be just one of the groups but, whether you, me or whoever else like it or not, they are the most important. Anybody can make suggestions, but only coders can make most of them reality. This, together with the fact that a project always has coders and the fact that coders may have to do even other things because the project may not have enough other groups, may be a reason for the second fiddle situation."

(said by Lubos Lunak, in my comment about other people (UI-experts, documenters, artists etc.) playing "second fiddle" when compared to coders).

Are the coders most important? True, they are the ones that write the actual code. But does that fact mean that they are most important? If anything, it merely means that they are the gatekeeppers. Everything that goes to the overall system must go through them. Usability-experts are rarely good at coding, so they have to rely on coders to implement the stuff. And if the coders disagree with the usability-experts, they could refuse to implement the suggestions. Only thing that the UI-people can make is to make "suggestions".

This situation is made worse by the fact that many times the developers think that they ARE usability-experts. 98% of the time, they are not. And even if they did know something about usability, their opinions would be colored by their background. So their ideal UI would be good for developers, but less ideal for other people. You can actually see this in KDE. Developers are power-users, and UI in KDE is targetted towards power-users.

Again: are the coders most important? Would Mac OS be as loved and successfull as it is if it just had good code, with zero usability? In the overall design of the system, usability is very important.

I think this one particular area is a weakness on Open Source. Apple, Microsoft and others can employ usability-experts that design the system as usable as possible. They also have paid coders that can be told "here, implement this", and they will do it. How does that work in open source? We have usability-people designing the UI. But their suggestions have to go through the developers, and if developers disagree with their suggestions, they will not be implemented. End-result will look something that the developer agrees with, and not like something that was designed by usability-experts.

In short: people who are not experts in that specific field are the ones making decisions about it. Open source is said to be a meritocracy. And it is that, as far as code is concerned. But designing a modern GUI takes a lot more than just code. And in case of usability, that meritocracy does not happen, since the people making the decisions are not the best people to make them. As we speak, we have coders making decision about code. And they are the best people doing it. But we also have coders making decisions about usability, with usability-experts making "suggestions". Does anyone see the problem here?

In an ideal world, we would have a GUI which was designed by the best artists and usability-experts around, with best possible code and architecture, created by the best coders possible. Sadly, that does not happen.

What about GNOME?

I can hear that question asked already. If open source is problematic when usability is concerned, how did GNOME achieve it? Well, it seems to me that they had lots of paid developers working on it. Developers from Red Hat, Eazel, Ximian and Sun were working on it. And those companies had usability-experts designing the system. So the usability-people had lots more power over the design of the system, as their colleagues in KDE had. KDE seems to be a lot more volunteer-driven effort, whereas GNOME seems to have corporate-backing. And while that volunteer-background is a great thing, there are benefits in the GNOME-way as well. One benefit is the more focused roadmap. Instead of havings dozens (hundreds?) of people and organisations pulling the project in different directions, you have relatively few organizations pulling the project to same direction. It does give the project more focus.

Meritocracy for non-coders

How should this be fixed? To be honest, I don't know. I don't want KDE to turn in to system designed by corporations. Even with it's shortcomings, being volunteer-project is a strenthg, value and an asset. Ideal solution would be that we had a meritocracy in other areas besides coding as well. But that would mean that the usability-guys could tell the developers to change some stuff in the system. And that goes against the way open source works, since in OS, developers work on things they want to work on. If they are told to do something that they disagree with, they might not do it. And they have that right.

One way to achieve true meritocracy would be a web of trust. The developers would have to learn to say "To me that does not make any sense. But you are the expert on this area, while I'm not, so I'll trust your judgement". The developers should trust that the other people really do have the best interest of the project in mind.

3 Comments:

don't underestimate the developers. the fact they are no experts doesn't mean their input is not valuable. the fact they don't say "yes sir" when an usabillity expert tells them to do things different is imho an advantage. see how gnome turned out - dumbed down. this won't happen to KDE, as the dev's simply will refuse to remove functionallity, but force the usabillity people to think harder and to get their ui's usable AND featurefull.

I'm not saying that developers are morons, far far from it. Many of the developers in the greater open source community are propably among the smartest people on the planet. I'm just saying that they are not as good on usability as usability-experts can be. We don't have usability-guys telling the coders how to code, but we do have coders deciding on usability. That's not an optimal situation. Yes, developers input is valuable. But does the fact that they are developers make their usability-input more important that input from regular user would be. Why would it be more important? Just because he's a developer does not mean that he know more of usability than some "normal" user would know.

Coders know code. And they may know usability. Usability-people know usability. And they may know code. But each group has their distinct strong points. We should take advantage of their strong areas. In other words: let the coders create the kick-assest code possible, while we let the usability-guy focus on usability.

I'm not saying that we should "dumb down" KDE. And I'm definitely not advocating removal of features. Far far from it. But I do maintain that GNOME-guys got many things right as far as usability is concerned. They did go overboard in simplifying things, but overall they did a very good job. I want KDE to be featurefull AND easy to use. Unfortunately it's not that right now.

Related to this: We should really think of other terms for usability-work than "dumbing down". that term has a severe negative stigma attached to it, and there's lots more to usability than "dumbing down".

IMHO the solutions is same as for new coders. It's called credibility.

When a coder starts to work on project X, his code isn't trusted immediately either. He could be the brightest coder in the world but he still has to start sending patches that are checked by the project maintainer.

Over time his work will be trusted and he gains access to the source repository.

Same goes for usability experts. How should the project maintainer know if the guy sending suggestions to the mailing list really is an expert?

The usability experts have to gain there credibility as everyone else does. Take e.g. the people from OpenUsability.org. Through a constant flow of good suggestions backed up with hard data (usability tests) they earned a lot of credibility.

They are respected throughout the KDE community and i'm sure no developer would discard their suggestions.