[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: GSoC: KWord interface revamp proposal
From: David Antler <david.antler () gmail ! com>
Date: 2009-03-23 17:58:43
Message-ID: 200903231258.44161.David.Antler () gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Monday 23 March 2009 9:31:26 am Sven Langkamp wrote:
>
> <blahblah>
>
> These goals are quite sinilar to the ones that lead to the current user
> interface. Still we did draw different conclusions.
>
> The basic idea behind the dockers at the side is that it uses the space
> more effectively on widescreen screens which are getting more and more
> popular. Also the documents in KWord are usually higher than they are wide.
> You can see in your mockup that some gray areas appear on the right and
> left side of the page, at the same time vertical space is reduced.
>
> For the dockers itself: Many of the dockers are shared across KOffice, so
> they appear in the other apps to. This means that if you start changing
> dockers in KWord that effects all other apps aswell. It was one of the
> design goals that the they are consistent across KOffice. Additionally the
> dockers are optimized for the current arrangement. I don't see how the
> mockup reduces the usage of dropdown/popup window (except that you
removed
> all menus). You removed the styles tab which is an essential part of KWord
> and is long list of styles. The only way to add it to the mockup would be
> to have it as combobox, which could be very cumbersome if you need a lot
of
> styles.
>
> I'm not a usability person, but I doubt that the UI would get more
> productive or the features could be easier discovered. The current UI
> allows to show more functions at same time. As you can see in your mockup
> there are two dockers which use nearly the complete horizontal space and
> tabs are needed to show more. As you removed the menus at the same time
you
> would have to compress everything like in the ribbon to fit into it. With
> the current UI I can put about 4-6 dockers onto the screen
>
> Personally I think it's not the time for a bigger UI change at the moment.
> We have just got a completly new interface for 2.0 and I don't see the
> point to design a completly different UI so short after the release of the
> previous one. We can say "Look here we have a completly new UI, but don't
> get used to it as the next release will have a completely new ribbon UI".
> Also the reactions that I have seen about the current UI were mostly
> positive so far.
> Finally I think due to the shared nature of KOffice the implications of
> this changes, the project might not be suited for a rather short gsoc
> project. I'm not sure if you are aware of that but this project would need
> a lot more than just moving some widgets in Qt Designer.
I still think that this is a logical progression from the current "Beta"
interface and would be a great benefit to the user. My plan was to come up
with a separate subset of dockers specific to KWord, not to modify existing
ones. I agree, that would be too difficult. I'm not sure of exactly how Qt
Designer works, but that's why I need everyone's help. My proposed redesign
is ambitious, but I don't think the technical implementation is going to be
too difficult (because there are tools like Qt Designer). The docker code is
already there. It doesn't sound like too much but I could be very wrong about
this.
As far as usability is concerned, I am one of the wide-screened users that
everyone seems to be worrying about. One thing that hasn't changed in my
mockup is the amount of space occupied by GUI at the top of the screen; there
is simply more stuff up there. My idea is that when you are trying to do
different tasks with the software, a different tab on the right side will show
up. Notice from the mockup that things already showing are useful no matter
what state the software is in, where as tabbed things are unimportant at
certain times. I wouldn't want to see the "Text" tab when I'm drawing paths,
I would want to see the "Draw" tab, with options geared towards layering,
wrapping, and shadows. This functionality is already implemented but could be
more useful with a layout like the one in my mockup.
I don't think there's any question that this is an improvement. I added the
"Insert" part to the top so that users know what KWord can do; I had no clue
any of that functionality existed when I first used it. With this
arrangement, widescreen users don't need to keep the window maximized.
They can view their nice desktop plasmoids instead, or keep it beside a
browser window.
Currently, when I try to do something in KWord, I get so many dockers on the
right side that I can't even access all of them. They end up going off the
bottom of the window. What appears by default is something dreadful. Here's
the most usable UI I could come up with by arrangement of current dockers,
which is admittedly good, but still took me a while to get right:
http://imagebin.ca/view/aoZHEMot.html
The problem is that, by default, none of those are showing. They appear in
strange places at strange times. I dont think users should be expected to
change so much stuff to get a usable UI. When I first open up KWord, I don't
even notice the frames that make it so powerful, and I have no idea how to
change the text color. There's also a bunch of useless stuff hanging around,
do we really need a humongous, grayed out "B" with "Bold" written under it
when using the path tool? I'd say that all of the toolbars are worthless and
should be replaced completely by dockers, which care about the current state
of the software. But then we have a problem, dockers running too far down
the side of the window. That's why KWord must have dockers configured for
placement at the top and bottom of the window.
In the arrangement I showed in the mockup, it actually does look like the
ribbon, but this is technology that KOffice2 has had implemented all along.
Will Microsoft sue someone if a user decides to lay them out this way?
MSOffice's ribbon is static; KWord's dockers can also be arranged at the right
to maximize usage of screen width, and the current dockers can be used for
that.
Maybe I should make the proposal title: Reworking of KWord Dockers
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" \
"http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" \
content="1" /><style type="text/css">p, li { white-space: pre-wrap; \
}</style></head><body style=" font-family:'Sans Serif'; font-size:10pt; \
font-weight:400; font-style:normal;">On Monday 23 March 2009 9:31:26 am Sven Langkamp \
wrote:<br> ><br>
> <blahblah><br>
><br>
> These goals are quite sinilar to the ones that lead to the current user<br>
> interface. Still we did draw different conclusions.<br>
><br>
> The basic idea behind the dockers at the side is that it uses the space<br>
> more effectively on widescreen screens which are getting more and more<br>
> popular. Also the documents in KWord are usually higher than they are wide.<br>
> You can see in your mockup that some gray areas appear on the right and<br>
> left side of the page, at the same time vertical space is reduced.<br>
><br>
> For the dockers itself: Many of the dockers are shared across KOffice, so<br>
> they appear in the other apps to. This means that if you start changing<br>
> dockers in KWord that effects all other apps aswell. It was one of the<br>
> design goals that the they are consistent across KOffice. Additionally the<br>
> dockers are optimized for the current arrangement. I don't see how the<br>
> mockup reduces the usage of dropdown/popup window (except that you removed<br>
> all menus). You removed the styles tab which is an essential part of KWord<br>
> and is long list of styles. The only way to add it to the mockup would be<br>
> to have it as combobox, which could be very cumbersome if you need a lot of<br>
> styles.<br>
><br>
> I'm not a usability person, but I doubt that the UI would get more<br>
> productive or the features could be easier discovered. The current UI<br>
> allows to show more functions at same time. As you can see in your mockup<br>
> there are two dockers which use nearly the complete horizontal space and<br>
> tabs are needed to show more. As you removed the menus at the same time you<br>
> would have to compress everything like in the ribbon to fit into it. With<br>
> the current UI I can put about 4-6 dockers onto the screen<br>
><br>
> Personally I think it's not the time for a bigger UI change at the moment.<br>
> We have just got a completly new interface for 2.0 and I don't see the<br>
> point to design a completly different UI so short after the release of the<br>
> previous one. We can say "Look here we have a completly new UI, but don't<br>
> get used to it as the next release will have a completely new ribbon UI".<br>
> Also the reactions that I have seen about the current UI were mostly<br>
> positive so far.<br>
> Finally I think due to the shared nature of KOffice the implications of<br>
> this changes, the project might not be suited for a rather short gsoc<br>
> project. I'm not sure if you are aware of that but this project would need<br>
> a lot more than just moving some widgets in Qt Designer.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; \
margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>I still think that this is a logical progression from the \
current "Beta" interface and would be a great benefit to the user. My plan was to \
come up with a separate subset of dockers specific to KWord, not to modify existing \
ones. I agree, that would be too difficult. I'm not sure of exactly how Qt Designer \
works, but that's why I need everyone's help. My proposed redesign is ambitious, but \
I don't think the technical implementation is going to be too difficult (because \
there are tools like Qt Designer). The docker code is already there. It doesn't \
sound like too much but I could be very wrong about this.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>As \
far as usability is concerned, I am one of the wide-screened users that everyone \
seems to be worrying about. One thing that hasn't changed in my mockup is the amount \
of space occupied by GUI at the top of the screen; there is simply more stuff up \
there. My idea is that when you are trying to do different tasks with the software, \
a different tab on the right side will show up. Notice from the mockup that things \
already showing are useful no matter what state the software is in, where as tabbed \
things are unimportant at certain times. I wouldn't want to see the "Text" tab when \
I'm drawing paths, I would want to see the "Draw" tab, with options geared towards \
layering, wrapping, and shadows. This functionality is already implemented but could \
be more useful with a layout like the one in my mockup.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>I \
don't think there's any question that this is an improvement. I added the "Insert" \
part to the top so that users know what KWord can do; I had no clue any of that \
functionality existed when I first used it. With this arrangement, widescreen users \
don't need to keep the window maximized. They can view their nice desktop plasmoids \
instead, or keep it beside a browser window. <br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>Currently, when I try to do something in KWord, I get so \
many dockers on the right side that I can't even access all of them. They end up \
going off the bottom of the window. What appears by default is something dreadful. \
Here's the most usable UI I could come up with by arrangement of current dockers, \
which is admittedly good, but still took me a while to get right: \
http://imagebin.ca/view/aoZHEMot.html<br> <p style="-qt-paragraph-type:empty; \
margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; \
-qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>The problem is that, \
by default, none of those are showing. They appear in strange places at strange \
times. I dont think users should be expected to change so much stuff to get a usable \
UI. When I first open up KWord, I don't even notice the frames that make it so \
powerful, and I have no idea how to change the text color. There's also a bunch of \
useless stuff hanging around, do we really need a humongous, grayed out "B" with \
"Bold" written under it when using the path tool? I'd say that all of the toolbars \
are worthless and should be replaced completely by dockers, which care about the \
current state of the software. But then we have a problem, dockers running too far \
down the side of the window. That's why KWord must have dockers configured for \
placement at the top and bottom of the window.<br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>In \
the arrangement I showed in the mockup, it actually does look like the ribbon, but \
this is technology that KOffice2 has had implemented all along. Will Microsoft sue \
someone if a user decides to lay them out this way? MSOffice's ribbon is static; \
KWord's dockers can also be arranged at the right to maximize usage of screen width, \
and the current dockers can be used for that. <br> <p \
style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; \
margin-right:0px; -qt-block-indent:0; text-indent:0px; \
-qt-user-state:0;"><br></p>Maybe I should make the proposal title: Reworking of KWord \
Dockers</p></body></html>
_______________________________________________
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic