Michel Renon píše v St 26. 09. 2012 v 13:45 +0200:
UI decisions should be taken based on facts, analysis, polls, statistics.
So this is the statistics I have at hand: Several people angry about a
feature, and nobody praising it. Now, you are the first one, so please
tell me how much do you actually use Impress. If you do, it is really
hard to believe that you haven't got bitten by this yet. Also, I would
be most interested to hear how many times have you actually used the
We cannot measure everything, otherwise we wouldn't get much far because
all that time spent talking, and considering, and writing
specifications. Much better approach is to try what seems good, and if
it does not work, ie. we get complaints constantly, not only a few
during a transition period, change it.
Please note that Renaissance is 3-4 years old project.
A good idea will never be obsolete ;-)
Renaissance was a project, not an idea ;-)
I may be the first, but let me tell you that I find the new
header/footer control *very useful* !
The control is extremely useful, indeed, only its presentation was
annoying, and Cedric fixed that (thanks Cedric!). Now everybody is
And I wish we can use that idea for table edition and much more.
Come up with a proposal, and implement it, that's the best what you can
do. Or try to enthuse a developer to implement it.
Why not allow users to enable/disable such appearing-controls by
Everybody should be happy :
- beginners and average users won't see changes between versions
- power users may choose what they prefer
Every such setting brings you complexity that you have to maintain. It
is error-prone, and the time to implement that is non-trivial too. If
you find somebody who is willing to implement it, maybe, but I'd
encourage the guy/gal to spend the time in some more sensible way.
As a general point of view on this subject, I would say that it shows
several problems in the design team (that's why I'm CCing to design list) :
- there is a lack of long-term vision for LO's UI/UX : a vision, a
roadmap, with tenets. Some big users (administrations, companies...)
need that kind of information so that they can plan training, migration .
For example :
- should we use or avoid appearing / disappearing UI elements ?
- should we use floating and/or docked panels ?
When a decision is made, it should not change for several years (3-5)
Alex / Astron / Mirek / others [in alphabetical order :-)] all have
common vision, and it shows with 3.6 - it is the most beautiful open
source office suite around. How comes you have not noticed that? ;-)
- a developer may decide to make big UI changes, just because he talked
with few users : it's a complete by-pass of the existing UI process
(whiteboards, proposals, discussions, vote) ; it may also bring some big
Imagine a new volunteer who contributed code to improve something, do
you want to say him/her that "OK, but you haven't followed the PROCESS,
return to the drawing board."? Do you think that he'll contribute the
Sorry, but no - this is what this ux-advise list is for. If the code
looks good, and generally the idea looks plausible (even without
extensive UX testing), the best is to get it in, and then _cooperate_
with the author to make it even better, and fitting the overall vision.
I really appreciate how Mirek reacted on what I've done - concrete
points to improve (the toolbar that is too far, etc.). That's something
actionable, and the way I'd like to see the design<->developers
cooperation in general - and I see it happening, thank you all!
- most important, it may changes/revert recent modifications --> users
will be disturbed by those UI flip/flop (for example see previous
changes between Rythmbox and Banshee in Ubuntu)
The best way is to test changes early - get the daily builds, test them,
and report anything that you see problematic there.
and the context of my feedback is that I have not enough
time to work, propose on the UI/UX team, so it's just a little
Well - talk is cheap ;-) Please do get involved, the best is to improve
something that annoys you - an icon that is unpleasant, a drawing
artifact that shouldn't be there, etc. Or just test the daily builds
from time to time, that won't take you that much time.
Unsubscribe instructions: E-mail to email@example.com
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy