'Re: GSoC: KWord interface revamp proposal'

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

List: koffice-devel
Subject: Re: GSoC: KWord interface revamp proposal
From: Sven Langkamp <sven.langkamp () gmail ! com>
Date: 2009-03-23 14:31:26
Message-ID: 478b087a0903230731s3cfb5c5dma0bf6e6ca53d6f49 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Thanks for your proposal. I have listed some of my thoughts below.

Design philosophy: Keep the most commonly used features easily accessible t=
o
> the user at all times, highlighting the strength of KWord in layering and
> use of frames. Display relevant features at relevant times. Using symbols=
 to
> express ideas and tooltips to clarify rather than static text. Minimize t=
he
> user's visual parsing of interface required to find their desired action.
>
>
> Design goals:
> =95 Increase the productivity of KWord users
> =95 Introduce convenient shortcuts for common tasks
> =95 Showcase KWord's capabilities and features to unfamiliar users
> =95 Minimize usage of dropdown/popup windows
> =95 Eliminate the need to modify the UI for functionality
> =95 Conserve screen space
> =95 Maintain the customizaton and flexibility that KOffice users are
> accustomed to
>

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 mor=
e
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 o=
f
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 t=
o
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 allow=
s
to show more functions at same time. As you can see in your mockup there ar=
e
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 poin=
t
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 thi=
s
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 mor=
e
than just moving some widgets in Qt Designer.

[Attachment #5 (text/html)]

Thanks for your proposal. I have listed some of my thoughts below. 
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px \
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div \
style="font-family: &#39;Sans Serif&#39;; font-size: 10pt; font-weight: 400; \
font-style: normal;"> Design philosophy: Keep \
the most commonly used features easily accessible to the user at all times, \
highlighting the strength of KWord in layering and use of frames. Display relevant \
features at relevant times. Using symbols to express ideas and tooltips to clarify \
rather than static text. Minimize the user&#39;s visual parsing of interface required \
to find their desired action.

Design goals: •	Increase the productivity of KWord users 
•	Introduce convenient shortcuts for common tasks 
•	Showcase KWord&#39;s capabilities and features to unfamiliar users 
•	Minimize usage of dropdown/popup windows 
•	Eliminate the need to modify the UI for functionality 
•	Conserve screen space 
•	Maintain the customizaton and flexibility that KOffice users are accustomed \
to</div></blockquote></div> 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&#39;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&#39;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&#39;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&#39;t see the point to design a completly different UI so \
short after the release of the previous one. We can say &quot;Look here we have a \
completly new UI, but don&#39;t get used to it as the next release will have a \
completely new ribbon UI&quot;. 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&#39;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.

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