[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:       Inge Wallin <inge () lysator ! liu ! se>
Date:       2009-09-02 11:21:20
Message-ID: 200909021321.20572.inge () lysator ! liu ! se
[Download RAW message or body]

On Wednesday 02 September 2009 11:15:50 Pierre Stirnweiss wrote:
> 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.

Agree 100%.

> 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).

I think you are partly right here.  Detailed analysis is probably a waste of 
time since, as you say, we will have to add lots of UI elements and even 
complete dialogs.  However, that is not what I'm after.

What I want us to really go through and see if our basic assumptions were 
right from when we started to develop the current paradigm, and if they are 
implemented as we wanted -- or better: as we really want.

Just to pick a trivial example, I become irritated every time I have to double 
click on a shape to get its config dialog to open.  Somebody said it was 
dependent on applications, but as I said: it's just an example.  I think 
Boudewijn mentioned inspectors as something else that wasn't implemented, but 
was some time ago and I may remember wrong.

And things will turn up again and again during the development cycle.  What I 
hope Celeste will help us with is that we get a common framework and language 
so that we can discuss these things without making a lot of naive assumptions 
and press points that usability science have already proven wrong. So we have 
to have a state of mind that usability and UI design is important and that's 
what I hope to kickstart.

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

This is where it gets interesting.  Yes, a good API will help us implement the 
basic core features.  The question is if those basic core features aren't 
already implemented, though.  Things mentioned in other mails in this 
discussion: table editing, etc are hardly core features of the libraries.  
They may be core features of the applications, but they are nicely contained 
in plugins. So to fix them, we don't need to redesign or freeze any API's.

I think we all agree that in the end we want to have complete, correct 
applications with a solid base in well designed APIs and with a UI on top of 
it that is so natural to use that you hardly notice it.  The question is in 
which order to achieve this.  As I see it we can either:

1. Design our API's and freeze them to make it easier to get outside help.
2. Take care of the remaining UI issues and make the already correct working 
apps more shiny.

or:

1. Design a natural and well functioning UI
2. Freeze our API's now that we really know what we need.

The main risk with the first approach is: what if we find out that we need to 
change our API's to achieve what we want in step 2?  I.e. what if our, now 
frozen, API's don't support what we need in order to achieve the well working 
UI?  Then we are, as they say, screwed.

	-Inge

_______________________________________________
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]