Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Hi guys,
So, here's the situation:

This feature was coded as part of the UX Hackfest that took place after
FOSDEM. The dev behind it hard-coded it, thinking that if he had time, he
would tweak it so that the color would change based on what background it's
on. He didn't have time, so the color remains hard-coded. I'm doubtful that
we'll find a dev to implement any sort of smart color mechanism, but it's
likely we'll find one to change the hard-coded color.

Milan is right in that the default should work out of the box for as many
as possible. The right thing to do would be to test various colors, on
various monitors, and on people with varying vision levels. I've contacted
Björn Balazs about it, he said that he'll ponder whether he'll work on
that, though he definitely won't have time until at least next week. If any
of you would like to orchestrate a wide-spread test, that would be
extremely useful. As a start, here's a JSFiddle to play with: . Just change the color in the top right
panel to whichever one you propose and click "Run". It might be good to
gather up a few basic hues and then test variants of different brightness
and saturation.

As for the color itself, it should:
* Recede into the background
* Be clearly visible on a white background
* Be distinct from the document content (e.g. please don't use colors from
the LibO color palette)

It might be noteworthy that both iWork and some versions of Office (not
sure if Mac or Windows ones, or both) use blue for invisibles.
BTW, since someone asked before, the reason why gray isn't being used is
because it's very likely that the document contains gray content.

Also, if you find a willing dev, it wouldn't hurt to add this under
Appearance. (This whole section is "advanced", so no worries about
cluttering up Options here. The section will hopefully be moved to "Expert
Configuration" once that becomes usable enough.) However, adding an option
wouldn't fix the issue at hand -- a great default is a must.

2014-06-04 21:25 GMT+02:00 Laurent Lyaudet <>:

Hi Stefan, all,

 Ultimately, this will always be the implementer's decision. Not anyone's
in this team.

So the design team should not take any decision ?
In this respect, whether our decision is based on reasoning or random
thoughts makes no difference.
I prefer to think that the implementer has some sanity and will take into
accounts our decisions.

1) There is no chance get the majority of [people/users of LibreOffice/
    ..?] to express an opinion on this matter.

The same "no chance" argument apply to all ideals.
That's not a reason to stop doing any effort in direction of these ideals.
Ultimately, I prefer to try and fail than accepting different forms of

 2) Do we actually need everyone's opinion? Or would it make more sense
    to find arguments one way or another?

These two goals aren't contradictory. The goal of my previous mail was to
explain that both are needed.
We need arguments but in the end there is most of the time no unique
logical conclusion,
and that's why we end a democratic debate by a vote in order to have the
more representative opinions we can get.
(Maybe we don't need everyone's opinion but we should try to have more
representative opinions.)

 Solving this is best done via Bugzilla with arguments, not via a poll
that will only give skewed, reason-free output anyway.

I don't think Bugzilla is the best place for this because :
- you already provide a privileged solution when you open the bug report;
- it can be done by the devs before a decision has been reached.
We need to centralize the arguments in some place : the archive of the
design mailing list does that when you look at a discussion.
We can also put them in the wiki if you prefer.
Clearly bugzilla without the design team knowing it's here is not the best

I don't see why a poll "will only give skewed, reason-free output anyway. "
Can you prove it ?
Do you mean people who vote have no reasoning abilities ?

 When it comes to design I see a lot of contradicting arguments and most
of the time you end up adding "apples" with "oranges" and so on.

Reasoning on design matters is not (yet?) as clear cut as in
mathematics, true. Still, it should be more than people expressing
random whims.

"Yet ?" ? You don't believe in polls but you do believe some day reasoning
on design matters will be clear cut.
Design matters try to satisfy the needs of the people.
If one day we fully understand people needs and how to adapt to these
needs, I hope we should be able to have efficient polls.

 Second aim "usable to as many people as possible" : I don't see why
having the choice between colors makes it "not usable".

Setting a colour that is too light makes LibreOffice less usable to a
large class of users. That is what I meant here, mostly.

Ok, you wrote your mail as if your aims were arguments against having the
choice of colors.
I misunderstood you.

 But, of course, you are hinting at it... options come at a price. They
increase the complexity of the user interface, they need to be kept
working etc.

The price is not high.
You don't look at the options in a normal workflow.
The complexity of the user interface is marginally increased in some part
that is not often visited.
It's a good example of adding "apples" and "oranges" :
- How to quantify :
-- the gain of usability for some users ?
-- the increase of complexity of the UI ?
- How to compare both quantities ?

"They need to be kept working" : Software, cars, etc. that's quite common.
However, localized features do not need a lot of maintenance.

 The Appearance page of the LibreOffice options in particular is already
a graveyard for far too many borderline useless options.

There is not that much options there.
I work on a business application that has 10 times more options than Libre
I do see a problem with the options interface (it is indeed most
noticeable on the appearance page) : The window is ridiculously small and
you can't extend it.
That's why it feels overcrowded there. Should it be full screen and you'll
breath again.

Best regards,

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.