Comments on new icon set: I - Colours

• May 12, 2013 - 10:27

This is intended as a place to discuss the new icon set currently under development.

Firs of all, thanks to TinMan for the hard work! His proposal is a great improvement on the previous situation, grown a bit casually over the years.

Inevitably, a first proposal is not a finished work and any given solution will not please everyone. So, I will mainly focus on aspects needing, in my opinion, further attention.

I have split the topic in two, expecting that different parts will attract different kinds of comments. This part is about

Icon colours

The current set is basically bi-tonal and uses a mildly light shade of gray, with a darker shade used as a second level in some icons. The bi-tonal choice is of sure effect: clean and appealing.

The choice of shades, IMHO, can be improved. The human eye bases shape recognition mainly on contrast, so contrast should be maximized to help shape recognition. This is even more true for a bi-tonal theme like this one. Thus:

1) The main colour should be white, not gray.
2) The darker shade could also be lightened.

Some objections to this have already been raised.

A) "The default background of most drawing programs being white, working with white on white is cumbersome: developing a white set would be difficult."

I agree, but this is a consequence of the light-on-dark theme chosen. I am not an expert of drawing programs, but I am confident that it is possible to set a dark background with most of them. And this for other important reasons:

- white and black (or light and dark) are not opposite, they have side effects; one of them tend to spread -- physically and/or optically -- into the other (on paper usually black spreads into white, on screen I think white spreads into black);

- human pattern recognition is not neutral with respect to foreground-background luminance relationship (light patterns on dark background may be recognized differently, or from different details, than the opposite). Again, this is emphasized by the bi-tonal choice.

- all of this is also dependent upon the resolution: the lower the resolution the greater the spreading and the fuzzy the pattern recognition; this may make sub-optimal even using the same shapes with the same colours on greatly different media resolutions;

The net result is that any work should be done with the real, final background and foreground or unexpected results may arise (and usually do).

B) "Current colours may be just 'place-holders' to be replaced, perhaps on-the-fly, with actual colours; incidentally this would allow to generate, perhaps on demand, different sets from the same icons, maybe even a light theme, in addition to the dark one."

- This sounds intriguing, but it is not going to work for the second consideration above: a shape designed to 'look right' with light-on-dark is likely to look wrong with dark-on-light (and vice versa; not to mention the complexities and resources needed to implement such a machinery).

Thanks for reading. Comments, suggestions, anathemas are welcome.

M.

Comments

• May 13, 2013 - 16:07

I've just built the latest commit which has the new icon set.

I have criticised the Dark colour scheme elsewhere http://musescore.org/en/node/19510

And my objections still stand - the dark colour scheme looks slightly better under Windows 8 than it did in XP, but there is still the problem that you cannot tell whether a button is depressed or not.

In this screen shot you are having to peer at the icons to see which ones are selected, and this is because the entire colour scheme is too dark, thus limiting the ability to use shading to indicate a 3d representation of the icon state.
pic

Attachment Size
NewIconSet.png 39.49 KB

Reply

• May 13, 2013 - 16:49

Just to look at the other side of the coin here is a screenshot of the main toolbar in Native mode.

pic

Here you can tell at a glance which icons are selected, but as they have been designed for a white on dark UI they lack depth and substance.

What is needed for the whole UI IMO is for it to be based on a light colour so that antialiasing techniques can be brought to bear in order to give substance and depth to the icons, which should be of a darker colour.
Just to illustrate this here are light and dark renditions of the old Foto mode icon with antialiasing used to give depth and presence:

pic pic
Incidentally Tinman thank you for your hard work with this, and I hope you don't feel I'm being too negative.

I am trying to be constructive in my comments, with ideas on how to put this right.

Reply

• May 14, 2013 - 11:32

First of all, THANKS to Tinman for changing the colour scheme to (almost) white: MUCH clearer (and very fast work indeed!).

("almost" because some, (many?) of the symbols end up at a luminance of 238, only a few, like "Load", arrive at the full 255!)

@ChurchOrganist: Me too, I am not a fan of the dark theme, but it looks like this is what we will have... so, I'm trying to get the most out if it.

I totally agree with Michael's point: the greatest disadvantage of the current theme is its inability to clearly show button statuses.

However, I believe it could be improved. Even without user customizability (which would be useful, but possibly lengthy to implement), between the dark of the background and the white of icons, there is ample margin for:

- making bottom and right button borders much lighter

AND / OR

- making the background of depressed button slightly lighter.

Either (or both) would give a much more immediate perception of depressed buttons. In mstyle/colorscheme.cpp, there are several tables of colours, but I could not make head or tail of them, also because listed colours do not seem to match colours actually used in the program.

Perhaps some hint could help in locating the right spots in the sources and allow for some epxerimentation.

Thanks,

M.

P.S.: again @ChurchOrganist: your suggestion and your example seems suggestive, but I am not sure it would work: 1) to show the different volumetric shades, it requires a resolution much greater than the one usually available for icons. 2) Any but the simplest shape is likely to behave differently when put on a dark or on a light background: it is unlike that the same set of shapes would work equally well in both cases.

Reply

• May 14, 2013 - 14:17

There is one idea which would enable us to keep the dark theme and yet have better icons.

Make the icons themselves a different colour from the main work area background.

Have a look at Finale Notepad (from whence this idea was inspired) to see what I mean.

HTH
Michael

Reply

• May 15, 2013 - 15:02

I suspect this has never been done, but you can't see the difference between those icons that are enabled (from the example above: sound, midi, repeats, pan, metronome) and when they are enabled but not available (no score loaded). MuseScore Connect is in that same group, and it is always available, but they all look exactly the same.

Reply

• Jun 6, 2013 - 15:04

My brain unfortunately refuses to interpret the dark colour scheme as anything but a negative image - 60 odd years of reading black text on white have presumably stagnated it into that mode of thinking :(

I have therefore experimented with turning Tinman's new icons red, which enable me to see the icons consistently in either light or dark mode, depending on whether what I am testing requires the latter.

If you would be interested in looking at the result, you can get it from my FileFactory account here:

http://www.filefactory.com/file/56znxoiu6u4h/

It is based on an old commit (Friday 31st May) but should be enough to give you an idea of how it would look.

Reply

• Jun 7, 2013 - 09:36

Indeed :)
Here's the standard Dark theme
pic

And the same in Native theme
pic

For some reason the icons are toggling to when selected black which is not so good for the dark theme, and I had not noticed yesterday.

Could this be because the code is using Boolean operators to change the selection colour?

EDIT: A quick check with my programming calculator reveals that FF000(red) AND 19DCFF(light blue) produces a near black - 190000 so it looks as though that is the case

Attachment Size
DarkRed.png 38.29 KB
NativeRed.png 33.67 KB

Reply

Do you still have an unanswered question? Please log in first to post your question.