About those vector icons (2011)(pushing-pixels.org)
pushing-pixels.org
About those vector icons (2011)
https://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html
26 comments
Design has changed a lot in the last 9 years to the point where I don’t know if a lot of this still applies.
I’ll also highlight the concept of designing for the medium; it might make more sense to create a design that does seamlessly scale without manual involvement than to do the designer’s first idea and then manually tweak that to work in every possible variation.
Given that much of the time svg is perfectly reasonable, I wish platforms had better support - I’ve found Xamarin.Forms, UWP, WPF, and native iOS all wanting. Web seems to be about the only place it works seamlessly nowadays.
Also, if anyone in the Windows desktop team is here, please support SVG desktop backgrounds. Often my desktop is vector art and I’d like to skip the jpg middle man and get something that scales to all my monitors well by default. You were somehow weirdly on the right track with the Windows 8 start backgrounds fwiw.
I’ll also highlight the concept of designing for the medium; it might make more sense to create a design that does seamlessly scale without manual involvement than to do the designer’s first idea and then manually tweak that to work in every possible variation.
Given that much of the time svg is perfectly reasonable, I wish platforms had better support - I’ve found Xamarin.Forms, UWP, WPF, and native iOS all wanting. Web seems to be about the only place it works seamlessly nowadays.
Also, if anyone in the Windows desktop team is here, please support SVG desktop backgrounds. Often my desktop is vector art and I’d like to skip the jpg middle man and get something that scales to all my monitors well by default. You were somehow weirdly on the right track with the Windows 8 start backgrounds fwiw.
“Design has changed a lot in the last 9 years to the point where I don’t know if a lot of this still applies.”
I think it still applies. In my experience, as we’ve gone far away from skeuomorphic design (hey, it’s 2011 in the title, we can use that word), having those nice razor sharp minimalistic icons at 20pt/dp or smaller sizes means you do want to draw them with care. You can notice the slop when something doesn’t fall on a nice integer position.
Especially as we still are not in a fully HiDPI world. I came across this the other day when I was trying to create an icon for a 5×5 matrix. Looked great on my MacBook Pro screen. And then I dragged it to my external display that I keep for testing. And oh. Yikes. I needed to tighten things up.
I think it still applies. In my experience, as we’ve gone far away from skeuomorphic design (hey, it’s 2011 in the title, we can use that word), having those nice razor sharp minimalistic icons at 20pt/dp or smaller sizes means you do want to draw them with care. You can notice the slop when something doesn’t fall on a nice integer position.
Especially as we still are not in a fully HiDPI world. I came across this the other day when I was trying to create an icon for a 5×5 matrix. Looked great on my MacBook Pro screen. And then I dragged it to my external display that I keep for testing. And oh. Yikes. I needed to tighten things up.
All images, included png and jpeg ones, are first internally (re)converted to jpeg when assigned to the Windows background. The default conversion quality factor is 80 (for no good reason). You can change it to 100 in the registry: HKEY_CURRENT_USER\Control Panel\Desktop\JPEGImportQuality
JPEG? Please tell me you're not forced to use lossy raster graphics for vector art? A PNG render of at least the resolution of your largest screen should be fine.
A lot of this could be solved by more clever formats. The printer icon, for example, just needs the lines to not be scaled or, in other words, be treated as lines, not areas. A lot of this stuff is extremely well known in the realm of typography and graphic designers would do well to learn from it.
"Fonts" appears frequently in this piece, without noting that the design actually changes at different scales. This is more than hinting.
When I walk into a hardware store planning to appropriate some part for a different purpose than intended, my first question is "who has this problem?"
I've been exploring mind-mapping software. It's astonishing how primitive the namespace handling can be. Shades of the flat file system from a 1984 Macintosh (mine had an early serial number). Same question: Who understands this issue? Programming language designers. Everyone else is just guessing.
Fonts change design at different scales.
When I walk into a hardware store planning to appropriate some part for a different purpose than intended, my first question is "who has this problem?"
I've been exploring mind-mapping software. It's astonishing how primitive the namespace handling can be. Shades of the flat file system from a 1984 Macintosh (mine had an early serial number). Same question: Who understands this issue? Programming language designers. Everyone else is just guessing.
Fonts change design at different scales.
Can an SVG (or similar) change design at different scales? It seems like at least a good portion of the challenges described in this article would be solved if so.
And it seems like a solution to excessive aliasing (in the sense of a dark thin line rendering as a not-so-dark double-wide line) could be to round the desired size down to the nearest known-good size and pad the edges with negative space.
And it seems like a solution to excessive aliasing (in the sense of a dark thin line rendering as a not-so-dark double-wide line) could be to round the desired size down to the nearest known-good size and pad the edges with negative space.
CSS in SVG supports media queries[0] so it's entirely possible to change the display of elements depending on the size of rendered image. You could have fills, stroke widths, or whole elements change properties at particular size break points[1]. At small sizes you can use thin strokes and solid fills and larger sizes thicker/varied stroke widths and gradient/pattern fills.
[0] https://www.sitepoint.com/using-svg-with-media-queries/
[1] https://css-tricks.com/svg-properties-and-css/
[0] https://www.sitepoint.com/using-svg-with-media-queries/
[1] https://css-tricks.com/svg-properties-and-css/
Although this may seem like the right way to handle lower resolutions it suffers from the fact that, in practice, you will be turning a whole bunch of css levers and knobs to get to get a small number of pixels to turn the right colour. It’s a complicated and roundabout way of doing things. It would be better just to have an svg for 64px and above and a set hand drawn png images for the smaller icons. No fancy new image format, maybe just a decent naming convention or zip file per image set. Should only be 64px.svg 32px.png 24px.png and 16px.png. You may even be able to skip the 24px version.
Using media queries in SVG isn't just about getting a few pixel colors correct. In terms of total expenses effort, an SVG that looks right at small sizes with media queries isn't much more effort than making raster versions of the graphics.
A single good SVG can obviate your small raster images and the 2x and 3x versions you might need for HiDPI screens. You can also get automatic handling of dark mode with no changes to your page's CSS.
There's work involved but the flexibility is pretty awesome.
A single good SVG can obviate your small raster images and the 2x and 3x versions you might need for HiDPI screens. You can also get automatic handling of dark mode with no changes to your page's CSS.
There's work involved but the flexibility is pretty awesome.
That’s a good point you made about theming.
SVGs can respond to their size, yes -- essentially the same way websites can -- see https://codepen.io/pjwdev/pen/dypVLgg
In addition, vector-effect="non-scaling-stroke" allows you do declare that a line is [eg] 1px thick, regardless of the image size.
Snapping to sizes would be possible, but not straightforward, until CSS supports calc(round()) https://www.w3.org/TR/css-values-4/#round-func
In addition, vector-effect="non-scaling-stroke" allows you do declare that a line is [eg] 1px thick, regardless of the image size.
Snapping to sizes would be possible, but not straightforward, until CSS supports calc(round()) https://www.w3.org/TR/css-values-4/#round-func
For me, the lack of smooth transition between scales is a larger cost than the benefits presented in the article.
It feels surprising to see such a limitation on my Modern apple devices, for example, when I change scale and everything violently snaps to refit.
It feels surprising to see such a limitation on my Modern apple devices, for example, when I change scale and everything violently snaps to refit.
In my mind, this is just an argument for 8K monitors and subpixel rendering for SVG, the same as with fonts.
Agreed in a theoretical sense, but how would you handle the physically small icons where removing some of the content is needed (like some of the examples in the article)? Our eyes can only see so small, even if in perfect detail (think about the small print on chargers).
The problem with this is that you then have to drive that 8k, or multiple 8k, monitors which is a problem if you're doing anything visually complex. As someone who straddles the programming / visual arts world (I write plugins for 3D modelling software) I actually spend most of my time having to use "low resolution" (1080p or 1440p) because I'm dealing with complex polygon models with tens of millions of polys and scenes with sometimes thousands of objects in them. You get a similar problem with games or doing video editing. It also doesn't address the problem that there's a limit to people's visual acuity (especially as they get older as I'm rapidly discovering at 40) so you still have to make icons "bolder" and change details as the article addresses as they get smaller to make them more "readable".
appropriate suggestion for your username.
The tradeoff between a little bit or human touch and effort upfront vs higher energy and CO2 expenditure overall is not something I find personally compelling
The tradeoff between a little bit or human touch and effort upfront vs higher energy and CO2 expenditure overall is not something I find personally compelling
Higher resolution monitors do not necessarily draw much more power! Most of the energy goes into the backlight, which is largely constant irrespective of the resolution of the LCD panel in front. Similarly with OLED, the power consumed is mostly a function of the total lumens the panel puts out, not the size of the individual pixels.
You'd need more powerful video cards, sure, but for typical 2D graphics, the difference is on the order of 5-10W, which isn't exactly going to boil the oceans...
You'd need more powerful video cards, sure, but for typical 2D graphics, the difference is on the order of 5-10W, which isn't exactly going to boil the oceans...
This is a good use case for deep learning.
Or retina displays.
> Or retina displays.
More pixels only addresses the blurriness caused by a display's low resolution. The other side of the problem is the limitations and quirks of human vision, which require a different set of adjustments to increase legibility at small sizes. And arguably, increasing resolution can make everything smaller (esp. if there isn't a 'High DPI' setting, and so makes the size problem even more urgent.
The design adjustments needed by icons at small sizes are closely related to optical sizing in fonts (increasing x-height, lower contrast, heavier weight, large terminals and serifs are shrunk, small ones enlarged, etc.), except that an icon's topology ofyen needs to change as well.
A simple example is that if a large icon features a 3x4 grid as a design element, at small sizes it may need to be a 2x3 grid instead, the point being that the grid-ness of the design element is the important part, not the specific number of rows and columns.
Other design elements may just need to be removed entirely (such as digits or division markers on a clock face).
These sorts of 'optical icon adjustments' (I'm not aware of any other term for them) are really important for icons, perhaps more important than optical adjustments to fonts, since icons are less familiar and so are harder to recognize.
In summary, increasing the resolution of the display only solves half the problem (and often makes the other half harder).
More pixels only addresses the blurriness caused by a display's low resolution. The other side of the problem is the limitations and quirks of human vision, which require a different set of adjustments to increase legibility at small sizes. And arguably, increasing resolution can make everything smaller (esp. if there isn't a 'High DPI' setting, and so makes the size problem even more urgent.
The design adjustments needed by icons at small sizes are closely related to optical sizing in fonts (increasing x-height, lower contrast, heavier weight, large terminals and serifs are shrunk, small ones enlarged, etc.), except that an icon's topology ofyen needs to change as well.
A simple example is that if a large icon features a 3x4 grid as a design element, at small sizes it may need to be a 2x3 grid instead, the point being that the grid-ness of the design element is the important part, not the specific number of rows and columns.
Other design elements may just need to be removed entirely (such as digits or division markers on a clock face).
These sorts of 'optical icon adjustments' (I'm not aware of any other term for them) are really important for icons, perhaps more important than optical adjustments to fonts, since icons are less familiar and so are harder to recognize.
In summary, increasing the resolution of the display only solves half the problem (and often makes the other half harder).
If you have a Mac, try making the Dock the smallest possible size. Those icons are just scaled down from the larger versions, and they can be hard to make out sometimes.
Even on high-res displays, small versions of icons would benefit from separately made versions that leaves out some detail.
Even on high-res displays, small versions of icons would benefit from separately made versions that leaves out some detail.
HVIF supports only basic shapes with integer coordinates (by default) and detail reduction. Each shape is tagged with a minimum and maximum scale³--computed from a base icon size of 64x64--at which it should be visible. Rounding and hinting bring those shapes within tossing distance of custom-drawn icons at small scales.
¹ Leah Hanson's post is quite illuminating, though it focuses more on the small on-disk size of HVIF data; http://blog.leahhanson.us/post/recursecenter2016/haiku_icons...
² https://web.archive.org/web/20070111153750/http://haiku-os.o...
³ "stippi"'s original announcement: https://www.freelists.org/post/haiku/Icon-Artwork