Svgs/Glyphs should have separate art boards

[barlock]

The .ai files currently have icons and glyphs on the same art board. They should be split apart onto their own artboards so they can be easily exported

This enables auto exporting from a script #16

[barlock]

New glyph files for 2.0.0 release are here https://github.com/mbarlock/icons/tree/new-glyphs/ai

[poofichu]

Why 5 different sizes? I'm seeing 2 different sizes for glyphs 16x16 and 24x24, then 3 more sizes 32x32 / 64x64 / 128x128. I do see different weights and little elements changed here and there, but I'm wondering how necessary and vital is this? Loading in 5 different versions of 1 icon can get load heavy and pretty daunting with performance. @hchughes @mbarlock thoughts?

[barlock]

5 icon sizes is a lot to deal with and I don't know how much value it adds. Since all of these icons are vectors, It seems to me that we don't need this many sizes.

For the time being though I think we should create essentially (3 types x 5 sizes) 15 different ai files (like object-based-32.ai etc) and evaluate the usefulness of the many sizes a bit in the future. Right now it could lead to performance issues but our devs are hopefully capable of not doing anything stupid.

[Moodycomputer]

Should we recommend one or two of those sizes as the default? Sort of the "Because you're only going to use one of these, use this one" option?

[barlock]

@hchughes I totally agree with @poofichu about the vast number of sizes. Sense all of these icons are vector based, they basically scale infinitely. There seem to be stroke weight differences but I don't think the overhead of maintaining so many sizes adds value.

What would be better in my mind would be at most three sizes. Small ( generally used around 16-24 px, the glyphs), medium (32px, these should be optimized to render at 32 pixels but should expand up to say 63ish pixels relatively well), and large (greater than 64px).

The reason having so many sizes is a pain is that to do icons correctly so that they render well on browsers there are a lot of micro optimizations that need to happen and it wouldn't be worth that hard work on on the scale of 800+ icons (177 icons at 5 sizes)

[barlock]

To answer @terracomma, yes I think we should have three, functionally built at 24, 32, and 64. I'm flip-flopping on 24 vs 16px but the previous comment explains my reasoning

[Moodycomputer]

I would vote 16px on the small ones- Reasoning being that if we are adding design considerations for each size (and we are in a few cases I think) then the consideration for 16px is more likely to hold at 24px than vice versa.

[poofichu]

ALSO @hchughes I'm seeing that these new ones are different than the ones you an download from both the repo and the Design Language website. See API:

Downloaded ones:

New ones:

Which ones are going to official for 24x24?

[barlock]

I'm good with @terracomma's logic for 16px over 24. Also the ones without text is always better for a company in as many countries as we are in ^_^

[hchughes]

@poofichu @terracomma @mbarlock Hi All - regarding the difference between glyphs and icons:

Glyphs
We offer glyphs at two sizes, 16 x 16 pixels and 24 x 24 pixels. Glyphs are designed with more solid balancing solid shapes and knocked-out details so they retain their recognition at smaller sizes. Their recommended size is 24 x 24 pixels minimum for touch interfaces. Glyphs that are not meant for touch should be no smaller than 16 x 16 pixels. Some metaphors, like API, will have a glyph that is an alternative metaphor from the icon in order to help retain legibility at smaller sizes.

Icons
We offer icons at 32 x 32, 64 x 64 and 128 x 128 pixels. Icons accommodate for limited space, but are sized for interactive, touch-friendly experiences. They can indicate change, provide visual cues for the eye and increase recognition.

Just because vector icons are infinitely scalable doesn't mean they're infinitely legible. I recommend using three sizes that aren't just scaled versions of the same icon, so that their detail adapts to their size. For glyphs I would recommend using the two sizes. Right now, I cannot imagine a use case for maintaining all five sizes for each symbol, but please let me know if you have one and we can parse through it.

Lastly, we recommend using SVGs with PNG fallbacks for production code. Icon fonts are valuable for prototyping but not meant for production, as they can cause way more performance issues than managing a few svgs. If your product has dozens of icons, I would do an audit to see if the icons are littering the UI and question if is really the best approach for the UX. This should be a good starting place for the "reducing the quantity" of icons that are loaded issue.

[barlock]

@hchughes Good points! The problem that we have now is that there are roughly 870 icons and because of the fact that we're all human and much of maintaining this project involves manual steps, we miss things.

For example, the zoom-out icon is named differently for pngs and svgs (zoom-out vs zoomout) and the microphone-recording image only exists as a png. On top of that a lot of those icon names differ from their art board names. These are problems in the contract of what we offer developers and designers.

I understand the point of all of those icons and the value that each one can add along the way in terms of legibility. But the question is, is it worth the effort the ensure all 850 of those line up exactly with each other to conform to a consistent contract for our designers and developers to use. The problems that engineers care about (like in #21 and #3) would take manual work to fix for those 850 icons. If each of those icons took 2 minutes to fix, that would be an entire non-stop work-week for someone to fix!

What I'm hoping to reach is a middle ground between maintainability, weight efficient and performant svgs, and good looking icons. I think having a glyph size and a icon size should accomplish that. But I see the value in having something bigger for illustrations. Five sizes feels like its overkill as the legibility difference between the 64px scaled to 128px and the 128 px icons is very tiny.

If we choose to maintain all 5 sizes of every icon what I predict will happen is that the general quality of every single icon, in terms of weight and web usability and rendering, will be par at best. We wont be able to offer the superior product that we want IBM Design to be.

Between separating the icons into their own art boards (this issue), and then being able to export the icons easily (#16). We can reduce the number of contract problems as there will only be a single source of truth (the illustrator files). But It doesn't help us with the most important part, which is what the user actually ends up seeing.

[hchughes]

Yeah, it sounds like I misread the question...Re: microphone:I have the svg so I can resolve that, and the naming can get resolved. Regarding the problems, @jhnsnc mentioned a script he created to help fix some of the issues with #3. I guess one thing I am concerned about from the user's perspective is how legible the symbols read if we only have one glyph size and one icon size. It ties to the concern that certain line weights are used for certain size icons, so if we scale some of them, they might not retain the fidelity and proper proportions of the symbols. Let's do some testing and compare options to resolve this...

[barlock]

That would be great! I'll open up an issue so we can track the results of that.

Once we get this issue resolved, which @poofichu has gracefully offered to help with, the tedious aspects of maintainability (like naming and missing files) vanish sense there will be 15 manual tasks (which is still not great... but tolerable) instead of 850 and we can add some scripting to do easy transformations.

[poofichu]

@hchughes gotcha with the two icons being different. Just wanted to make sure everything is solid and consistent when I build out the illustrator files.

I am 100% on board with testing! Keeping these files manageable and able to be a living document should be high priority along with user context and of course performance.

However I can help, let me know!

[jhnsnc]

The point about different stroke widths and text size is honestly something that slipped my mind. I saw the API icon in Bluemix scaled really small and it kind of irked me. I should have thought about that then.

Also, regarding the naming differences, I did make a complete list of all the discrepancies. Let me know where and I can post it to save you some time.

[barlock]

@jhnsnc Please post them here (#23) and I'll rename the issue to be something a little more obvious. I'm hoping they all go away after we get this issue done and then ACTUALLY build the dist folder...

[poofichu]

Also this:
http://sarasoueidan.com/blog/svg-tips-for-designers/

#8 goes into export options and it has some good pointers on when we create future svg files.

[barlock]

It seems that we can export illustrator files from the command line! (or at least with an apple script, which is good enough for me for now) So for maintainability I think it would make the most sense to put every icon in its own illustrator files. That way you can see every size of an icon and adding a new icon is as easy as dropping it into the source tree. So I think it should look like this

|- src
|  |-- action-based
|  |    |- add-new.ai
|  |    |- close.ai
|  |    |- // etc.ai
|  |-- object-based
|  |    |- // object-based ai files
|  |-- formatting
|  |    |- // formatting ai files 

Every icon based .ai file would contain all 5 sizes of the icon with the art board named for its size. (ie 16, 24, 32, 64, 128)

@hchughes How does that sound? I think that would make this really maintainable and easy to contribute to.

[poofichu]

@hchughes just checking on a few things - there are some missing new glyphs, like all the file types and no hat glyph. Is this intentional or are they on their way?

Missing/Need to Be Designated from Object Based Category:

• activity
• audio-file
• compressed-file
• hat
• image-file
• industry
• inventory
• list-view
• password-key
• pdf-file
• person
• presentation-file
• recommendation
• role
• satellite-dish
• tile-view
• video-file
• watch

[poofichu]

Missing Action Based Glyphs:

• configure
• download
• filter
• get-information
• run
• trash
• warn

[barlock]

I would assume their on their way. Its probably worth opening a new issue with these missing glyphs after we get the new artboards merged

[poofichu]

Moving missing glyphs to new issue #28

[barlock]

Fixed by #31