[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 8:51:34
Message-ID: 200909021051.34271.inge () lysator ! liu ! se
[Download RAW message or body]

On Wednesday 02 September 2009 10:01:24 Thomas Zander wrote:
> On Wednesday 2. September 2009 09.33.35 Inge Wallin wrote:
> > I maintain that not focusing on user interface now will make KOffice 2.2
> > not ready for end users.
>
> If KPresenter doesn't allow a user to vertically center his text, if Karbon
> doesn't have text on each shape then it will not be end user ready for a
> large chunk of users.
> Your argument seems to assume that usability is the only problem we have to
> reach the end-user-ready goal. 

Be very careful with words like "only".  I have never said anything like that.  
My suggestion was that we could have both an API review *and* a user interface 
track at the sprint.  You, yourself, argued against that. 

What I said next was not that I think correctness and features are 
unimportant, but that I think that an improved user interface is more 
important than an API review in the short term if I really have to chose 
between them.

> Its is not. Will users complain about
> missing features like not being able to edit tables, like not having more
> than one type of shape-border (line), like not having mail merge, like not
> having animations (think avi/divx) etc etc etc.

Totally correct.  However I have not argued against features ever.

> > Do you and Thomas thus advocate that we move the
> > "user ready" stamp to 2.3?
>
> I'm (personally) arguing that you are misunderstanding the issues KOffice
> faces. All the user-level-visible problems I described above are problems
> in plugins. Plugins that non-core people can only honestly hack on if we
> have a stable API.

If they hack on the koffice tree, a stable API is not very important for them 
because all changes in the core API will be immediately mirrored in the 
plugins in the same commit.  Most of the problems you describe above can and 
should be fixed in the koffice tree, not outside it.

For developers of external plugins, a changing API is a problem, but
 a) I don't think it will happen very often, and
 b) when they happen it's going to be a smaller problem than you make it out 
to be.

What we are discussing is not removing the API freeze, just maybe postponing 
it until 2.3.

> I am arguing that even if we put 100% of every developers time in
> usability, we'll still not have an end-user-ready release in 2.2. Since too
> many end users require one of the items from my (shortened) list above.

I don't think it will require that many hours.  We have to focus on it, and 
execute it, but to actually implement things will not take that much time. 

However, what you write here is interesting.  Are there more people thinking 
that 2.2 will not be end user ready no matter what we do?

> I would also suggest we stop reopening discussions we already had, we
> discussed and decided on the last sprint to do a sprint in Oslo because we
> agreed on the API stabilization. Its not helpful when discussion topics are
> reopened and we have to re-argue all the points. If you don't have
> compelling new arguments, lets follow previously made decisions. All of us.
> Please.

I think I have compelling arguments even if others may disagree. And I also 
think it is not helpful to try to stifle discussion this way.  Not every 
decision is correct, nor every circumstance that lead to the decision is 
constant. Some times we have to revisit things, otherwise we are just rigid 
and stupid.

We have now heard from people thinking that I am wrong (you, Jos, Pau) and 
people who think I'm correct (Casper, Alexandra, Jaroslaw). That even gives me 
a slight majority.

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