[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice 2.2, usability and the Q4 sprint
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2009-09-02 9:15:50
Message-ID: af76e3dc0909020215h6ce5cb05sdbdd3eaf66ff1433 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


The contribute my 2 cents:

I think there is a general consensus on two points:
- we don't have as of yet (and probably not even before 2.2) all the *basic
core features* in our applications (to various extend depending on the
application). To be honest, I am not even sure these are really defined for
every application in Koffice.
- for the ones we have, problems (bugs) exist. This is the correctness
discussion.

Now, keeping in mind that we will add significant (both in size and in
amount) features, is it realistic to state we can maintain stability in:

- library API: perhaps if designed properly.

- user interface and user interaction: if we are speaking of UI at a
detailed level, I very much doubt it (as an example: tables in KWord are now
pretty basic and do not require much UI, this will change pretty quick).
Every new feature will have to be added to the UI. This means that when our
basic core features are finally there we will have to redo the UI exercise
again or have  a nice subset UI with additional features being patched up on
top.

So my opinion on the subject is that untill all the basic core features are
there, all UI work (at a detailed level) requirering a useability expert is
probably a loss of time. If we are speaking of having developers educated in
basic UI principals, I think litterature on the subject is probably more
efficient at this stage (as opposed to fly in somebody to do a lecture).

On the other hand, API (re)design will help significantly for adding these
required basic core features.

Pierre

[Attachment #5 (text/html)]

The contribute my 2 cents:<br><br>I think there is a general consensus on t=
wo points:<br>- we don&#39;t have as of yet (and probably not even before 2=
.2) all the <u>basic core features</u> in our applications (to various exte=
nd depending on the application). To be honest, I am not even sure these ar=
e really defined for every application in Koffice.<br>
- for the ones we have, problems (bugs) exist. This is the correctness disc=
ussion.<br><br>Now, keeping in mind that we will add significant (both in s=
ize and in amount) features, is it realistic to state we can maintain stabi=
lity in:<br>
<br>- library API: perhaps if designed properly.<br><br>- user interface an=
d user interaction: if we are speaking of UI at a detailed level, I very mu=
ch doubt it (as an example: tables in KWord are now pretty basic and do not=
 require much UI, this will change pretty quick). Every new feature will ha=
ve to be added to the UI. This means that when our basic core features are =
finally there we will have to redo the UI exercise again or have=A0 a nice =
subset UI with additional features being patched up on top.<br>
<br>So my opinion on the subject is that untill all the basic core features=
 are there, all UI work (at a detailed level) requirering a useability expe=
rt is probably a loss of time. If we are speaking of having developers educ=
ated in basic UI principals, I think litterature on the subject is probably=
 more efficient at this stage (as opposed to fly in somebody to do a lectur=
e).<br>
<br>On the other hand, API (re)design will help significantly for adding th=
ese required basic core features.<br><br>Pierre<br>


_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]