[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: new layout of koffice apps
From: Boudewijn Rempt <boud () valdyas ! org>
Date: 2008-06-21 9:23:02
Message-ID: 200806211123.02261.boud () valdyas ! org
[Download RAW message or body]
On Friday 20 June 2008, C. Boemann wrote:
Well, I'm afraid I don't agree with much of your proposal. The big usability issues \
for me are the distance between the toolbox and the tool option widget, the ordering \
and appearance/disappearance of tools and having just one tool per shape. For \
instance, I'd be tempted to have more tools for the text shape, like a style \
paintbrush. The size of the current configuration isn't a problem. KOffice apps \
(except for standalone kchart and kformula) are what Alan Cooper calls "sovereign \
applications". They must be used full screen (which reminds me: why don't koffice \
apps remember their previous size anymore?). So given a 1024x768 screen, our dockers \
+ toolbox do not take more room than photoshop's do (and by analogy, in design or \
illustrator). They leave the same working area. The big thing when ordering an \
application's layout is in these wide-screen days to leave as much vertical space as \
possible, not as much horizontal space as possible. That said, smaller margins in the \
toolbox, or maybe having the toolbox undockable and as small as possible by default \
might be good. And other applications should perhaps do the same thing as krita and \
define a default docker layout and restore that on startup if the user hasn't changed \
it. It's probably a bit of a hack, but the only way I can find to define a default \
docker layout. To go into details:
> Basically:
> - it can't hold all the dockers and info we need, so it becomes clumsy
Here we might be able to -- post 2.0 -- achieve something by using a special small \
widget style in the dockers. We also need to fix the layout of some dockers. For \
instance, Krita's freehand paint tool dockers has grown with a number of comboboxes \
and labels and really needs to be redesigned. I saw a demo of IBM's Lotus Symphony \
yesterday and I notice that for their word processor part they have a \
context-sensitive option panel on the right-hand side of the application. That's very \
similar to what we have, only we aren't as context sensitive.
> - the toolbox approach seems awkward for productivity apps
I disagree. I think that we don't use the toolbox enough. We need more tools for the \
separate actions that we can apply to specific shapes. Only then will the toolbox \
come into its own.
> - the toolbox takes up way too much space
Maybe we could move to ordinary toolbars? One for the always present default shape \
tools, one with the per shape-tools. Make the first left-hand side default, the \
second floating by default.
> - the shape collection takes up too much space and only kivio really needs
> it
Here I disagree completely. Don't be fooled by the preponderance of simple path \
shapes currently in the shape selector (which really should get categories before we \
release 2.0). The ability to drag an illustration shape, an image shape, a table, \
chart or text box shape into a document is just as important in kword. Same with \
KPresenter. Looking at Apple's Numbers I can see the same concept working very well \
of KSpread. Shapes for layers and selection masks are just as important in Krita. A \
stylable connector shape is going to do wonders for many presentations and technical \
documents.
> I've come to the conclusion that we would be best served by having dockers
> at the top, though they can't be very heigh. But we should conserve space
> anyway by using popups so it's not that bad.
>
> We should also have the document layoutdocker at the left (common for many
> productivity apps) or right (common for paint apps). Whether we should
> choose one default side for all of koffice can be decided later.
>
> But we shouldn't have dockers at the bottom or at both sides. It just eats
> too much space.
We shouldn't have more than one toolbar at top, nothing at the bottom. I think we can \
actually leave the document structure viewer bottom right without serious problems. \
The big issue with the dockers not showing enough information, to me, is their \
graphical clumsiness. The Oxygen widgets aren't bigger than any other widgets (but \
then, all Qt4 styles have, for instance, comboboxes that are a bit too hight), but \
for dockers we really need a style that focuses on being small. We need a common \
approach to margins -- and they need to be small. And we need to use more popup \
widgets. For 2.1, I would like have a tool option widget that floats, \
semi-transparently over the document and can be called up and dismissed with a button \
or a mouse gesture.
--
Boudewijn Rempt | http://www.valdyas.org
[Attachment #3 (text/html)]
<html><head><meta name="qrichtext" content="1" /></head><body \
style="font-size:8pt;font-family:Misc Console"> <p>On Friday 20 June 2008, C. Boemann \
wrote:</p> <p></p>
<p>Well, I'm afraid I don't agree with much of your proposal. The big usability \
issues for me are the distance between the toolbox and the tool option widget, the \
ordering and appearance/disappearance of tools and having just one tool per shape. \
For instance, I'd be tempted to have more tools for the text shape, like a style \
paintbrush.</p> <p>The size of the current configuration isn't a problem. KOffice \
apps (except for standalone kchart and kformula) are what Alan Cooper calls \
"sovereign applications". They must be used full screen (which reminds me: \
why don't koffice apps remember their previous size anymore?). So given a 1024x768 \
screen, our dockers + toolbox do not take more room than photoshop's do (and by \
analogy, in design or illustrator). They leave the same working area. The big thing \
when ordering an application's layout is in these wide-screen days to leave as much \
vertical space as possible, not as much horizontal space as possible.</p> <p>That \
said, smaller margins in the toolbox, or maybe having the toolbox undockable and as \
small as possible by default might be good. And other applications should perhaps do \
the same thing as krita and define a default docker layout and restore that on \
startup if the user hasn't changed it. It's probably a bit of a hack, but the only \
way I can find to define a default docker layout.</p> <p>To go into details:</p>
<p>> Basically:</p>
<p>> - it can't hold all the dockers and info we need, so it becomes clumsy</p>
<p>Here we might be able to -- post 2.0 -- achieve something by using a special small \
widget style in the dockers. We also need to fix the layout of some dockers. For \
instance, Krita's freehand paint tool dockers has grown with a number of comboboxes \
and labels and really needs to be redesigned.</p> <p>I saw a demo of IBM's Lotus \
Symphony yesterday and I notice that for their word processor part they have a \
context-sensitive option panel on the right-hand side of the application. That's very \
similar to what we have, only we aren't as context sensitive.</p> <p>> - the \
toolbox approach seems awkward for productivity apps</p> <p>I disagree. I think that \
we don't use the toolbox enough. We need more tools for the separate actions that we \
can apply to specific shapes. Only then will the toolbox come into its own.</p> \
<p>> - the toolbox takes up way too much space</p> <p>Maybe we could move to \
ordinary toolbars? One for the always present default shape tools, one with the per \
shape-tools. Make the first left-hand side default, the second floating by \
default.</p> <p>> - the shape collection takes up too much space and only kivio \
really needs</p> <p>> it</p>
<p>Here I disagree completely. Don't be fooled by the preponderance of simple path \
shapes currently in the shape selector (which really should get categories before we \
release 2.0). The ability to drag an illustration shape, an image shape, a table, \
chart or text box shape into a document is just as important in kword. Same with \
KPresenter. Looking at Apple's Numbers I can see the same concept working very well \
of KSpread. Shapes for layers and selection masks are just as important in Krita. A \
stylable connector shape is going to do wonders for many presentations and technical \
documents.</p> <p></p>
<p>> I've come to the conclusion that we would be best served by having \
dockers</p> <p>> at the top, though they can't be very heigh. But we should \
conserve space</p> <p>> anyway by using popups so it's not that bad.</p>
<p>></p>
<p>> We should also have the document layoutdocker at the left (common for \
many</p> <p>> productivity apps) or right (common for paint apps). Whether we \
should</p> <p>> choose one default side for all of koffice can be decided \
later.</p> <p>></p>
<p>> But we shouldn't have dockers at the bottom or at both sides. It just \
eats</p> <p>> too much space.</p>
<p>We shouldn't have more than one toolbar at top, nothing at the bottom. I think we \
can actually leave the document structure viewer bottom right without serious \
problems. The big issue with the dockers not showing enough information, to me, is \
their graphical clumsiness. The Oxygen widgets aren't bigger than any other widgets \
(but then, all Qt4 styles have, for instance, comboboxes that are a bit too hight), \
but for dockers we really need a style that focuses on being small. We need a common \
approach to margins -- and they need to be small. And we need to use more popup \
widgets.</p> <p>For 2.1, I would like have a tool option widget that floats, \
semi-transparently over the document and can be called up and dismissed with a button \
or a mouse gesture.</p> <p>-- </p>
<p>Boudewijn Rempt | http://www.valdyas.org</p>
</body></html>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
--===============1962776800==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic