[Panel-devel] KDE4 front-end papers

[Zack Rusin]

On Tuesday 02 May 2006 10:42, Zbigniew Braniecki wrote:
> From my experience, through I understand that you don't want to be bounded,
> it's a mistake. You can create a camel, instead of the horse. It means,
> that when you'll come to first betas, and then someone will point you an
> exciting idea that would change the way you work with the UI (like, imagine
> something the quality of plasmoids but related to user data management for
> example) you'll have to reject it, rework major parts of the core libs to
> fit the new design or apply hooks over core libs which will result in lower
> quality.

Unfortunately this paragraph and basically your whole logic is based on a 
horrible fallacy that I'll address first.
What you _have_ to remember is that:
1) KDE 4 doesn't come from a vaccum, it's based on KDE 3. If you want to 
influence KDE 4, take KDE 3 and comment on it. We have bugs.kde.org for that 
already.
2) KDE developers don't start from scratch, we have about 8 years of feedback. 
We can safely assume that's enough.
3) If a rework of a GUI concept (in your example) plasmoids takes more than a 
few hours than we already failed with the framework and no kind of user 
feedback is going to save it.

> will looks like. So instead of writing libs to solve the problem we want to
> solve (let the user be able to do X,Y,Z with his wallpaper, and V,W and U
> with his kicker) you write the UI based on the already existing libs

Again, that's a nasty fallacy. If we did that half a year ago we'd end up with 
a CDE. The features we need don't exist in libraries so by induction we can't 
use them and obviously from that follows that before we work on them we have 
to add them to base libraries.

> In result for example "boot process" could looks like in KDE 3.5:
>  - X server is launched
>  - kdm is launched, login box appears
>  - I'm typing my password, asterixes appears in password box
>  - I'm pressing enter, it disappears
>  - some box appears and icons idicates the next loaded parts
>  - it disappears and kicker, wallpaper and icons appear
>
> This process precizely relates to how the code is written and how the split
> on the apps exists and what libs need to be loaded in which order.
> This is not what the user is looking for. He doesn't care. User experience
> is sth like this:
>
>  - User sees screen that gradients from black to wallpaper
>  - login box fades in/slides in/whatever
>  - he's logging in, some indicator states that he typed proper password
> (usability)
>  - he's accepting login/pass, the login box fades out/slides out/whatever
>  - he can see some neat visual animation that tells him important
> information: how much more time he'll have to wait
>  - the logging box blends out with transparency/slides out/disappears in
> any other way
>  - elements of his UI appears in some visual way like fading, sliding,
> morphing, expanding, whatever
>
> It's just an example. Example of two different approaches and different
> results.
>
>  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.
>
> Did you try?

Well, yes, that's what I do for my job. 

> > 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?
>
> And should the doctor say "I'm going to do X,Y and Z to improve your
> situation" so you can say "but doctor, it doesn't hurt me in Y, so you'll
> not solve my problem there, but in your plan it seems that you're not going
> to solve my problem with W" 

Again, that's also a fallacy (and a really bad analogy too, if doctors would 
be doing that everyone would be dead and if that would be how we worked no 
one would use any of our software and looking at KDE 3 stats you're simply 
wrong). In software engineering we have this dogma of not fixing things that 
aren't broken which we'll adhere to (even if by the virtue of not having 
enough bodies to do other stuff).

> or should he just do his work, wake you up and 
> say "I did X,Y,Z. If you don't like my changes, change your body"? ;)

Really, that doesn't relate to absolutely anything.

> > where we'll be accepting feedback. Until then there's absolutely no
> > decent feedback we could get.
>
> It'll be too late for tons of feedback.

Yeah, that's why we had KDE 1, 2, 3. If you're trying to say that 8 years 
wasn't enough and suddenly you will come up with brilliant things in about 
two weeks we have way bigger problems than KDE 4.

> > 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_.
>
> Hmm, so, can you say that I'm wrong that it'll be too late for majorty of
> feedback?

Another fallacy. As I mentioned repeatedly if changing graphical elements is a 
problem we have way bigger problems on a lot more fundamental level because 
our framework isn't there.

> My experience is that "beta" is the moment when you can improve the feature
> set, not change it. When you can improve set of major concerns, not
> redesign goals.

That's because you seemed to be bend on an archaic way software development 
worked (or rather didn't). Like I mentioned that's not how Open Source works. 
It's a _lot_ more dynamic.

> Once more - I would never try to doubt in your experience and knowledge.
> I'm just assuming that it's theoreticly possible that your routines could
> bound you to already known paths and result in missing some things that
> cannot be archived in your model. I also believe that it's always good to
> share the experience and discuss different approaches between different
> projects.

Yes, like I mentioned we had 8 years of that and number of conferences that I 
couldn't list (and trust me I even tried to write down all my trips during 
the last 3 years and wasn't able to). Not even mentioning irc and email 
discussions. 

To go back to your initial question, no one will write full blown design 
documents. In fact I'll be militantly opposed to something like that. It 
never ever works. We discuss features as we're developing them. Like I 
mentioned things don't come from vaccum. Each new idea that we'll (and i'm 
using "we" as i'm not that involved in KDE anymore) implement will come 
naturally and will follow from a public discussion. So going back to your 
analogy with failing plasmoids - if we'd figure out that they're busted 
during only betas that would imply that we failed as a community. And this is 
crucial you have to understand this to see how Open Source development model 
works :
every feature that is implemented follows from a public discussion on a public 
forum (usually mailing lists but the more important ones get on dot.kde.org, 
slashdot and similar mediums), that's how the feedback works in Open Source.

The reason we use this method is because it works. It allows us to focus 
community on the same concept while it's being worked on. 
Otherwise if I'm working on, for example grammar checker for KDE and you'd 
come down and say "i've read design document and i think that the graphical 
concept of filters on the desktop you did is busted" I'd have to ignore you 
because it doesn't realate to what I'm doing at the moment and I can't just 
drop everything every single time someone has a comment. And that would be a 
shame. 

Zack

-- 
If it is not on fire, it is a software problem.