Widelands

Hi Borim,
I'm definitely not the one to say anything about programming techniques.
I cannot be sure - this was before "my time", but I could imagine that 
Nasenbaer (Peter) has done
part of or all of this work. Unfortunately he is very busy lately and 
does not show up much.

I am also trying to fix those colors at the moment, hoping somebody will 
then
somehow bring them into the code :)
What I can say, however, is that those colors were generated with a 
ruleset in mind.
(best seen with the Atlanteans) like: "666600", "333300",ccff00" 
"99cc00" and so on.
It seems like the primary intention was to assign different colors to 
everything even across the tribes,
and to avoid any repetition.
I don't see the point in that. One set of colors can go for all tribes IMO.
And rather than "invisible" or "undistinguishable" colors, I'd go with 
some repetition.

Since this systematic approach obviously gave some unwanted results, I 
am now trying (as in "paint a thin line on that light grey marble 
background" to find colors that are:
a) Clearly visible against that background (if not, I'll suggest 
changing that first!)
b) As different from each other, as can be contrived.
The reason the mathetical approach is not so good, is a physiological one:
The human eye is not equally sensitive over the whole spectrum of 
colors, but is best
in the "green" section. So, I think there is no better way than try and 
error.
I have not yet done much to find new colors, so if you want to do that 
yourself, tell me, please.
Else, I hope I can come up with a list of suggestions.
If you can (and agree) I'd ask you too look for the place where the 
width of the line is defined in code,
and make the lines a bit thicker. This seems to be part of the problem 
also, and the scale of the graph
does not allow for too much accuracy anyhow.

cheers Wolf (aka Astuur)


Am 20.11.2011 12:00, schrieb borim7@...:
> Hello,
> I currently change the plot line colors in the ware statistics menu. Some of them are hardly vissible...
>
> During my work I recognized that the array, which define the color is 241 entries long, but the accumulated sum of ware types is only 137 (39 barbarian, 45 empire, 53 atlanteans)
>
> Is there any reason known, why such a big array is created?
>
> And if anything speaks again shrinking the array down?
>
> Cheers
> Matthias (Borim)
> ___________________________________________________________
> SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
> kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public
>

Heya,

Am 20.11.2011 um 12:00 schrieb borim7@...:

> 
> I currently change the plot line colors in the ware statistics menu. Some of them are hardly vissible...
The ware statistics menu is mainly from me. The colors were autogenerated from some html color list iirc. 
 
> 
> During my work I recognized that the array, which define the color is 241 entries long, but the accumulated sum of ware types is only 137 (39 barbarian, 45 empire, 53 atlanteans)
> 
> Is there any reason known, why such a big array is created?
No. It was not clear back then how much would be needed. 

> 
> And if anything speaks again shrinking the array down?
Yes. The array is hardly sensical. If you start working on this, I suggest a change. The idea was that one was able to compare wares in their production  - for example see if trunks and planks are produced equally or so. But while playing it shows that it is hardly ever useful to compare more than two or three wares. I therefore suggest the following: instead of statically setting some colors, I suggest that colors are given in the order the player selects a ware. For example, the player clicks on planks and a blue do appears on the button and the plot is drawn in blue. If he now clicks on another ware, this one will be drawn in red and so on. If the player tries to activate more than (say) 5 wares, the plot area will refuse this - he first has to deactivate another ware.

What do you think.

Cheers,
Holger

Am 20.11.2011 12:40, schrieb Wolf Steinmetz:
> Hi Borim,
 > ...
> I am also trying to fix those colors at the moment, hoping somebody will
> then
> somehow bring them into the code :)
I dont mind to do it ;)

> What I can say, however, is that those colors were generated with a
> ruleset in mind.
> (best seen with the Atlanteans) like: "666600", "333300",ccff00"
> "99cc00" and so on.
> It seems like the primary intention was to assign different colors to
> everything even across the tribes,
> and to avoid any repetition.
If the intention was to use different colors for everything, than only 
the color array show this in the code.
Only the first 45 color entries are used for plot lines. Also there is 
no differentiation between the tribes.

> I don't see the point in that. One set of colors can go for all tribes IMO.
> And rather than "invisible" or "undistinguishable" colors, I'd go with
> some repetition.
I can only agree with you and currently this is done this way, too.

> Since this systematic approach obviously gave some unwanted results, I
> am now trying (as in "paint a thin line on that light grey marble
> background" to find colors that are:
> a) Clearly visible against that background (if not, I'll suggest
> changing that first!)
> b) As different from each other, as can be contrived.
> The reason the mathetical approach is not so good, is a physiological one:
> The human eye is not equally sensitive over the whole spectrum of
> colors, but is best
> in the "green" section. So, I think there is no better way than try and
> error.
> I have not yet done much to find new colors, so if you want to do that
> yourself, tell me, please.
I think the main problem is, that so many different colors were generated.
If you do not mind, I will generate a short color list with only 50 
entries (just to prevent that adding a new ware require to touch this 
code again ;) ) and without any gray shade. And if you want you can 
improve it with your hand picked colors, when you are not pleased with it.

> Else, I hope I can come up with a list of suggestions.
> If you can (and agree) I'd ask you too look for the place where the
> width of the line is defined in code,
> and make the lines a bit thicker. This seems to be part of the problem
> also, and the scale of the graph
> does not allow for too much accuracy anyhow.
>
> cheers Wolf (aka Astuur)
Currently there is no definition of the line width. It is simply draw a 
single line.
I will implement a thicker line and than we can decide what looks better.

Cheers Matthias (Borim)

Since Sirver has again outsmarted us both
with his excellent suggestion :),
there is no place for an 
evidence-based-graphical-orientated-color-evaluator like me.
Dropping out of this task.
Good luck Borim!


Am 20.11.2011 16:22, schrieb Borim:
> Am 20.11.2011 12:40, schrieb Wolf Steinmetz:
>> Hi Borim,
>   >  ...
>> I am also trying to fix those colors at the moment, hoping somebody will
>> then
>> somehow bring them into the code :)
> I dont mind to do it ;)
>
>> What I can say, however, is that those colors were generated with a
>> ruleset in mind.
>> (best seen with the Atlanteans) like: "666600", "333300",ccff00"
>> "99cc00" and so on.
>> It seems like the primary intention was to assign different colors to
>> everything even across the tribes,
>> and to avoid any repetition.
> If the intention was to use different colors for everything, than only
> the color array show this in the code.
> Only the first 45 color entries are used for plot lines. Also there is
> no differentiation between the tribes.
>
>> I don't see the point in that. One set of colors can go for all tribes IMO.
>> And rather than "invisible" or "undistinguishable" colors, I'd go with
>> some repetition.
> I can only agree with you and currently this is done this way, too.
>
>> Since this systematic approach obviously gave some unwanted results, I
>> am now trying (as in "paint a thin line on that light grey marble
>> background" to find colors that are:
>> a) Clearly visible against that background (if not, I'll suggest
>> changing that first!)
>> b) As different from each other, as can be contrived.
>> The reason the mathetical approach is not so good, is a physiological one:
>> The human eye is not equally sensitive over the whole spectrum of
>> colors, but is best
>> in the "green" section. So, I think there is no better way than try and
>> error.
>> I have not yet done much to find new colors, so if you want to do that
>> yourself, tell me, please.
> I think the main problem is, that so many different colors were generated.
> If you do not mind, I will generate a short color list with only 50
> entries (just to prevent that adding a new ware require to touch this
> code again ;) ) and without any gray shade. And if you want you can
> improve it with your hand picked colors, when you are not pleased with it.
>
>> Else, I hope I can come up with a list of suggestions.
>> If you can (and agree) I'd ask you too look for the place where the
>> width of the line is defined in code,
>> and make the lines a bit thicker. This seems to be part of the problem
>> also, and the scale of the graph
>> does not allow for too much accuracy anyhow.
>>
>> cheers Wolf (aka Astuur)
> Currently there is no definition of the line width. It is simply draw a
> single line.
> I will implement a thicker line and than we can decide what looks better.
>
> Cheers Matthias (Borim)
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public
>

Am 20.11.2011 15:38, schrieb Holger Rapp:
...
>> And if anything speaks again shrinking the array down?
> Yes. The array is hardly sensical. If you start working on this, I suggest a change. The idea was that one was able to compare wares in their production  - for example see if trunks and planks are produced equally or so. But while playing it shows that it is hardly ever useful to compare more than two or three wares. I therefore suggest the following: instead of statically setting some colors, I suggest that colors are given in the order the player selects a ware. For example, the player clicks on planks and a blue do appears on the button and the plot is drawn in blue. If he now clicks on another ware, this one will be drawn in red and so on. If the player tries to activate more than (say) 5 wares, the plot area will refuse this - he first has to deactivate another ware.

I think the array is also required in the dynamical approach. Simply as 
you need something to store the color values. The difference is only 
that you choose the color by the number of the active plot line and not 
by the ware number.

I have some doubts if limiting the number of activatable wares is a good 
decision. I mostly use 1 - 3 active wares at the same time and I agree 
more active wares are hardly helpful. But if someone wants a rough 
overview, why not let him activate all wares, or who knows why else he 
wants to activate more...
Also you need to inform the player, why no more wares are activated, so 
you have to show him a popup. This means some work (do not know how 
much) and annoys the player.
So I prefer to allow activating all wares ;)

Now to the dynamic assigning of the line color itself. Compared to the 
change of the color array, this is quite a big change. Roughly you have 
to add following things:
* change the color of the ware button, when activating/deactivating
* change the color of the plot line
* keep track of active colors
That is some complexity which is added to the ware statistics menu...

Maybe with the dynamic approach the plot line looks a little better, but 
a well designed static color distribution should also looks nice. And I 
think with about 50 colors it should be not so hard to create a good 
color distribution ;)

To sum it up, I am not really convinced that the work for a dynamic 
determined plot color is well invested. Also I prefer to keep the code 
simple ;)

Did I miss any advantages of the dynamic approach?

Cheers Matthias

Am 20.11.2011 18:04, schrieb Borim:
> Maybe with the dynamic approach the plot line looks a little better, but
> a well designed static color distribution should also looks nice. And I
> think with about 50 colors it should be not so hard to create a good
> color distribution;)

Borim, --- it's not easy to find 50 suitable colors; I have tried and 
reduced it to 20.
And even that is not easy to tell apart with thin lines on a light 
patterned background.

For all practical consideration reducing the simultainiously available 
colors to 5 -> 10 seems
quite generous to me and more than enough.

Can't comment on the prgramming work, obviously.

Heya,

>> 
>> Yes. The array is hardly sensical. If you start working on this, I suggest a change. The idea was that one was able to compare wares in their production  - for example see if trunks and planks are produced equally or so. But while playing it shows that it is hardly ever useful to compare more than two or three wares. I therefore suggest the following: instead of statically setting some colors, I suggest that colors are given in the order the player selects a ware. For example, the player clicks on planks and a blue do appears on the button and the plot is drawn in blue. If he now clicks on another ware, this one will be drawn in red and so on. If the player tries to activate more than (say) 5 wares, the plot area will refuse this - he first has to deactivate another ware.
> 
> I think the array is also required in the dynamical approach. Simply as 
> you need something to store the color values. The difference is only 
> that you choose the color by the number of the active plot line and not 
> by the ware number.
I would suggest starting with the player colors which are quite well distinguishable. Also, tuning player colors will then also tune the ware colors.

> 
> I have some doubts if limiting the number of activatable wares is a good 
> decision. I mostly use 1 - 3 active wares at the same time and I agree 
> more active wares are hardly helpful. But if someone wants a rough 
> overview, why not let him activate all wares, or who knows why else he 
> wants to activate more...
This is information overflow. I doubt that anyone can read more than 10 lines. It also makes little sense comparing many different wares against each other. Maybe all in one category. I feel supporting something that we all agree on makes no sense makes no sense (what a phrase :) ).

> Also you need to inform the player, why no more wares are activated, so 
> you have to show him a popup. This means some work (do not know how 
> much) and annoys the player.
I disagree. There are actually two thinks you could do:
1) do not activate the color. The player realizes that it no longer works because no color on the button and no graph appears. He might not deduce that he can only show this and this many wares though.
2) deactive the first color and reuse it for the new ware. This will disable the first ware the user has activated. I think this is quite intuitive.
> 
> 
> Now to the dynamic assigning of the line color itself. Compared to the 
> change of the color array, this is quite a big change. Roughly you have 
> to add following things:
> * change the color of the ware button, when activating/deactivating
> * change the color of the plot line
> * keep track of active colors
> That is some complexity which is added to the ware statistics menu...
I agree that this will change the functionality of the ware statistics code. I argue that it reduces complexity for the user though. About the coding work involved, I feel that we are currently talking "quick fix" or "doing it right". I'd love that you repair the menu when you are going to touch it, but obviously your suggestion is already an improvement and better than not touching it.

> To sum it up, I am not really convinced that the work for a dynamic 
> determined plot color is well invested. Also I prefer to keep the code 
> simple ;)
The statistics menu is quite a mess code wise. It stems from early work and I hope my newer code shows my growth as a programmer. I'd bet you a beer that you can reduce code complexity while adding the functionality (This bet comes from experience: i am reworking the editor atm and I regularly kill dozen lines of code and achieve better results).

Cheers,
Holger

On Sunday 20 November 2011 18.52:30 Wolf Steinmetz wrote:
> Am 20.11.2011 18:04, schrieb Borim:
> > Maybe with the dynamic approach the plot line looks a little better, but
> > a well designed static color distribution should also looks nice. And I
> > think with about 50 colors it should be not so hard to create a good
> > color distribution;)
> 
> Borim, --- it's not easy to find 50 suitable colors; I have tried and
> reduced it to 20.
> And even that is not easy to tell apart with thin lines on a light
> patterned background.
> 
> For all practical consideration reducing the simultainiously available
> colors to 5 -> 10 seems
> quite generous to me and more than enough.

As long as the colors are assigned dynamically, a mix of both approaches is 
the best: keep an array of around 50 or so colors, but order them such that 
the first 5 to 10 colors are clearly distinguishable, i.e. start with primary 
colors, continue with a few colors that are clearly distinct, and then later 
go into shades that may be harder to distinguish.

The further down the list you go, the harder they become to distinguish, but 
that's okay: those colors will only be used when the player selects that many 
wares - so then it's "their own fault".

cu,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

Hello,

About maximum distinguishable colors I can provide some "scientific thought hammer" (not really): I recently stumpled upon the problem of having distinguishable colors in plots and ran into an implementation of an interesting idea: Generate colors and choose n colors that are maximally apart in the colorspace of "human perception" [1]. I found a nice matlab implementation [2] that could be easily transferred to other languages - you might give this a go to find good colors if you so choose.

[1] http://en.wikipedia.org/wiki/Lab_color_space
[2] http://www.mathworks.com/matlabcentral/fileexchange/29702

Cheers,
Holger

Hey,

Am 21.11.2011 12:42, schrieb Holger Rapp:
> [1] http://en.wikipedia.org/wiki/Lab_color_space
> [2] http://www.mathworks.com/matlabcentral/fileexchange/29702

Thanks for the info, maybe it helps.

Am 21.11.2011 11:32, schrieb Nicolai Hähnle:
 > As long as the colors are assigned dynamically, a mix of both 
approaches is
 > the best: keep an array of around 50 or so colors, but order them 
such that
 > the first 5 to 10 colors are clearly distinguishable, i.e. start with 
primary
 > colors, continue with a few colors that are clearly distinct, and 
then later
 > go into shades that may be harder to distinguish.

I will implement the dynamic color picking, but I wont limit the allowed 
active wares. So I will do it like Nicolai suggested it ;)

Am 20.11.2011 18:52, schrieb Wolf Steinmetz:
 > Borim, --- it's not easy to find 50 suitable colors; I have tried and
 > reduced it to 20.
 > And even that is not easy to tell apart with thin lines on a light
 > patterned background.

I have played a little with the colors and it is much difficult, than I 
thought.
@Astuur If you have allready picked 20 colors, can you please give me 
the color codes?

Cheers Matthias (Borim)

Off-topic regarding the widelands (future) implementation, but very
on-topic regarding color perception:

http://blog.xkcd.com/2010/05/03/color-survey-results/

I wish for at least using "shark infested water blue" at some points in the
WL ui ;)

Regards,
Tino

2011/11/22 Borim <borim7@...>

> Hey,
>
> Am 21.11.2011 12:42, schrieb Holger Rapp:
> > [1] http://en.wikipedia.org/wiki/Lab_color_space
> > [2] http://www.mathworks.com/matlabcentral/fileexchange/29702
>
> Thanks for the info, maybe it helps.
>
> Am 21.11.2011 11:32, schrieb Nicolai Hähnle:
>  > As long as the colors are assigned dynamically, a mix of both
> approaches is
>  > the best: keep an array of around 50 or so colors, but order them
> such that
>  > the first 5 to 10 colors are clearly distinguishable, i.e. start with
> primary
>  > colors, continue with a few colors that are clearly distinct, and
> then later
>  > go into shades that may be harder to distinguish.
>
> I will implement the dynamic color picking, but I wont limit the allowed
> active wares. So I will do it like Nicolai suggested it ;)
>
> Am 20.11.2011 18:52, schrieb Wolf Steinmetz:
>  > Borim, --- it's not easy to find 50 suitable colors; I have tried and
>  > reduced it to 20.
>  > And even that is not easy to tell apart with thin lines on a light
>  > patterned background.
>
> I have played a little with the colors and it is much difficult, than I
> thought.
> @Astuur If you have allready picked 20 colors, can you please give me
> the color codes?
>
> Cheers Matthias (Borim)
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public
>

Hi

I love this idea, but the user should be able to customize the colors set if 
he doesn't like the default one.
Don't forget that many people are daltonians : 
http://en.wikipedia.org/wiki/Daltonian (5 to 10% of the males).
We'll surely have many daltonians players.

My 2 cents.

HalfWolf

----- Original Message ----- 
From: "Nicolai Hähnle" <prefect_@...>
To: <widelands-public@...>
Sent: Monday, November 21, 2011 11:32 AM
Subject: Re: [Widelands-public] plot line colors of ware statstics menu


> On Sunday 20 November 2011 18.52:30 Wolf Steinmetz wrote:
>> Am 20.11.2011 18:04, schrieb Borim:
>> > Maybe with the dynamic approach the plot line looks a little better, 
>> > but
>> > a well designed static color distribution should also looks nice. And I
>> > think with about 50 colors it should be not so hard to create a good
>> > color distribution;)
>>
>> Borim, --- it's not easy to find 50 suitable colors; I have tried and
>> reduced it to 20.
>> And even that is not easy to tell apart with thin lines on a light
>> patterned background.
>>
>> For all practical consideration reducing the simultainiously available
>> colors to 5 -> 10 seems
>> quite generous to me and more than enough.
>
> As long as the colors are assigned dynamically, a mix of both approaches 
> is
> the best: keep an array of around 50 or so colors, but order them such 
> that
> the first 5 to 10 colors are clearly distinguishable, i.e. start with 
> primary
> colors, continue with a few colors that are clearly distinct, and then 
> later
> go into shades that may be harder to distinguish.
>
> The further down the list you go, the harder they become to distinguish, 
> but
> that's okay: those colors will only be used when the player selects that 
> many
> wares - so then it's "their own fault".
>
> cu,
> Nicolai
> -- 
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public

On Wednesday 23 November 2011 23.01:34 HalfWolf wrote:
> I love this idea, but the user should be able to customize the colors set
> if he doesn't like the default one.
> Don't forget that many people are daltonians :
> http://en.wikipedia.org/wiki/Daltonian (5 to 10% of the males).
> We'll surely have many daltonians players.

Three points:

1. We should strive to make the **default** colors appropriate for colorblind 
people. It is a stupid reflex to immediately suggest customizability because of 
an accessibility issue like that. Making the colors better for colorblind 
people does *not* make them worse for normally sighted people (though I am 
open to be convinced otherwise if you actually come forward with some 
studies). Given that, why not just go with those better colors **by default**?

(I'm sorry, I'm just a bit allergic to these kinds of suggestions because they 
are so horribly common in the open source world. Adding configuration options 
when it is **clearly** better to just change the default setting is part of 
the reason why so much open source UI traditionally sucks.)

2. I am **absolutely** against making this configurable in the UI itself. It 
would be another barely tested codepath, i.e. a maintenance nightmare.

3. We could consider loading the color list from a file (e.g. run a LuA script 
at startup that returns the list of colors).

cu,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

Hi,


> 
> 1. We should strive to make the **default** colors appropriate for colorblind 
> people. It is a stupid reflex to immediately suggest customizability because of 
> an accessibility issue like that. Making the colors better for colorblind 
> people does *not* make them worse for normally sighted people (though I am 
> open to be convinced otherwise if you actually come forward with some 
> studies). Given that, why not just go with those better colors **by default**?

I agree fully here. Generally UI interfaces should be high contrast - working in the CSV colorspace makes it easier to find distinguishable colors that are recognizable for most people. Defaults should consider daltonians.

> 
> (I'm sorry, I'm just a bit allergic to these kinds of suggestions because they 
> are so horribly common in the open source world. Adding configuration options 
> when it is **clearly** better to just change the default setting is part of 
> the reason why so much open source UI traditionally sucks.)
I also agree here: We have in the past been under the spell of optioneritis but have since been cured: Options are a last way out, working the default to be the best it can be for most people is the better way and keeps our feature set focused. There are quite some projects that died of optioneritis imho (e.g. Inkscape).
 
> 
> 2. I am **absolutely** against making this configurable in the UI itself. It 
> would be another barely tested codepath, i.e. a maintenance nightmare.
see above. Agree fully!

> 3. We could consider loading the color list from a file (e.g. run a LuA script 
> at startup that returns the list of colors).
I think this should not be necessary: the graphics we bring with the game are more or less fixed so we can also fix the "best colors" that match them. 

+1 for hardcoding a good set of colors into the code.

Cheers,
Holger

Hi,

My point was just to bring your attention to color blindness which concerns 
a lot of widelands players.
No matter the solution used. BUT the missing color is not the same for all.
If you want to create a common default set for people who don't see red, 
people who don't see blue and people who don't see green, I wish you good 
luck.

I'm not daltonian, I'm a developper and I can bet that, as me, the first 
colors you would have used are red, green and blue.



----- Original Message ----- 
From: "Holger Rapp" <HolgerRapp@...>
To: <widelands-public@...>
Sent: Saturday, November 26, 2011 1:26 PM
Subject: Re: [Widelands-public] plot line colors of ware statstics menu


> Hi,
>
>
>>
>> 1. We should strive to make the **default** colors appropriate for 
>> colorblind
>> people. It is a stupid reflex to immediately suggest customizability 
>> because of
>> an accessibility issue like that. Making the colors better for colorblind
>> people does *not* make them worse for normally sighted people (though I 
>> am
>> open to be convinced otherwise if you actually come forward with some
>> studies). Given that, why not just go with those better colors **by 
>> default**?
>
> I agree fully here. Generally UI interfaces should be high contrast - 
> working in the CSV colorspace makes it easier to find distinguishable 
> colors that are recognizable for most people. Defaults should consider 
> daltonians.
>
>>
>> (I'm sorry, I'm just a bit allergic to these kinds of suggestions because 
>> they
>> are so horribly common in the open source world. Adding configuration 
>> options
>> when it is **clearly** better to just change the default setting is part 
>> of
>> the reason why so much open source UI traditionally sucks.)
> I also agree here: We have in the past been under the spell of 
> optioneritis but have since been cured: Options are a last way out, 
> working the default to be the best it can be for most people is the better 
> way and keeps our feature set focused. There are quite some projects that 
> died of optioneritis imho (e.g. Inkscape).
>
>>
>> 2. I am **absolutely** against making this configurable in the UI itself. 
>> It
>> would be another barely tested codepath, i.e. a maintenance nightmare.
> see above. Agree fully!
>
>> 3. We could consider loading the color list from a file (e.g. run a LuA 
>> script
>> at startup that returns the list of colors).
> I think this should not be necessary: the graphics we bring with the game 
> are more or less fixed so we can also fix the "best colors" that match 
> them.
>
> +1 for hardcoding a good set of colors into the code.
>
> Cheers,
> Holger
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public

Hi,

> My point was just to bring your attention to color blindness which concerns 
> a lot of widelands players.
> No matter the solution used. BUT the missing color is not the same for all.
> If you want to create a common default set for people who don't see red, 
> people who don't see blue and people who don't see green, I wish you good 
> luck.
:) . Luninosity and saturation are two parameters which should be always usable (of course only one should be varied). Of course it would be even better to have something more than just colors to differentiate parameters.

However I do not see such a big issue with the graphs for the reason that the user can activate and deactive them in any order and knows which line has apperead when. This also allows for associating ware to line. Colors are just more intuitive - but maybe only for non color blind people, who knows?

Cheers,
Holger
> 
> ----- Original Message ----- 
> From: "Holger Rapp" <HolgerRapp@...>
> To: <widelands-public@...>
> Sent: Saturday, November 26, 2011 1:26 PM
> Subject: Re: [Widelands-public] plot line colors of ware statstics menu
> 
> 
>> Hi,
>> 
>> 
>>> 
>>> 1. We should strive to make the **default** colors appropriate for 
>>> colorblind
>>> people. It is a stupid reflex to immediately suggest customizability 
>>> because of
>>> an accessibility issue like that. Making the colors better for colorblind
>>> people does *not* make them worse for normally sighted people (though I 
>>> am
>>> open to be convinced otherwise if you actually come forward with some
>>> studies). Given that, why not just go with those better colors **by 
>>> default**?
>> 
>> I agree fully here. Generally UI interfaces should be high contrast - 
>> working in the CSV colorspace makes it easier to find distinguishable 
>> colors that are recognizable for most people. Defaults should consider 
>> daltonians.
>> 
>>> 
>>> (I'm sorry, I'm just a bit allergic to these kinds of suggestions because 
>>> they
>>> are so horribly common in the open source world. Adding configuration 
>>> options
>>> when it is **clearly** better to just change the default setting is part 
>>> of
>>> the reason why so much open source UI traditionally sucks.)
>> I also agree here: We have in the past been under the spell of 
>> optioneritis but have since been cured: Options are a last way out, 
>> working the default to be the best it can be for most people is the better 
>> way and keeps our feature set focused. There are quite some projects that 
>> died of optioneritis imho (e.g. Inkscape).
>> 
>>> 
>>> 2. I am **absolutely** against making this configurable in the UI itself. 
>>> It
>>> would be another barely tested codepath, i.e. a maintenance nightmare.
>> see above. Agree fully!
>> 
>>> 3. We could consider loading the color list from a file (e.g. run a LuA 
>>> script
>>> at startup that returns the list of colors).
>> I think this should not be necessary: the graphics we bring with the game 
>> are more or less fixed so we can also fix the "best colors" that match 
>> them.
>> 
>> +1 for hardcoding a good set of colors into the code.
>> 
>> Cheers,
>> Holger
>> 
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Widelands-public mailing list
>> Widelands-public@...
>> https://lists.sourceforge.net/lists/listinfo/widelands-public 
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Widelands-public mailing list
> Widelands-public@...
> https://lists.sourceforge.net/lists/listinfo/widelands-public