

About those vector icons - aaronpk
http://www.pushing-pixels.org/2011/11/04/about-those-vector-icons.html

======
emilsedgh
Oxygen icons (by KDE project) use SVG for all sizes of icons. Here is an
example:

<http://wstaw.org/m/2012/03/18/plasma-desktopA20554.png>

(The icon on the left is suited for 16x16 size. The icon in right is the same
icon, just suited for larger scales)

I think this scheme is supported by FreeDesktop.org's Icon Theme
Specifications and other icon theme's used on Linux desktops (like Tango) use
the same scheme.

~~~
kirillcool
Indeed, in that they have multiple SVG versions of the same icon (name) for
smaller pixel sizes - 16x16, 22x22, 24x24, 32x32 - the last time I checked.

~~~
dubya
That seems like the appropriate compromise, SVG for various optical sizes. The
analog example that comes to mind is Dr. Seuss books. The Cat in the Hat is
much less detailed when he is far away, and has very detailed pen work close
up.

------
nicpottier
Long but good article.

Glad he got into (and linked to the excellent article about) font hinting,
because that is of course the solution. A simple vector format is not enough,
you need to define what parts should scale how, which are rigid, which are
elastic.

I don't think higher resolution displays actually help, because the real
limitation becomes the human eye. Though the new display could use the 'old'
normal sized icons as small ones, your eye couldn't distinguish some of the
details that worked before.

Anyways, it is an interesting problem and one that I don't envy designers for.

~~~
ChuckMcM
I agree it was a fascinating look at the problem. However, the assumption in
the article is pixels. Let me sum up.

Scaling artifacts occur because at smaller _sizes_ the quantitization of the
unit pixel overwhelms the details of the image. When I was a system programmer
at the Image Processing Institute at USC (you know the source of that Lena
picture :-) this was characterized as the frequency response of the display.
So if you were to take a horizontal line across the pixels, and then plot
their intensity vertically along a line (so _x_ becomes the position in the
line, and _y_ is the intensity of the pixel at position _x_ ) then you can
then do an FFT across those pixels and see the distortion in the visual signal
from the source material to the displayed material.

Now the part that gets confounded in articles like this one is that the UX
designer doesn't really want a 16 _pixel_ icon, what they want is an icon that
has a certain size with respect to the whole screen. Working backwards, lets
say the icon ended up being 16 x 16 on a 1024 x 600 screen which had 72 pixels
per inch. The icon is about 1/4" on a side (.22" but you get the picture). Now
on a screen that that has 240 pixels per inch, that icon at 16 x 16 pixels is
only .06" or nearly impossible to see, but if you keep it at 1/4" you get 60 x
60 pixels to work with.

So lets bring two things together, you do 'hinting' because the artifacts that
are created by the quantitizing effect of pixelation cause you to lose
information. As screen resolutions get denser the information lost goes down
(less quantization, or more signal bandwidth is available) so once your signal
loss from a straight mathematical shrink is acceptable in all required sizes
your done.

Bottom line is that this won't be an issue when the minimum icon size is being
rendered into a field of 128 x 128 pixels or more. Might take one more
generation of screens.

The second thing is that while a designer can poke pixels to get an icon that
looks good, so can the computer. One of the things you can do is compute the
frequency 'footprint' of the image, then change the render until the render
foot print is as close as you can get to the original. HP did this for their
ink jet printer half-toning algorithm. In a 16 x 16 pixel space you could
almost exaustively search it on a modern machine.

~~~
kirillcool
Author of the article here.

If you read the closing paragraphs of the article, you will see that I do talk
about the physical size of the final representation of the pixel-based icon.
However, just because you can use more pixels on higher-resolution displays,
it does not mean that you can just take a highly detailed vector artwork and
display it.

Being able to display very intricate details for each icon is not necessarily
the end goal. The end goal is to preserve the clarity, which is why smaller
icons (physically, _not_ pixelwise) should have smaller amount of detail
compared to larger ones.

In your example, a 128x128px icon that occupies the same physical size on an
extra-high DPI screen as a 16x16px icon on a lower-end screen can
(mathematically) have 8 times as much detail along each axis. Just because
this is possible to do without losing the signal quality on the level of
individual pixels, does not mean that it is desirable from the UX / UI
perspective.

~~~
surrealize
You're right that in a world with varying pixel densities, it's not enough to
just design an icon for a given pixel size. But physical size isn't the right
design target either. An icon designed for a given physical size on a display
close to the user's eyes won't work if the display is much further away.

So when you go from thinking about pixel size to thinking about physical size,
you're going in the right direction, but you're not going far enough. The
relevant metric is more like "the angle subtended at the user's eyes", kinda
like how the "CSS pixel" unit works.

Now, given that it's almost impossible for software on the device to know how
far away the user is, trying to design up front for that metric (angle
subtended by the icon) is also almost impossible.

And even if you did know both the pixel density and the distance to the
display, that still doesn't take into account the fact that users will vary in
their visual acuity. The right design choice for a 20-year-old user holding
the display close to their face is going to be dramatically different from the
right choice for a 70-year-old holding the display at arms length.

You can't really design well for all those possibilities up front. The right
answer has to involve allowing the user to adjust the "zoom level" to their
liking. And that level of flexibility means that automated approaches
(possibly something like freetype's autohinting, extended to work in color)
are probably going to be a better approach than manual pixel tweaking.

------
evincarofautumn
The very meaning of the term “icon” implies a non-literal representation, and
since there is no automatic way to transform high-res representation to low-
res caricature, you end up with vector artists doing horrendous pixel art.

Pixel art is a very different medium from what they’re used to, and there are
specific techniques that they haven’t learned, largely because they don’t even
know such techniques exist. They don’t know how (or when) to antialias or
dither by hand. They don’t know what banding is and why to avoid it, nor what
selective outlining (“selout”) is and why they need it. They _especially_
don’t know how to correctly choose a good, limited palette. All of these
things taken together make for designers at best reinventing tools and
techniques, and at worst making icons that suck.

But what can you do? Pixel art isn’t a popular medium, so the wealth of
knowledge out there goes to waste. It’s such a pity.

~~~
bkirwi
Do you have any resources for beginners you recommend? (I'm not a designer --
just have a certain fondness for dying media, I guess.)

~~~
evincarofautumn
Absolutely! Though pixel art isn’t dying—the niche is small, but not
shrinking, and there are artists who make a considerable amount in
commissions, typically sprites and backgrounds for games.

I suggest you check out Pixeljoint[1]—coincidentally it’s down today for a
server upgrade, but the community offers excellent feedback for new artists,
and the tutorial section has links to some great resources. Pixelation[2] is a
great community with many experienced artists from the pixel world and
demoscene. You’ll also find a couple of tutorials on an older site of mine,
Studio Purloux[3]. One is a general tutorial by my good friend Kevin
Chaloux[4], an outstanding and highly regarded pixel artist; the other is my
own introduction to manual antialiasing. That should be enough to get you
started.

[1]: <http://www.pixeljoint.com>

[2]: <http://www.wayofthepixel.net/>

[3]: <http://purloux.com/artwork/tutorials/>

[4]: <http://kaiseto.deviantart.com/>

~~~
bkirwi
Thank you! Exactly what I had in mind. The attention to detail and tight
constraints reminds me a lot of font design / hinting / etc.

------
pixelcort
I'm glad to see near the end the mention of high-density displays. When
designing icons, a 64@2x icon should be different than a 128@1x icon. Although
the former is technically at 128, it is going to be displayed on a high-
density display at a smaller size, and care should be taken to simplify
embellishments and details that will just make it look too detailed when
viewed.

For icon designers out there, I'm curious how many are already aware of this
distinction and are designing icons accordingly?

------
vibrunazo
Isn't this a little bit of inefficient over-optimization. Sure auto scaled
vectors look more blurred than hand made bitmaps. But the important question
is: do normal people even notice the difference in today's screens? At the end
of the post, the author concludes that not yet. But he doesn't seem to back it
up. And I don't mean to back it up by comparing vector and manual icons for
videophile designers. But actually a/b test it with real users.

I know I personally cannot tell the difference between the example comparisons
in the post. Not sure my users would. I'll probably a/b test it with them at
some point to be sure. Until then, my impression is that vectors are a net
positive.

~~~
gurkendoktor
I use a SIMBL extension to bring OS X 10.6's colorful Finder sidebar icons to
10.7. I have always been meaning to improve its source code because it simply
scales the large versions down.

The difference is irritating and _clearly_ noticeable for e.g. the "Documents"
icon if you compare it to the "Go" menu. And it's not because the big versions
are bitmaps, it was mostly the missing outline and lack of contrast.

(I still find them much faster than the monochrome versions (and with a smile)
:))

The Finder's "Go" menu is really a good example of tiny, clear icons.

------
Adaptive
I'd like:

1\. native support for optional manual hinting vector icons

2\. native support for optional auto-hinting vector icons

Auto hinting is _not_ the ultimate solution, but it can get you part way
there, just like with fonts.

~~~
masklinn
> Auto hinting is not the ultimate solution, but it can get you part way
> there, just like with fonts.

Even without auto-hinting, it still boggles my mind that "desktop" vector
formats don't seem to support hinting at all: I recently discovered there is
no possibility of hinting in SVG, therefore SVG fonts (fonts described using
SVG shapes) can not be hinted at all, that's completely insane.

~~~
Adaptive
YES. Given how long we've been building up to resolution independence, given
the already long standing real-world examples of vector object hinting
provided by fonts... it's amazing that there seems to be little work in this
area and less work in terms of actual standards/implementations.

This is an area Apple is perfectly, ideally positioned to execute and lead on.

EDIT: _I wonder if one could implement vector icons as fonts in order to
properly hint them._

~~~
masklinn
> I wonder if one could implement vector icons as fonts in order to properly
> hint them.

That's exactly what is happening these days with custom font embedding having
become practical (in web pages): <http://somerandomdude.com/2010/05/04/font-
embedding-icons/> (that was in 2010, but this thing is _really_ gaining
traction these days following the release of "Font Awesome" for Twitter's
Bootstrap[0])

In desktop OS, that is in fact a very old technique, that's why the Marlett
font exists in Windows [1].

It does have a significant inconvenient though: the icon can only have one
color for the glyph and one for the background. This provides a crisp look but
lowers the expressivity of the icons. On the other hand, if the color scheme
changes for some reason (or can vary from one page to an other), it is very
easy to match the icons's color scheme to that of the application.

[0] <http://fortawesome.github.com/Font-Awesome/>

[1]
[http://blogs.msdn.com/b/oldnewthing/archive/2012/01/16/10256...](http://blogs.msdn.com/b/oldnewthing/archive/2012/01/16/10256947.aspx)

~~~
Adaptive
I've used custom embedded icon fonts on websites as well, but I was actually
thinking of the more complex ui components through layering. I.e. button
background/foreground combinations for buttons.

I suspect that there would be a whole host of other issues (rending of
baseline location varying by a pixel, etc.).

------
luminarious
But doesn't SVG support CSS Media Queries? That would make it more than
possible to support showing/ hiding appropriate elements/ layers according to
the current dpi, width/ height, orientation or whatever?

------
tqh
Haiku OS uses vector icons in a a format called HVIF, a much more efficient
format than SVG:

[http://haiku-os.org/docs/userguide/en/applications/icon-o-
ma...](http://haiku-os.org/docs/userguide/en/applications/icon-o-
matic.html#bitmap-vector)

[https://www.haiku-
os.org/articles/2009-09-14_why_haiku_vecto...](https://www.haiku-
os.org/articles/2009-09-14_why_haiku_vector_icons_are_so_small)

------
oconnore
This is an interface design/hardware issue, not a display optimization issue.

The article makes the bulk of the case for pixel optimization while discussing
very small icons, and that's true, but it's a red herring. Interfaces should
never rely on users being able to identify or interact with icons that are
16x16 pixels. At 64px, all of the icons seen in the article can be auto scaled
successfully (in gimp, cubic transform): <http://imgur.com/a/DOAyW>

What we really need is to stop building hardware that demands 16x16 pixel
elements, and to stop building interfaces that provide them. With high dpi
screens, even character hinting becomes silly (or even without high dpi, I
disable hinting on my 22" 1920x1080 screen because I like consistent letter
spacing).

Pixel optimization experts may still have a place in the future, but it's
likely in the same boat as audiophiles and $1000 HDMI cables.

------
frankyoo
Great, detailed post. I think situations exist today where vector icons can be
a good solution; however, the promise of design once, deploy everywhere for
artwork and UI that requires attention to every detail ... the
rendering/display tech is not yet available at scale.

I think an orthogonal challenge is convincing cross-functional peers that
visual execution and all of the design details have a huge affect on the user
experience, the product, and therefore the business. In my experience, it's
rarely a straight-forward or painless debate.

------
jacobr
Just like with HTML/CSS and responsive design, you can use media queries in
SVG images. That way you could do the optimizations suggested in the article,
including changing colours, hiding details, etc. Take a look at the demo links
at [http://my.opera.com/ODIN/blog/2009/10/12/how-media-
queries-a...](http://my.opera.com/ODIN/blog/2009/10/12/how-media-queries-
allow-you-to-optimize-svg-icons-for-several-sizes)

As far as I know there's still a lack in tooling though, so you might have to
write some "code".

------
seclorum
The solution is in SVG itself. Set the id='s properly, and we can then do a
simple map of existing hinting terminology directly into the DOM. Want less
density at lower resolutions? Create a low-res layer within the SVG
specifically for this case. The strength is entirely in the language used to
declare the hinting; this can be directly incorporated in SVG, and thus made
accessible to designers immediately (Inskcape -> Ctrl+Shift+X, start your
engines..)

------
asmosoinio
Symbian used SVG for all icons, for various screen sizes. Never looked
especially good, especially so on the lower DPI screens.

------
WiseWeasel
So it would seem the ultimate future-proof solution is to have multiple vector
icons with different levels of detail, each targeting a particular set of
actual rendered sizes. Then, when the platform vendor doubles pixel density on
you, you simply use your current 32x32px-targeted vector design to render the
new 64x64px icons.

------
smlacy
Not sure why this can be a "solved problem" with fonts (mostly) due to
intelligent hinting.

Is there nothing like "Hinting for SVG" or an SVG equivalent to "Multiple
Master" fonts (<https://en.wikipedia.org/wiki/Multiple_master_fonts>)?

------
ricardobeat
Fortunately all of this will be moot in a few years, when high-dpi becomes the
norm.

Some of the examples he shows are much worse than reality. You can have
outlines that don't increase in width for larger sizes.

------
ben0x539
I wonder how that works out with the crazy new ipad resolution. If that's the
future, maybe we can have those one-size-fits-all vector icons eventually.

------
judgej2
thorough as hell, bookmarked for later. good find.

------
wavephorm
The answer is to use HTML5 canvas instead of SVG, and create your icons as a
JavaScript algorithm. Canvas code can become vector if you utilize the scale()
function. I've done this for the icons in one of my web apps and it's a superb
solution.

If there was some way to export a vector drawing as a JavaScript algorithm, or
some semi-standard way to process an SVG image to Canvas then it'll become the
defacto icon solution for the forseeable future.

~~~
julienc
Can you please show an example? This is interesting.

------
drivebyacct2
I want higher DPI and it's an "easier" albeit expensive solution.

