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

List:       koffice-devel
Subject:    Re: Re: Re: Re: Re: [Karbon14] Re: Re: Re: misc
From:       Thomas Zander <zander () planescape ! com>
Date:       2002-10-28 19:58:46
[Download RAW message or body]

On Mon, Oct 28, 2002 at 04:51:15PM +0100, kudling@kde.org wrote:
> Dirk Sch?nberger <dirk.schoenberger@sz-online.de> schrieb am 28.10.2002,
> 16:34:47:
> > > > And my other _Office apps_ doesn't have it, so?
> > 
> > > As i said, if you force me to decide between usability and compliance
> > > it's very clear which way i'll go.
> > 
> > And as I said, without compliance there can be no useability. If I have to
> > relearn the
> > UI of each application apart, there is no useability.
> 
> And what if the gui of a certain program is proven to be _very_ good? OF
> COURSE the gui of a graphic app IS different to a word processor. Don't
> try to equalize things which are not.

Just to point out; all usability studies, and most graphics artist agree that
the GUI of Adobe Illustrator is a the worst in usability on the market.
Problem is that it is the standard and graphics-schools actually teach
Illustrator (which should say something by itself).


I'm just picking this message to reply to; but about this thread there are some
points I'd like to talk about.

First about the current toolbox widget.
Since the bottom widget is so wide that it takes 2 columns of buttons I don't see
any way to nicely put that in another toolbar without creating something ugly and
unusable.
The 2 column (or 2 row if you dock it at the top/bottom) is therefor no problem
IMO, and just what lots of people expect.


> > All modern GUI applications have a menubar, and a toolbar with the _user
> > selected_ mostly used functionality.
> 
> All modern operating systems have a mach kernel, now what?
I must disagree here, Dirks point is valid since a user expects consistency.
More below.

> > Becuase things like "change stroke properties" and "change fill properties"
> > aren't implemented as KActions, it isn't possible to create truely useable
> > toolbars.
> 
> You don't need to, since you have dockers/dialogs with tabpages.

If you choose to access a config via a dialog, the action to access that
dialog should be in the menu.  This is like that in all KDE applications, and
its been done for a reason. (I hope you can just accept that certain GUI
design decisions are in the styleguide after being made by well-informed
people)

If you want to do it in a docker; then do so via actions. So the docker (which
should be a toolbar) can be configured normally.

Lenny has a very good point that some things are not really nice in their
implementation if you have to follow the KDE rules. For example I really like
the idea of dockers!
A point I made last week stands though, a user WILL still expect the defaults
to be usable. So a docker should just be a toolbar for maximum conformaty.

For example I implemented the toolbox to use a grid, but it is still a
toolbar!  If Dirk then wants a number of toolbars that have the actions
formatted via the xml toolbars. Let him!

The only change is that the toolbuttons used currently should be KActions.
Is that a problem?

-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]