Quarter Life Crisis

The world according to Sven-S. Porst

« Live Route Planning • Main • Huah!, World/Inferno & The Robocop Kraus Live »

Iconic

1651 words on

I added a list of links and comments to related texts at the end of this post.

Daniel Jalkut touches some of the challenges of resolution independent user interfaces today. That’s certainly an interesting topic and one that more and more people will be confronted with once resolution independence is a working feature of the operating system.

The most obvious way to make things resolution independent is going for vector instead of bitmap graphics. That’s kind of technically cool and neat as well. And it also sucks. In a way it looks like a typically geeky solution which tries to ‘solve’ a problem with cool technology rather than looking at the details.

And while vector graphics will be a charm for certain simple graphics such as the clock style progress indicator that Daniel describes, I see them fail in other places.

The first are low pixel count situations, i.e. small user interface elements. While an increase of screen resolutions will reduce the number of those situations over time, they are still there on the current screens of many people. And they will be around for many years to come. So they cannot be ignored. And looking around many new applications of the past years, I have noted a rising popularity of the small sizes of standard controls in there (with Apple’s ‘Pro’ apps being quite heavyweight contestants in that game). And the more frequent use of smaller controls will extend the life expectancy of low-pixel count controls even further.

And even with all the new technology we have, the basic facts about low-pixel count situations remain true: Graphics in which those few pixels are carefully and consciously placed will look better than those created from generic vector graphics. Only in a few lucky situations we will be able to get equivalent results from cool vector graphics tricks.

The other setup are high pixel count situations, i.e. loads of pixels. Usually vector graphics are rendered nicely in such situations. So that won’t be too much of a concern. And with all the clever caching techniques, I guess even the overhead of having to render vector graphics instead of bitmap graphics is a manageable – if not negligible – problem.

The question I do keep asking myself in that area, however, is how far we actually need to go. The current 128×128 icons are quite good already and I suspect they are very rarely seen in their full size beauty these days (Perhaps when Command-Tabbing between applications on a 30 inch screen or so?). But I can see how that limit is actually reached and their size may be a bit too small in the near future.

The next step seem to be 512×512 icons. Whoa! 16 times the pixel count. At that size, I wonder whether you will actually hit any limits in the foreseeable future. After all, icons usually are not displayed at huge sizes. And they usually are full colour beauties these days. So anyone wanting to claim that we need anything better than that should probably try to come up with situations where we might realistically need something like megapixel icons in the next five to ten years.

Let me take this a little further and into a somewhat ranty direction: Ever since we got OS X with its large icons, I thought that we started seeing worse icon design. Not only is it hard to get all the pixels right when doing an icon that has 16 times as many pixels as the icons you previously designed. The sheer number of pixels and the transparency also made it very feasible to just paste pictures there rather than doing proper icon design. (I am very familiar with that cheap way out because making a proper icon is hard, time consuming and not necessarily what you want to spend your time on.)

But in fact, the number of ‘just pasted’ pseudo-icons has become quite low over time and now we often see icons which may be produced with a lot of effort and cleverness, but which still fail to be good icons because they have too many details. And those icons just aren’t all that iconic. They can be distracting. And – even worse – they can be pretty hard to recognise in low pixel count situations. (It might be interesting to do a discussion of common icons in this context and highlight what is good and bad about which icons for which reasons. Be it to bitch about some of the existing icons or to illustrate essential points to people who want to design icons.)

Now my fear is that once there are even huger icons, people may start adding even more details to their icons. And that will just make things more confusing – and possibly more ugly as well. So I hope that people will only use the extra pixels to prettify their existing icons – giving them nicer shading and so on. Of course that will mean an awful lot of time, money and memory will be wasted for what look like pretty insignificant changes. But such is the nature of prettiness.

Finally, let me return to the issue of vector graphics in a somewhat ironic twist: While I don’t think that vector graphics are a solution for icon design, I do think that using vector graphics in the process of icon design may be a good idea. Working with vector graphics seems to make people think more in terms of large structures than in terms of small details. And thus, for simplicity’s and clarity’s sake, basing an icon design on vector graphics may be a good thing to do.

The discussion about high resolution icons has been quite vivid, interesting and covering a large number of angles on the subject. I kept a bunch links to posts on that topic on my desktop to keep track of things. And of course I kept forgetting who made which points and so on. So here comes a list with short notes on each contribution. I’ll try to keep this updated, so please let me know about new contributions that I missed.

[1] I wanted to keep the list above relatively short and neutral and not elaborate on my own writing too much, so I put some extra commentary here: I may not have been as clear as I should have been on the point that I am not concerned about the technicalities like file formats here but rather about how having a higher resolution could influence the look of icon.

When writing that post I tried to not alienate people too much and to wrap my thoughts into polite words instead. But perhaps some clarity was lost in that process. So here comes my original line of thinking: Geeks lack artistic skill and taste. Geeks are bad at making good icons. Geeks can handle vector graphics. Geeks will love vector graphics icons. Thus having vector graphics icons will give us technically great scaling icons that look like crap.

OK and now you can insert an encyclopaedia of disclaimers here. I am not denying that geeks with artistic skills exist… just talking about majorities and so on. Another reason I didn’t go for those more offensive lines was that I feared to the not-so-uncommon superficial reader it might look as if I wanted to bash what Daniel did. Which I definitely didn’t want to do as he describes a perfectly reasonable approach in his text: Using vector graphics for a case that is suited for vector techniques. (I guess we could get into an argument about the 1× size of his vector icon looking a bit too thin and thus being less than perfect – but I didn’t even want to get into that and we’d need a more real-life screen shot with matching colours and without JPEG artifacts to judge that properly.) [Back up to the list]

November 11, 2006, 1:11

Tagged as software.

Comments

Comment by pauldwaite: User icon

“my fear is that once there are even huger icons, people may start adding even more details to their icons”

Well, with great power comes great responsibility, and all that. Can’t stop people doing dumb stuff with tools.

“I don’t think that vector graphics are a solution for icon design”

I think it depends on your icon. If the icon lends itself to being expressed with vectors, and doesn’t benefit from extra detail at large resolutions, then what’s the problem?

November 12, 2006, 4:21

Comment by RJ: User icon

…and this lecture of on-screen usability brought to you by someone whose own blog sports mixed-level gray text blocks on gray backgrounds? huh?

and just because there have been a lot of small icon and control elements designed to-date doesn’t justify not trying to pull that cart out of the ditch it’s been driven into over the past decade. i do agree on the point that, when it comes to icons and toolbars that are meant to be shown in a 12x12 or 16x16 space, you must design those icons pixel by pixel. and there may even still be pro apps that are using that design space for their controls, but that doesn’t make it right, or make an environment where, if given the tools (e.g. leopard) we shouldn’t be getting ready to change our ways. and no, actually, no one has to justify a future unforeseen need for 512x512 icons (or hell, 1024x1024 if we’re going to get really out there) in order for us to start making them, because you know, it’s the FUTURE, and we don’t know what will be necessary 7-10 years down the road. i happen to see LOTS of icons every day that guide my behavior that are measured in FEET — they’re called traffic signs. an icon is NOT defined, nor has it ever been, by its relative size.

you even opined that the only place where you could even see those 128x128 icons being used in all of their detailed glory was the app switching on a 30” display. congratulations, that’s a perfect environment that NONE of us could have seen being in the hands of the average computer-using joe 7-10 years ago. but the early os x beta builds allowed for the 128x128 icons, didn’t they? and you and i both know we CRINGE when a classic app happens to be running under os x and it’s 32x32 icon is blown up to wonderfully blurred dimensions in that same app switcher.

if you want to keep designing for elements of 16x16 or less, by all means, but i’d wager you’ll soon be designing them only because that’s all we could hope for and all we needed for a long time, rather than recognizing that we’ve actually always wanted more but couldn’t envision in the current technological realm.

November 12, 2006, 17:51

Comment by ssp: User icon

Fair points.

Paul: I tried to express in a less direct and rude way that I don’t trust average programmers enough to carry that responsibility. And of course vector graphics may work for some icons – the one in Daniel’s example, say – but that’s not a solution for the general problem.

RJ: Of course having large icons will not hurt. However, I fear that – just as it happened when we got 128×128 icons – people will go and spend all their time designing pretty shiny huge icons and neglect making good icons at smaller sizes. As those icons will still be used for some time to come, I consider that to be a bad tradeoff.

A look at a medium size Dock on a medium size screen may be the best way to illustrate the problem I see today and that I fear to become worse in the future: Each icon in that Dock is displayed at a relatively small physical size. And the more detailed icons just start looking like a cluttered mess and become hard to recognise at a glance. And as icons in the Dock are expected to scale smoothly, the Dock

P.S. As for the blog design: My idea for it was that the sidebars are inessential and thus shouldn’t bother the reader who came for the actual text. Your comment suggests that they do that job. Feel free to dislike the design and comment on that or to suggest improvement. But please don’t mix that with your on-topic points.

November 12, 2006, 18:27

Comment by Mike Abdullah: User icon

I think what we need here is a proper file format for new icons. At present we have:

icns - bitmaps only, but allows different images for different sizes pdf - allows almost anything, but is quite “heavyweight” svg - not widely adopted yet, and limited to vectors (I think so anyway, I may have misunderstood things!)

So I think we need something like .icns that allows different images to be used dependent upon the size of display. It then also needs the capability to hold both vector and bitmap versions of an image.

So, in the case of an application icon, at sizes less than, say 24px, a bitmap can be displayed. And at larger sizes, a vector version instead.

November 12, 2006, 20:07

Comment by Marc Edwards: User icon

Great post and I completely agree. Anyone who thinks vector is the way forward probably hasn’t spent enough time in UI design.

I don’t see the small pixel count situations going away any time soon. I think the current “design a large image with hints at specific resolutions (ie. 32x32 and 16x16)” is a brilliant solution.

Also… take a look at your OS X dock. Imagine recreating all of those icons as vector only images. Most would require an imbedded image or two, as some things are not possible in vector alone. Couple that with the low pixel issues and it becomes a very complex and inadequate solution for a simple problem. The fact is that some icons couldn’t be easily done with vectors.

RJ : I think you’re missing the point. The last couple of icons I’ve design have been built at 2000x2000 or bigger. I assume a lot of icon designers do that. It protects your design for the future and makes it usable on printed packaging. The 2000x2000px file doesn’t get released with the current version of the app… it’s just there in case it’s needed at some point in the future.

“and there may even still be pro apps that are using that design space for their controls, but that doesn’t make it right, or make an environment where, if given the tools (e.g. leopard) we shouldn’t be getting ready to change our ways”

Pro app users need to cram a lot of info onto their screens. When I’m running Logic I’ll sometimes have 100+ tracks on my 20” Apple Display. My display probably won’t get much bigger over the next 10 years, but the resolution will so the same problem exists… the icons and UI widgets will be relatively small. Even if screen resolutions double the x and y res, we’re still talking about 32x32 or 64x64 pixel sized icons for most functions. That’s definitely still a “small pixel count situation”.

And (one last point!), notebook sales are up in a big way so a lot of users are working on 13” to 17” screens. I don’t see these ever getting bigger due to the nature of what they are.

November 13, 2006, 1:22

Comment by Craig Hockenberry: User icon

There are two groups of people working with these huge icons: developers and designers.

Designers should be working with vectors — it allows you to future-proof your work:

http://iconfactory.com/home/permalink/1681

Developers, on the other hand, should be working with bitmaps:

http://iconfactory.com/home/permalink/1731

Smart people will realize that you can have your cake and eat it too. The Transmit icon we did for Panic will have some fun surprises for people who view it at the maximum size — but it will also be VERY readable at 16x16 because it has been tuned by hand.

And the “brand” that the icon represents is carried through at all sizes

-ch

November 13, 2006, 23:17

Comment by Andy: User icon

Just some food for thought on the subject: on each of your computers are thousands of vector drawings that have been optimized to adjust to varying levels of optical sizes while remaining legible and readable even when they’re scaled to very tiny sizes on-screen. These vector drawings I’m speaking of are the letters within the fonts you use.

The vector outlines are adjusted by “hinting” instructions http://www.microsoft.com/typography/TrueTypeHintingWhat.mspx which modify the outlines of the letters to produce a more ideal rasterization on a grid. I know that this isn’t a solution for icon developers, but embedding bitmap representations of letters within a range of screen resolutions hasn’t been common practice in font development for quite some time.

November 14, 2006, 0:05

Comment by ssp: User icon

Thanks for the additional thoughts.

And as much as I appreciate the ‘hinting’ for icons with carefully crafted bitmaps, I keep seeing a problem there for the current situation on the Mac: It doesn’t seem that Apple themselves even care about it.Many of their icons – particularly the more recent ones – leave a lot to be desired when displayed at small sizes (pixel counts).

In addition, some of the most prominent situations (Dock, Command-Tab application switcher) have smooth scaling effects and thus use a single icon (the 128×128 size) and scale it down as needed to ensure that scaling doesn’t look jumpy. While I understand the technical reasons for that, it also means that the icons I see most frequently don’t take advantage of their smaller ‘hinted’ versions.

Finally, there’s the question of details: Many or fine highly visible details make icons hard to understand. And when the icon is scaled down they can make things irritating. Looking for examples? Take the Mail icon - it’s ‘stamp’ is cool, but at small sizes it looks like dirt. Or the Preview icon – its magnifier still confuses me at small sizes after years of using it. Or the flimsy pen in the TextEdit icon. Or the white scribbles on the blue of the XCode icon which look like dirt at small sizes along with the hammerhead that is low contrast on the Dock.

To me it seems that details can really hurt at small sizes. And thus simple icons or those which carefully start exhibiting non-distracting details at large sizes like Transmit’s are the way to go. It will be difficult to strike the right balance, but it should be a good guideline to go for really simple icons unless people really know what they are doing.

November 14, 2006, 1:30

Comment by KeynoteKen: User icon

I’m wondering, for low pixel count icons, would it make sense as a halfway solution to pick a fairly tiny resolution under which you wouldn’t figure it’d be used lower than (when dealing with interface elements, etc, and pixel-ize your vectors like on this page.

http://web.mac.com/makentosh/iWeb/tipsfromtheiceberg/Blog/86C1701F-8A86-486E-A6C9-72F5621F5342.html

All of those bitmaps (except the image fills) were displayed as vectors in iWeb and compressed to .png at Publish-time. No, these wouldn’t look all smooth and curvy as they were enlarged BUT they wouldn’t be horribly antialiased either, the lines of definition would be just as sharp regardless of the size enlarged to (resolution displayed at).

November 14, 2006, 11:37

Comment by Amit Patel: User icon

Vector vs. bitmap art also has changed the game industry. 2d hand-drawn art (such as what you see in SimCity 4) feels completely different from the 3d vector art in most games. Vector art (textures on polygons) has the advantage of rotating and scaling, but it just doesn’t look as good as the bitmap art. It also all tends to look the same, because the 3d video card technology pushes you to use one particular style. Instead of trying to make the game elements distinct and easy to distinguish—the same qualities you want in an icon—we have “photorealistic” (even if cartoonish) games. Okami (Playstation game) is a recent game that bucks the trend, and has gotten praise for its unique artwork.

November 14, 2006, 18:34

Comment by Marc Edwards: User icon

Let’s simplify the argument.

Looks best at small sizes? Bitmaps.

Looks best at large sizes? Both look about the same.

Looks best at massive sizes? Vectors. Try and find an actual situation where we need icons bigger than 128x128 or 512x512 though.

Renders that fastest? Bitmaps (especially when rendered with a GPU).

Smallest file size? Depends. Simple icons will be smaller as vector, complex icons will be much smaller as bitmaps.

When you look at it, there’s almost no argument for vector based icons.

“In addition, some of the most prominent situations (Dock, Command-Tab application switcher) have smooth scaling effects and thus use a single icon (the 128×128 size) and scale it down as needed to ensure that scaling doesn’t look jumpy. While I understand the technical reasons for that, it also means that the icons I see most frequently don’t take advantage of their smaller ‘hinted’ versions.” So vector icons look just as bad as bitmaps. Not really an argument for vectors. As you pointed out, there’s not really any other option.

November 15, 2006, 9:50

Comment by alfatreze: User icon

Another possibility would be to actually create a new format where u could specify the elements that get displayed at varying sizes, u could use a mix of vector & raster graphics & create rules for them to be displayed, flexibility for both the system & the designer. It’s a complex issue with several advantages from either side wich don’t seem to dissipate, so maybe the mix would work. Perhaps having raster for vey low sizes, then vector, & then at very large, add detail with raster or only vector. exploratory possibilities. Still with very large resolutin displays ( not size ) the dispay of a vector icon is quite good & u could specify larger outlines & elements not to be displayed! Antialiasing would work well wich is currently the big problem!

November 15, 2006, 15:15

Comment by Marc Edwards: User icon

I couldn’t resist talking about this further… My thoughts and an example of how vectors look at small sizes can be found here: http://islayer.com/blog/?p=87

November 19, 2006, 15:21

Comment by Sebastiaan de With: User icon

I thought I’d just share my name ;).

Thanks for linking - I must say, I appreciate this post a lot. It’s been quite a read, but very informative.

June 1, 2007, 0:31

Comment by ssp: User icon

Thanks for sharing Sebastiaan, I updated things accordingly.

June 1, 2007, 0:59

Add your comment

« Live Route Planning • Main • Huah!, World/Inferno & The Robocop Kraus Live »

Comments on

Photos

Categories

Me

This page

Out & About

pinboard Links

People

Ego-Linking

Quarter Life Crisis • The world according to Sven-S. Porst • [top]