No subject

Tue May 2 01:18:29 CEST 2006

it's a mistake. You can create a camel, instead of the horse. It means, tha=
t
when you'll come to first betas, and then someone will point you an excitin=
g
idea that would change the way you work with the UI (like, imagine somethin=
g
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 ne=
w
design or apply hooks over core libs which will result in lower quality.

It seems to me a bit "random" - let's get some memes and libraries, take
some buzzwords and let's work on this while we share the vision in our grou=
p
and see what will appear at the end. And the last part that will be ready i=
s
UI which, in this approach, will depend on how the low level libs will look=
s
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

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 an=
y
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?

 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?" o=
r
> 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" 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"? ;)

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 decen=
t
> feedback we could get.

It'll be too late for tons of feedback.

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. Th=
e
> 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?
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 redesig=
n
goals.

 But the goal of that framework is provide the ability
> to dynamically adjust almost anything in KDE 4 based on user feedback.

It's pretty often that "we want to write a hammer that will work with
everything and then discuss what we will want to do with it" is wrong. I
hope it's not this case.

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.

If you think the opposite, and find my posts trolling or whineing, I'm
perfectly ok with staying silent. *^^*

Greetings
Zbigniew Braniecki

------=_Part_30259_2034841.1146580941863
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks for the reply Zack. <div>On 5/1/0=
6, Zack Rusin &lt;<a href=3D"mailto:zack@=
kde.org">zack at kde.org</a>&gt; wrote:<blockquote class=3D"gmail_quote=
" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0=
.8ex; padding-left: 1ex;">
 Waterfall doesn't work and Open Source does not work utilizing waterfal=
l.</blockquote><div> As I mentioned earlier, I'm sorry for this assumpti=
on, I do agree that there is a potential in dynamic project goal modificati=
on (like XP)
 &nbsp;</div> <blockquote class=3D"gmail_quote" style=3D"border-left:=
 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex=
;">&nbsp;What you do is define a high-level set of goals - we have them - p=
lasma, 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.</blockquote><div> 
I disagree here. I planned to answer Thiago in separate email but because I=
 disagree with him in the same point, let me just quote him and reply to bo=
th (also, Aaron stated the same in &quot;nobody owns KDE, everyone just doe=
s his part&quot;):
 &quot;We don't know that yet because KDE4 doesn't exist. If you wan=
t that, you'll have to wait for the first betas.&quot;</div> 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 ide=
a that would change the way you work with the UI (like, imagine something t=
he quality of plasmoids but related to user data management for example) yo=
u'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.
 It seems to me a bit &quot;random&quot; - let's get some memes and =
libraries, take some buzzwords and let's work on this while we share the vi=
sion in our group and see what will appear at the end. And the last part th=
at will be ready is UI which, in this approach, will depend on how the low =
level libs 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
 In result for example &quot;boot process&quot; could looks like in =
KDE 3.5: &nbsp;- X server is launched &nbsp;- kdm is launched, login =
box appears &nbsp;- I'm typing my password, asterixes appears in passwor=
d box &nbsp;- I'm pressing enter, it disappears
 &nbsp;- some box appears and icons idicates the next loaded parts &n=
bsp;- it disappears and kicker, wallpaper and icons appear This proc=
ess precizely relates to how the code is written and how the split on the a=
pps 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 experie=
nce is sth like this: &nbsp;- User sees screen that gradients from b=
lack to wallpaper &nbsp;- login box fades in/slides in/whatever &nbsp=
;- he's logging in, some indicator states that he typed proper password (us=
ability)
 &nbsp;- he's accepting login/pass, the login box fades out/slides out/w=
hatever &nbsp;- he can see some neat visual animation that tells him imp=
ortant information: how much more time he'll have to wait &nbsp;- the lo=
gging box blends out with transparency/slides out/disappears in any other w=
ay
 &nbsp;- elements of his UI appears in some visual way like fading, slid=
ing, morphing, expanding, whatever It's just an example. Example of =
two different approaches and different results. <blockquote class=3D=
"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0=
pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&nbsp;We don't have interfaces exposing anything so having a document sa=
ying that &quot;at some point in the future we might do Z&quot; (for wha=
tever definition of Z) doesn't help at all when you're working on some s=
oftware.
</blockquote><div> Did you try? </div> <blockquote class=3D"gmail=
_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt=
 0pt 0.8ex; padding-left: 1ex;">&nbsp;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 &quot;how would you fix =
you?&quot; or do you ask them where it hurts, figure out what's wrong an=
d perform the surgery yourself?</blockquote><div> And should the doct=
or say &quot;I'm going to do X,Y and Z to improve your situation&quot; so y=
ou can say &quot;but doctor, it doesn't hurt me in Y, so you'll not solve m=
y problem there, but in your plan it seems that you're not going to solve m=
y problem with W&quot; or should he just do his work, wake you up and say &=
quot;I did X,Y,Z. If you don't like my changes, change your body&quot;? ;)
 </div> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Yea=
h... Because it's not there yet. Once the betas will start coming, that's<b=
r>
where we'll be accepting feedback. Until then there's absolutely no decent<=
br>feedback we could get.</blockquote><div> It'll be too late for tons o=
f feedback. </div> <blockquote class=3D"gmail_quote" style=3D"border-=
left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left=
: 1ex;">
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 tha=
t, to
 redefine a lot of things so they work _for the people_.</blockquote><di=
v> Hmm, so, can you say that I'm wrong that it'll be too late for majort=
y of feedback? My experience is that &quot;beta&quot; is the moment when=
 you can improve the feature set, not change it. When you can improve set o=
f major concerns, not redesign goals.
 </div> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&nb=
sp;But the goal of that framework is provide the ability to dynamically =
adjust almost anything in KDE 4 based on user feedback.
</blockquote><div> It's pretty often that &quot;we want to write a hamme=
r that will work with everything and then discuss what we will want to do w=
ith it&quot; is wrong. I hope it's not this case. </div> Once more - =
I would never try to doubt in your experience and knowledge. I'm just assum=
ing that it's theoreticly possible that your routines could bound you to al=
ready 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 experienc=
e and discuss different approaches between different projects.
 If you think the opposite, and find my posts trolling or whineing, =
I'm perfectly ok with staying silent. *^^* Greetings Zbigniew Bra=
niecki </div>

------=_Part_30259_2034841.1146580941863--