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

List:       koffice-devel
Subject:    Re: GSoC: KWord interface revamp proposal
From:       Jos Poortvliet <jospoortvliet () gmail ! com>
Date:       2009-03-23 19:23:14
Message-ID: 5847e5cf0903231223p576f8899t205173cbc56a5353 () mail ! gmail ! com
[Download RAW message or body]

2009/3/23 David Antler <david.antler@gmail.com>:
> 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.

Creating separate dockers specific to KWord goes against the whole
philosofy of the docker system and the new KOffice, and is most likely
unacceptable. You might rework the current dockers, as I said, to be
more flexible so they can be put in the arrangement your mockup shows,
but that's about it.

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

Currently the dockers don't provide all functionality available in the
menu's. I dunno if they ever will, but for now you will need to keep
the menu's - so vertical space IS wasted. Furthermore, the current
dockers offer more flexibility in adapting to very small screens like
seen on netbooks. Again, it would be good if the dockers were a bit
more flexible in resizing for this to work best.

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

Hmmm, I never do that, but Mac users simply have to so I guess ppl do
it. Won't work on a netbook, though.

> 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

Why don't you fix that issue (changing default dockers, making them
resizable etc)?

> 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

Well, as I said, I'm no KOffice dev, but I do think the devs would be
interested in having somebody rework the dockers architecture to be
more flexible - and that will make it possible to put them on top. I
don't know much about the code behind them, but I doubt you will be
able to do that with some point-and-click-Qt-Designer work. I also
think you started a bit on the wrong foot (having not read the
guidelines, for starters, and showing mocks very closely resembling a
patented design from a competitor, and last but not least you probably
should've done some research so you would've known how much thought
has gone in the design of the current interface). That does not mean
you won't be accepted for a GSOC, but it would take quite a bit of
work and persistence from your end. If you're up to it, I would
suggest reading the guidelines and rewriting the proposal taking into
consideration the comments given in this thread. And also add some
mockups which show other layouts of the dockers - to make clear it's
meant as a generic improvement, not a let's-copy-MS act.

Either way, there is a lot to improve in the current docker system,
and I for one would welcome improvements. If you can make them stop
moving just because I switched tools, or allow them to more freely
resize so I can actually put them on either side of the screen, I'd be
happy :D

Good luck.
_______________________________________________
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]