[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:       Jos van den Oever <Jos.van.den.Oever () kogmbh ! com>
Date:       2009-09-02 7:54:38
Message-ID: 200909020954.38632.Jos.van.den.Oever () kogmbh ! com
[Download RAW message or body]

On Wednesday 02 September 2009 09:33:35 am Inge Wallin wrote:
> On Wednesday 02 September 2009 09:10:59 Jos van den Oever wrote:
> > A good API and stable software without bugs is much more important than a
> > nice and friendly UI.
>
> That is where we disagree.  Your point of view is a developers.  I'm trying
> to look at the users.
I am looking at the users too, and yes, I am looking from the point of view of 
a developer, because that is what I am. I program to produce nice software 
that people can use.
Improving an API, and more importantly ensuring software quality, is  just as 
much to the benefit of the end user as a good user interface is.
How much the user will like the software depends on how easy it is to use with 
the data of the user, how much the software costs, how well in interoperates 
with other software and most importantly how many bugs it has.

> > A nice UI is no use if it renders and edits documents
> > wrong.
>
> That is wrong in two ways. First, you mix API with implementation.  The API
> can be crap but the implementation still correct or vice versa.  the
> correctness was never up for discussion until you brought it up here.
> Second a UI is frozen over a minor release, but errors in rendering can be
> fixed by bugfix releases. I agree that bugs are bad, but that doesn't have
> much to do with how the UI looks and works.
Are you saying that UI is of use if it renders and edits documents wrong? That 
is the statement you quote and that statement does not contain the acronym 
'API'. It is true that correctness was not up for discussion as topic for the 
sprint. It is, however, more important than either UI and API and an area 
where we have issues. Working on API will help improve correctness much more 
than API will. API discussions should help move to library architecture where 
GUI and application logic are properly separated. This is essential for making 
correctness easier to achieve. So, since correctness is not up for discussion, 
I favor API as the main sprint topic.

> > Currently KOffice needs a lot of work on making sure that ODF and MS
> > Office files are supported properly and to have a framework where we
> > avoid regressions and can monitor progress. The current development model
> > is fragile. We see regressions and crashes and do not have a good enough
> > way of ensuring quality. I think quality monitoring is a topic more
> > important than user interface or API, although discussing a good API and
> > learning from the trolls how to make and maintain one will help a lot in
> > ensuring quality.
> >
> > Focusing on UI design in the current state is disruptive. Once we have
> > good library, it will be easier to design and even implement many UIs on
> > top of it. This is not the time for working on the user interface. We are
> > going to Oslo to be close to knowledgeable trolls. Let us make use of
> > this opportunity. Flying everybody to Oslo is not cheap on expenses or
> > the environment and flying in a  UI designer from across the ocean at
> > time when we should be working on other parts of KOffice is not
> > productive.
>
> I maintain that not focusing on user interface now will make KOffice 2.2
> not ready for end users.  Do you and Thomas thus advocate that we move the
> "user ready" stamp to 2.3?
I maintain that focusing on user interface will make KOffice 2.2 not ready for 
end users since it will take time away from more important issues.

> In the choice between making the API stable and getting end users, I would
> actually choose the end users. I think you put far too much faith in that a
> stable API will get us external developers.  The ones who work within
> KOffice will not be affected by if we move the freezing of the API's to
> 2.3, only external ones will.  More to the point, I think that if somebody
> develops an external shape and we do change the flake API, they can adapt
> pretty easily. An end user who tries out KOffice and finds it cumbersome to
> use will not be back soon.
I did not make an assumption about a stable API getting more external 
developers into the project, not is it something I think we should aim for at 
the moment. My concern is not so much with that API but with software 
correctness. Working on the UI will not improve this. We should talk more 
about what it means to work on such a big project and maintain quality.
KOffice should indeed not be cumbersome to use. The most cumbersome thing about 
KOffice now is that it often does not do what it is supposed to do: render 
documents properly and allow users to edit the document. The latter is not 
impeded as much by the location of the buttons, but by problems in the 
underlying code.

Cheers,
Jos


-- 
Jos van den Oever, software architect
+49 391 25 19 15 53
http://kogmbh.com/legal/
_______________________________________________
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]