KDE Usability Improvements

[James Richard Tyrer]

Cornelius Schumacher wrote:
> Hi James,
> 
> On Wednesday 20 April 2005 02:08, James Richard Tyrer wrote:
> 
>>I have been criticized (even flamed) for asserting that designing is
>>work -- work that is at least as important coding.  This makes no
>>sense unless those that do it are just protecting their turf.  If we
>>are all peers in this project then people should not need to protect
>>their turf.
> 
> 
> That's right. I really appreciate that you are still around, despite of 
> being flamed and criticized. You must be serious ;-)
> 
> I agree with you that design is important. But you have to realize that 
> the development process we follow is not that of traditional 
> engineering. We can't distinguish between designers and coders because 
> most of the time the same person does both jobs. 

I didn't mean to suggest that they had to be different persons, but they 
do need to be treated as separate work functions.

> The best design emerges from the team doing the actual work.

Yes, that is true.  At least it is better than having two teams that 
don't have reciprocal communications.  Perhaps two teams with extensive 
reciprocal communication would do better.  One of the strengths of 
conventional engineering is that you must defend your design to others 
and that others will help you be telling you exactly what is wrong with 
your design.  Does this fit in with open software?

> That's the point and I think you are on the same line when you say that 
> we are all peers in the project. It's much more important to 
> communicate in a good way and be part of the community instead of 
> specifying formal roles and processes. That's the power of KDE, that we 
> can concentrate on the work that has to be done, and don't waste time 
> with playing management and setting up formal procedures.

However, if we are going to have design guidelines, those that write 
code are going to need to follow them.

> There is an interesting read, the Manifesto for Agile Software 
> Development (http://www.agilemanifesto.org/). This summarizes quite 
> well what the principles of the open source development process are. 
> It's different from the traditional development process, and it might 
> be hard to accept these principles if you are used to a more formal 
> process, but the success of KDE and other open source projects shows 
> that they actually work quite well.

Yes, that is interesting.  Another, possibly related methodology, is 
eXtreme Programing.  XP might be useful since we have the means to 
communicate with the users.

IAC, I believe that the measure of excellence in software is how well it 
meets the needs of its users.  Adherence to UI guidelines is going to 
increase the excellence of KDE software.

The question is: how do we do this?  The "old Detroit" method is not the 
best method.  The "old Detroit" method is that first you build the car 
and then try to fix what is wrong with it.  The TQM method is that you 
build it correctly from the start and don't need to fix anything.

The patches in my tar ball are an example of the "old Detroit" method. 
And, I perceive that, at least part of, KDE operates on the "old 
Detroit" method which IIUC is counter to the general principles of OSS.

-- 
JRT