Wrench icon is removed in this icon but still valid for pin icon.

https://projects.kde.org/projects/kde/workspace/plasma-workspace/repository/revisions/5010e854f3f62e73c2525d013c35cc059ef25eeb

s/this icon/this commit

Git commit 1f4e72e618b5fe12d2a1cbcaf3d7e2df3adf9838 by David Edmundson.
Committed on 17/06/2014 at 14:12.
Pushed by davidedmundson into branch 'master'.

Use standard icon sizes

iconSize.small/2 is really wrong. If we randomly scale things what's the
point of having an iconSize property in the first place.

M  +1    -1    applets/systemtray/package/contents/ui/ExpandedRepresentation.qml

http://commits.kde.org/plasma-workspace/1f4e72e618b5fe12d2a1cbcaf3d7e2df3adf9838

eww, it looks really bad now, that pin icon makes sense when is small enough to not alter the whole balance of the window.
now the first thing the eye is drawn to, is that control of secondary secondary importance that screams look at me :/
(also, it has no right/top margins that should have, and would take even more space)

iconSize.small/2 *does* make sense there, maybe the mousearea around can be bigger to make it easy to hit, but right now it ruins the whole dialog

Then we should make an iconSize.extraSmall.

Taking a constant and scaling it by a random factor, defeats the entire point of the constants.

it's a ratio of a constant, correctly follows dpi and such

If iconSize.small is too large, maybe an iconSize.tiny (which is something between small and small/ in size) is needed?
I'd expect the icon to be the same size as the icons in the window decoration icons, because it has a very similar function.
Let our designers decide on the exact size. What counts for me is mostly that you don't need to be a surgeon to click the button.

The interactive area of the icon can be as big as we want, it doesn't have to be the same size as the icon.

I meant between small and small/2, of course.

From an HIG perspective, using ratios of constants is a bad idea. For consistency, it makes sense that developers only use the constants, then if the VDG decides that a class of icons should have a different size, we can ask you to change the constant while being sure that everything remains consistent.
If people start multiplying/dividing the constant during implementation as they see fit, that consistency is lost.

Therefore I am for introducing another size, smaller than "small", and let the VDG decide what size that is.

(In reply to comment #8)
> The interactive area of the icon can be as big as we want, it doesn't have
> to be the same size as the icon.

Unless the interactive area is visible, users would still try to click the actual icon, so while a bigger interactive area would make missing it less likely, it would not make the aiming less difficult.

The only source on minimum sizes for clickable elements for mouse-oriented UIs I could find is the Microsoft UX Guide, which says "Make click targets at least 16x16 pixels so that they can be easily clicked by any input device"

I think was quite happy with the look and feel and interaction so far, with the smaller icons. It doesn't feel tedious for me.

The buttons do actually have visual feedback when the interactive area is entered, there's a subtle animation improving contrast for of the icon. I'm not sure the interactive area is big enough yet, though. Perhaps we can pronounce that animation a bit more to make it more discoverable? How well that animation is visible also depends a bit on the contrast and quality of the display.

I don't think the Microsoft UX guideline is very useful here, to be honest. Input devices are too different to use one size for "any input device", and 16x16 is definitely too small on a reasonable DPI display to be usable with a touchscreen. Expressing it in pixel dimensions is wrong to begin with.

(In reply to comment #11)
> I think was quite happy with the look and feel and interaction so far, with
> the smaller icons. It doesn't feel tedious for me.

On my screen (see the linked screenshot) it just looked really weird because everything was quite large and the pin was really tiny.

> The buttons do actually have visual feedback when the interactive area is
> entered, there's a subtle animation improving contrast for of the icon. I'm
> not sure the interactive area is big enough yet, though. Perhaps we can
> pronounce that animation a bit more to make it more discoverable? How well
> that animation is visible also depends a bit on the contrast and quality of
> the display.

To be honest, I haven't tried the animation out yet. Will report back after trying another Neon 5 ISO.

> I don't think the Microsoft UX guideline is very useful here, to be honest.
> Input devices are too different to use one size for "any input device", and
> 16x16 is definitely too small on a reasonable DPI display to be usable with
> a touchscreen. Expressing it in pixel dimensions is wrong to begin with.

I deliberately only copied the bit about pointer-based interaction because we're talking about Plasma Desktop. For touch, "recommended minimum control size is 23x23 pixels (13x13 DLUs). " (with DLUs being a DPI-independent measure).

"The buttons do actually have visual feedback when the interactive area is entered, there's a subtle animation improving contrast for of the icon. I'm not sure the interactive area is big enough yet, though. Perhaps we can pronounce that animation a bit more to make it more discoverable? How well that animation is visible also depends a bit on the contrast and quality of the display."
About the hover animation, to be more obvious when i made some improvements on the CSS support i had an idea, that is still on hold..
It would be now possible (after adding some api to Svg tough) to animate the monochrome icons from black to highlight color (so the blue-ish) and that would be in general for mouseover of svg based icons
it may probably look bad tough, i'm not sure

> It would be now possible to animate the monochrome icons from black to highlight color

Let's try it? Fwiw, given how small the icon is, the current animation is barely noticeable for me. Alternatively it could be scaled when hovered but _that_ might look bad.

I just tried it out, but the color change from black to blue in such a tiny icon is barely noticeable, I'm afraid. Can't we e.g. darken the whole mouse area a bit when hovering over it? that way it would be consistent with buttons and much more visible.

Indeed, I always find myself clicking multiple times because the transition from gray to blue takes quite some time.

The icon is now using small icon size with a proper ToolButton, ie. it gets proper hover/press feedback and a larger hit area than the icon