Rewrote the Icons page with the following goals in mind:
Also adjusted the Emblems page to point to the new icons page, where applicable.
Your best bet is probably to compile it and read the pages yourself (see
https://hig.kde.org/resources/contribute.html#getting-started)
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Some thoughts:
I think it's better to start with the smallest icon you have to make because it leads to a more consistent design for each size. Should we mention monochrome icons first because of that and is what I think generally true in the first place?
In addition, colorful icons have a 1 px hard shadow on the bottom:
This is not always true. 32px preference icons don't have a hard shadow on the bottom. Most 32px preference icons don't have a 1px hard shadow at the bottom and some 32px category icons. Are you suggesting that all color icons have a 1px hard shadow from now on?
The monochrome style relies on distinct shapes and outlines instead of fine details and vibrant colors, and employs an intentionally limited color palette:
- Icon Grey: Used for icons in a normal state and non-destructive actions: back, forward, ok, home, etc. This is the most commonly used color. When in doubt, choose Icon Grey.
- Icon Red: Used for icons that depict actions: delete, remove, stop, etc.
- Icon Orange: Used for icons that involve user input of some kind.
- Icon Blue: Used for icons that involve the action “select” or “insert”.
- Icon Yellow: Used for icons that involve a “warning” state or some sort.
- Icon Green: Used to for icons that involve “connected”, “secure” or “successful” actions.
This is generally not true. Currently, the only Icon colors that are commonly used for monochrome icons are Icon Grey, Icon Red and Icon Yellow (hardcoded). Plasma Blue, Beware Orange and Noble Fir are generally used in place of Icon Blue, Icon Orange and Icon Green. Icon Grey is usually replaced with a color close to Shade Black or Cardboard Grey because of the Breeze and Breeze Dark colorschemes. There is also the undocumented #f2f2f2 color which is effectively Icon White used in Breeze Dark. Even if we did start using the icon colors, they would have to be hardcoded or they would be replaced with the colors that are currently used.
16px and 22px Emblems get a 50% opacity outline to ensure adequate contrast against whatever icon they are drawn on top of:
It's actually 60% opacity.
An emblem that indicates unread notifications should take the form of a light-colored number inside a blue circle. The circle can become “pill-shaped” if the number is very large.
These are not actually icons, so they don't really belong here.
The new icon to show video, it reminds me heavily about VLC. Are we going with that design?
That is the current VLC icon. :)
Okay, that makes sense.
In addition, colorful icons have a 1 px hard shadow on the bottom:
This is not always true.
32px preference icons don't have a hard shadow on the bottom.Most 32px preference icons don't have a 1px hard shadow at the bottom and some 32px category icons. Are you suggesting that all color icons have a 1px hard shadow from now on?
I was not able to find a type of colorful icon that consistently lacked bottom shadows. As you say, some of the 32px preferences icons have them. Same with the 32px category icons. All of the 32px Places and MIME type icons get bottom shadows. It seemed simpler to just make a blanket rule, because right now there is really no consistency at all, let alone a logical way to say "here's the reason why this gets a bottom shadow, but that doesn't."
The monochrome style relies on distinct shapes and outlines instead of fine details and vibrant colors, and employs an intentionally limited color palette:
- Icon Grey: Used for icons in a normal state and non-destructive actions: back, forward, ok, home, etc. This is the most commonly used color. When in doubt, choose Icon Grey.
- Icon Red: Used for icons that depict actions: delete, remove, stop, etc.
- Icon Orange: Used for icons that involve user input of some kind.
- Icon Blue: Used for icons that involve the action “select” or “insert”.
- Icon Yellow: Used for icons that involve a “warning” state or some sort.
- Icon Green: Used to for icons that involve “connected”, “secure” or “successful” actions.
This is generally not true. Currently, the only Icon colors that are commonly used for monochrome icons are Icon Grey, Icon Red and Icon Yellow (hardcoded). Plasma Blue, Beware Orange and Noble Fir are generally used in place of Icon Blue, Icon Orange and Icon Green. Icon Grey is usually replaced with a color close to Shade Black or Cardboard Grey because of the Breeze and Breeze Dark colorschemes. There is also the undocumented #f2f2f2 color which is effectively Icon White used in Breeze Dark. Even if we did start using the icon colors, they would have to be hardcoded or they would be replaced with the colors that are currently used.
So what's the take-home message here? What should this section say instead?
16px and 22px Emblems get a 50% opacity outline to ensure adequate contrast against whatever icon they are drawn on top of:
It's actually 60% opacity.
OK, will fix.
An emblem that indicates unread notifications should take the form of a light-colored number inside a blue circle. The circle can become “pill-shaped” if the number is very large.
These are not actually icons, so they don't really belong here.
Sure, I can move that section back to the Emblems page.
I'm not sure. It depends on whether or not we want to edit most of the existing monochrome icons. I kind of agree that we should have some standard colors just for icons, but how would that work with colorschemes? Icon Orange and Icon Green are not used in Breeze or Breeze Dark and only Breeze uses Icon Yellow for Link Text (Selection, not Main) and Neutral Text (Complementary, not Main). Should we also change the Breeze and Breeze Dark colorschemes? Should we just start hardcoding colors?
Here's what would require the least amount of work, but I don't know if it's what we should aim for:
Something that would be good to have linked to an HIG about icons would be a comprehensive list of colors that should be used for icons. I know we already a bunch of them in the colors category, but if we don't make colors that are just for icons and not for widgets, we will end up with poor contrast and the amount of usable colors will be lacking. Maybe it shouldn't necessarily be in this section, but we need to make some primary/secondary colors just for icons and have different shades of those colors.
Actually, the 8px emblem icons at the very bottom of the page look blurry. Are you sure you took that screenshot with them at 100% size?
You caught me: I took them at 16x16 (the smallest size in Dolphin) and scaled them down. I'll stop cheating and do it right. :)
| source/style/icon.rst | ||
|---|---|---|
| 301 | Actually only 5, 7, and 8 have no color at all. I deliberately wanted to show a mix; if all the icons in this image here had color, it might be interpreted to imply that status icons should always have some color. Not all status icons do, and that's acceptable. | |
| source/style/icon.rst | ||
|---|---|---|
| 46–47 | Typo: Monochome -> Monochrome | |
Change Icon Blue to Plasma Blue just so it matches reality. Simply saying we should use Icon Blue isn't a good thing to do right now since we don't have a way to make it actually use Icon Blue. It would only cause confusion. This is something we're going to have to find a way to fix once and for all, but that discussion needs to happen on a task that can reach multiple projects, not a diff for the HIG.
Should 32px monochrome icons have a different margin from 32px color icons? Currently, all of the 32px monochrome action icons use 4px margin on each side instead of 2px.
Consistent as in all 32px icons have 2px margins (this requires a lot of changes to 32px action icons) or consistent with how things currently are with the differences between monochrome and color 32px icons (a bit less straight forward, not currently in the HIG, fewer changes)?
Consistent with how we want it. I think it's okay if a change to the HIG results in some thing being incorrect until it's fixed. Better that than to enshrine a thousand exceptions in the HIG.
You're probably right.
I'm don't think anything else needs to be added to this diff. It'll need more edits in the future as we find solutions to our color consistency issues, but we don't have those solutions right now.