[Bf-taskforce25] Icons design

[William Reynish]

Hi Andrzej,

I'm grateful for you nice icon artwork. And although there are still  
important structural changes to be done for 2.5, icon work can always  
continue in parallel.


On 20 Jun, 2009, at 6:52 PM, Andrzej Ambroż wrote:

> The development goes fast forward as far as I can see and some  
> problems
> start to loom on the horizon.  Those are from GUI (icons) department  
> and
> ain't As-Much-Important-As-Core-Functions are but have to be  
> discussed at
> some point as well.
> Let me name some of them that bothers me the most:
>
> 1.SCRIPTABILITY
> The GUI will be scriptable, so icons should be.
> Calling icons by the script as an item instead of area coordinates  
> could
> solve some problems that are brought up in the next point.

I believe this has already been done.

> 2.ICONS STORAGE
> The icon set grows more and more. Right now we have over 300 items  
> and I
> didn't even start thinking about icons for Operators... Current *.png
> matrix is 600x640pix. Space between icons could be reduced to three  
> pixels
> instead of five so that couple of dozens more new icons could be  
> packed in,
> but even though the space will be far too small when bigger icons  
> will be
> introduced into the GUI (32x32 pix). Separate icon sheets aren't very
> elegant solution – I think. They will become a mess very quickly.
> More flexible storage system is needed.
>
> Maybe we should consider a zip archive full of separate icon files in
> various size formats? Naming of those files could follow scheme of  
> names of
> internal constant operators / RNA /(...whatever...).
> Advantages of such solution are:
> 1.expandability - more icons for new/custom tools/actions/etc. without
> redesigning the icon sheet(s).
> 2.Code independent multi-resolution icons. “To have bigger icons  
> or not to
> have?” question wouldn't be asked anymore - user could just call  
> an icon
> and size wouldn't matter actually.
> 3.calling icons by GUI's py scripts would be way easier (I think).
> 4.Not to mention about order (in terms of tidiness as well) within  
> the set.

Yes, if we do adopt multiple sizes, it quickly becomes unpractical  
with our current icon sheet. For multiple sizes per icon, an icon  
format such as .icns is also a possibility, to keep each icon nicely  
packed together.

>
> 3.COLOUR CODES
> The system of colours I choose for the icon set is effect of design
> compromises I had to make for Blender 2,4x icon design. The decision  
> was
> somehow arbitrary and very personal. I still find it rather  
> consistent,
> well thought and pleasant for my eye even though there are some minor
> flaws.
> But... it doesn't match Blender's general colour information system  
> which
> isn't strictly consistent itself. Colour of selection is good example:
> icons – gold; GUI – orange, although activated buttons are  
> blue (somehow
> fits icons – those buttons state is modified :D).
> Since I know nothing about planned colour system modifications, but  
> we have
> four ways to go:
> 1.change GUI colour info to fit icons;
> 2.make it the opposite way;
> 3.make some small changes on both sides;
> 4.design everything from scratch.
> The third way I've found the most reasonable... (more orange in  
> selected
> items for icons, less orange for GUI elements...).
> Besides I would love to get some feedback on the colour itself,  
> because I
> don't own professional display hardware that could be easily  
> calibrated.
> Each of my LCD's displays the icon set in slightly different way and  
> it's
> irritating somehow.

Changing colors in the GUI is very easy. We could toy with changing  
the blue hues to orange to match the selection colors, which might  
look a little nicer. Would make the GUI look an awful lot like Modo,  
but then again perhaps that's not really a bad thing ;)

There is some room for added consistency too. For example checkboxes  
could also be orange when selected, and so on.


>
> 4.TOOLS (OPERATORS)
> There are plenty of them AFAIK.
> Hundreds?
> Thousands?
> Making icon for each of them makes me laughing nervously.
> What if we had Ops categorized so that we get some kind of families of
> tools (edge modelling tools, vert modelling tools, selection tools,
> whatever tools, etc.)? The categories could be organized in form of  
> a tree
> providing depth-depend diversity.
> I propose it because 16x16pix icons are too small to be used for  
> stack of
> hundreds different   yet still very individual pictures. With proposed
> system 16x16pix icons could be made just for main families/branches  
> and
> individual tools would be labelled just with text. For bigger  
> resolutions
> the only problem is amount of icons to design.

But then again, if the tool icons will be identical they don't really  
communicate anything ;) Probably better to either have no icons, or to  
only make icons for the most common tools - like the top 20 or so. By  
no means all operators! And you are right, most tools are too  
complicated to communicate well with 16*16 pixels.

>
> 5.16x16pix + 32x32pix ICONS = INCOMING ICON FLOOD
> 32x32pix icons? Yeah! - more space for details etc. The problem is  
> which of
> icons should have their bigger equivalent. Making second whole set  
> of icons
> in higher resolution would be an overkill, so it's important to define
> destination target for them. Tools (operators) definitely should  
> have at
> least two sized icons. Anything else?
> I would propose to open possibility of having multi-res icons in  
> general
> (vide point 2.) but postpone official set of them for future  
> releases. I'm
> afraid that the amount of work will surpass me, so will have to find
> volunteer co-workers.
> Here's space for community collaboration though – when things  
> get solid
> enough, I plan to make icons visual identity guidelines so people  
> could
> make their own pictures that match the official set. This way making
> individual icons for Operators isn't such insane idea :)

I know your icons were designed to look good at 16*16 pixels, but  
since they are vectors, have you tried scaling them 200% while  
maintaining the 1 pixel stroke size? It might not look too bad.

Cheers,

-William