ok... so as the recent thread on kde-core-devel re: kcfg showed, people FEAR usability efforts. that's right, people FEAR it. that word was actually used in relation to the topic. they are afraid some people will screw it up, that KDE can't cope with a drive towards being more usable without becoming pure shit. i really feel like ranting about thickheads, but that would just be adrenaline speaking. as much as that would feel good 
, i'm going to try to be constructive instead: what can be done to gain the trust of people in KDE? or is that a pipedream?
how many times do i need to reiterate the "powerful, flexible AND usable" mantra before people hear it? or how could i say it in a way that people would understand and feel calm enough not to practice public knee-jerk stupidity? how many positive changes do we need to make for people to start trusting them? what sort of positive changes would help inspire trust?
i know other projects have abused their user population and done some really stupid things in the name of usability, and i know KDE is a powerful, configurable, flexible system which is something we need to protect. i like that aspect as much as anyone else. but just HOW does the failure of others translate to the impending failure of KDE?
these are not rhetorical questions. i need to find satisfactory answers.
Syndicate Blogs
Controversy
Honestly, over the past year or so, there has been a lot of conversation about usability in general circles and that has become one of the key dominating factors in KDE, GNOME and other development. It comes to something when CVS Digests are greeted with conversation about the usability of a change, rather than interest in a new feature.
I certainly applaud Aaron's work and that of others in improving KDE usability, but I worry that the usability focus is moving us away from feature development and progression that might heal usability faults as a product of improved methods of working in general.
There have been comments that each project should have a usability specialist, dedicated to the task throughout development, from concept through design, through implementation and subsequent revisions, but that rests on one fatal misconception; that there are a lot of usability experts out there.
I have spent time in university, studying HCI, but I will freely admit that I don't know nearly enough (although I do enjoy bandying ideas on the usability list, such as multi-paste buttons, konqi context toolbars and task-based multi-format meta-data folders). The interesting thing, is that my PhD is in Machine Vision, but I came across a very useful statement that is applicable. "Everyone thinks that because they use human vision, they are an expert in Machine Vision."
The same is true of usability. Everyone thinks that because they use interfaces, that they are usability experts. OSNews, Slashdot and other sites are full of people who think that reading the GNOME HIG makes them usability experts; they doff their caps to Fitt's law without actually ever having read anything about it. We run the risk of allowing KDE's development direction and resources to be forced into usability by controversy, to a point at which they damage all other development and conversation. Honestly, it is insane to be forced to listen to discussion on a new significant release, such as 3.2, with people suggesting that the reason they won't use it, or that Windows users won't use it, is because the context menu is 3 items more than the Windows one in a particular case. This sort of discussion is laying siege to current development.
So what to do about the lack of usability realism and discrete separation of actual experts from the mob?
I think perhaps the best move in this case, is to set up usability teams and resurrect the idea of usability audits for applications; which application developers and project maintainers can call upon at short notice. A hit squad who can look at an application and supply a short set of recommendations in a few days, with priorities, giving the developer a good idea of what can be concentrated on to gain maximum improvement in application usability. Effectively, usability assistance becomes a type of consultancy, and if the maintainer wishes, then usability developers can code patches to assist. The majority of issues that we see between usability coders and maintainers comes because there is a lack of communication, as mentioned here. If usability teams are invited in and invited to assist, however, that problem goes away, shifting responsibility onto the maintainer for any actions which are taken.
Beyond this, I don't know, but I'd like to reiterate that the work of the current usability experts has been great, and would like to thank them for it. I'd also like to reiterate my fears that armchair usability experts are disturbing the balance of development in a way that is making developers feel picked upon, which is possibly exacerbating the division we are seeing and trying to cope with here.