[Panel-devel] KDE4 front-end papers

[Zack Rusin]

On Monday 01 May 2006 03:06, Zbigniew Braniecki wrote:
> Hi. I had a discussion with Aaron on his blog (
> http://www.blogger.com/comment.g?blogID=7615673&postID=114537056816755856),
> but did not get the ultimate answer to my biggest concern.
>
> Aaron stated that KDE team has prepared the full UI and feature set related
> documents before they started actually implementing them. That's awesome!
> It means that there are documents describing what will be the feature set
> of KDE4. What will be the UI of the KDE, cases of workflow, target group,
> challenges, maybe there are charts, mockups, templates, there should be
> some docs about user interaction...

This is a problem that people who has been exposed to the archaic way software 
development worked bring forward. The idea that fully defined documents are 
the way to finish a project. They're not. Waterfall doesn't work and Open 
Source does not work utilizing waterfall. Projects that try fail. What you do 
is define a high-level set of goals - we have them - plasma, solid, phonon, 
move to DBUS. That's all we need. Anything beyond that is bound to fail as 
none of us has the uncanny ability to predict the future - which is exactly 
why every single waterfall project fails. 

> The only problem from my point of view is that those docs are not known to
> community - including myself - and thus people actually don't know what
> KDE4 will be. And this problem is WAY wider than just curiosity of small
> group of people - it's about a reliability, predictibility, and cathedral
> vs bazaar problem. 

No, it's not. This is about you knowing the future and that's something no one 
can give you. 

> No company/project can currently rely on KDE4 because they don't know what
> it'll be. 

That's a silly statement to make. What would they rely on? We don't have 
interfaces exposing anything so having a document saying that "at some point 
in the future we might do Z" (for whatever definition of Z) doesn't help at 
all when you're working on some software.

> More, it's users not only has TOTALLY NO influence on what KDE4 will be -

Do users code? No? K, well then by definition they have no influence on code. 
Users get their influence from using software and providing feedback. We 
don't turn users into managers by giving people who simply don't have in 
depth knowledge of development power to steer development. We let people who 
use computers influence the way those tools work. There's a big difference 
between the two. You're trying to promote the first which is an utter 
disaster. To use an analogy it's like having a sick person go for a surgery - 
as a doctor do you give them a scalpel and say "how would you fix you?" or do 
you ask them where it hurts, figure out what's wrong and perform the surgery 
yourself?

> set, but also they even cannot predict what will KDE4 be. So, Joe Average,
> who wants to use KDE, cannot say if he will want to use KDE4, because he
> doesn't know. 

Yeah... Because it's not there yet. Once the betas will start coming, that's 
where we'll be accepting feedback. Until then there's absolutely no decent 
feedback we could get.

> And, against all good habits of Open projects, KDE team seems 
> to focus on "big wow" instead of "release early, release often" method.

Please, do try to refrain from using some nasty homebrew generalizations, 
they're just really irritating. 

> Also, from my discussion with KDE team members on the IRC channel, I got
> the picture of the project which doesn't believe that the community can
> help. It's a blind circle. If you don't let them help, they cannot do this.
> And if they cannot do this, you get no help.

This goes to analogy above.

> Aaron said during that comment thread, that if I want to help I can join
> one of the various projects - Oxygen, KDE docs, KDE QA... It's a problem.
> You should not require people to be a part of the project, any project, to
> let them help you. 

Exactly, that's when a user all you do is download a beta. Then you provide 
feedback. And that feedback will be _immensely_ appreciated for KDE 4. The 
purpose of a long beta cycle before this release will be exactly that, to 
redefine a lot of things so they work _for the people_. 

The infrastructure that is laid in place right now - work on X we're doing, 
Qt, Plasma, Solid, Phonon - those are purely api centric things. And yes, 
users can't help with designing a framework - that's boring work that has to 
be done by people with in depth knowledge of given technologies and software 
engineering in general. But the goal of that framework is provide the ability 
to dynamically adjust almost anything in KDE 4 based on user feedback.

> If Zeldman or Mayer would like to suggest you 
> improvements to your website, would you ask them to join KDE Web Dev
> project first? 

We would gladly take them. If Zeldman or Mayer would like to suggest the way 
we develop the website, especially if we're in a middle of designing the 
backend infrastructure, we would not only ask them to join KDE Web team - 
we'd ask them to send us the patches.

> If Jakob Nielsen would like to spend a few minutes and point 
> you out the major flaws in your KDE4 UI plan, would you require him to join
> KDE4 project?

We'd provide a small "provide feedback" application in all betas where people 
will be able to do exactly that. Unfortunately for that we need those betas.

> The best moment, to let the plan get under the heavy discussion is just
> passing by. Once you already created the libraries, you will have to spend
> ten times more effort to redesign it if someone will point you a flaw than
> if you'd listen first, before acting.

Unfortunately this is another homebrewed generalization. The purpose of 
designing a good framework is exactly that - to make those changes non-hassle 
experience that can be done on the fly without any trouble. It's to allow us 
to create best possible user experience, fully based on feedback from the 
users actually using it while laid on a framework that allows us to seemingly 
evolve KDE as times and user cases change. 

Zack

-- 
If at first you don't succeed, skydiving is not for you