[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreoffice-design] Re: Light Blue for Non-printing characters
- Subject: Re: [libreoffice-design] Re: Light Blue for Non-printing characters
- From: "Mirek M." <email@example.com>
- Date: Thu, 5 Jun 2014 01:54:14 +0200
- To: Laurent Lyaudet <firstname.lastname@example.org>
- Cc: "email@example.com" <firstname.lastname@example.org>
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:
http://jsfiddle.net/mirek2/4D36a/ . 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
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 <email@example.com>:
> 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: firstname.lastname@example.org
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-
> 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
To unsubscribe 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
|[libreoffice-design] Re: Light Blue for Non-printing characters||Pedro <firstname.lastname@example.org>|
- Prev by Date: Re: [libreoffice-design] Re: Light Blue for Non-printing characters
- Next by Date: [libreoffice-design] Re: Light Blue for Non-printing characters
- Previous by thread: Re: [libreoffice-design] Re: Light Blue for Non-printing characters
- Next by thread: [libreoffice-design] Re: Light Blue for Non-printing characters