Author: Lefteous
Posted: Thu May 05, 2016 2:58 pm (GMT -6)
2ghisler(Author)
Something about the process. Using 16 icons as base for discussion isn't the right way from my point of view. While they have to be provided for some reason they shouldn't be the default in the program. 16x16 icons are always a compromise - especially when the 'downscaling' is a bit poor as in the iconexperience lib. Icons that are that small must always be optimized manually. These are mainly downscaled vector graphics. It doesn't work for me in many cases. The approach described by j7n to draw elements bigger in smaller icon sizes but drop some details is the right way to go.
Well it's a first version of the icons. I would definitely use a fine-tuned version of the new icons.
For me which color isn't the real question. The blue shape is much simpler in the Iconexperience lib while the yellow folder icon tries to do the classic folder metaphor. So for smaller icon sizes using a simpler shape is better and for larger I would display more details - but only use one color!
I guess we could discuss every single icon so here are some more general comments with references to certain icons as example.
1) Many icons consists of smaller elements which are not yet sized properly. This is one of the things that leads to the impression of cloudiness (icons #2,#17,#18,#21,#47...)
2) The idea of using new visuals for some of the existing is something that I really don't like. I would really try the existing icons in the iconexpericence lib that use the rubber band selection metaphor instead of the asteric which I never understood (e.g. #12, #40-#45, #71,#73). There are many more examples of this with other icons (e.g.#67,#68,).
I just doesn't work to use the same level of detail with this visual style.
3) Text in icons doesn't look as blurry as in the original iconexperience lib which is generally a good. However try to use equal pixes sizes (#6,#7).
4) Just downscaling already very small icons as one part of a multi-element icon might not be a good idea as things might get hard to identify (59,60). Try layering instead or increase contrast on the elements.
5) The rename icon is really hard to recognize (#33).
6) It would be really good to have the same basic representation for files (compare #33 to #63). In addition use the same basic for all file operation icons.
7) Icon #5 doesn't look like cm_srclong. Placing two folders on top of each other doesn't look like all file details. I would rather try to use a table metaphor (iconexperience lib #592+). Having a unified language for 'views' would be great. A table with different content could be an idea...
![Cool]()
Icon #10 misses the sort arrow (not a new problem).
9) Icon #13 uses green text for whatever reason (not a new problem).
10) To use a button style for icon #16 is a good idea. Make sure it's properly sized and centered.
11) Icons #17 and #18 wouldn't need text if they would work. The icons here are way too detailed for the size.
12) Icon #22. I know it's mainly a compatibility command but a tag icon coud work better than a couple of dashes.
13) And yes it doesn't without proper outlines especially in this size. They are there in some icons though.
Well I'll stop here for now. Reading the other comments the general direction isn't yet clear enough to start the detailed discussion.
Posted: Thu May 05, 2016 2:58 pm (GMT -6)
2ghisler(Author)
Something about the process. Using 16 icons as base for discussion isn't the right way from my point of view. While they have to be provided for some reason they shouldn't be the default in the program. 16x16 icons are always a compromise - especially when the 'downscaling' is a bit poor as in the iconexperience lib. Icons that are that small must always be optimized manually. These are mainly downscaled vector graphics. It doesn't work for me in many cases. The approach described by j7n to draw elements bigger in smaller icon sizes but drop some details is the right way to go.
| Quote: |
| would you use them? |
Well it's a first version of the icons. I would definitely use a fine-tuned version of the new icons.
| Quote: |
| should we use the blue elements for files/folders, like in icon #2 (tree) |
For me which color isn't the real question. The blue shape is much simpler in the Iconexperience lib while the yellow folder icon tries to do the classic folder metaphor. So for smaller icon sizes using a simpler shape is better and for larger I would display more details - but only use one color!
| Quote: |
| do you have any suggestions for specific icons? |
I guess we could discuss every single icon so here are some more general comments with references to certain icons as example.
1) Many icons consists of smaller elements which are not yet sized properly. This is one of the things that leads to the impression of cloudiness (icons #2,#17,#18,#21,#47...)
2) The idea of using new visuals for some of the existing is something that I really don't like. I would really try the existing icons in the iconexpericence lib that use the rubber band selection metaphor instead of the asteric which I never understood (e.g. #12, #40-#45, #71,#73). There are many more examples of this with other icons (e.g.#67,#68,).
I just doesn't work to use the same level of detail with this visual style.
3) Text in icons doesn't look as blurry as in the original iconexperience lib which is generally a good. However try to use equal pixes sizes (#6,#7).
4) Just downscaling already very small icons as one part of a multi-element icon might not be a good idea as things might get hard to identify (59,60). Try layering instead or increase contrast on the elements.
5) The rename icon is really hard to recognize (#33).
6) It would be really good to have the same basic representation for files (compare #33 to #63). In addition use the same basic for all file operation icons.
7) Icon #5 doesn't look like cm_srclong. Placing two folders on top of each other doesn't look like all file details. I would rather try to use a table metaphor (iconexperience lib #592+). Having a unified language for 'views' would be great. A table with different content could be an idea...
Icon #10 misses the sort arrow (not a new problem).9) Icon #13 uses green text for whatever reason (not a new problem).
10) To use a button style for icon #16 is a good idea. Make sure it's properly sized and centered.
11) Icons #17 and #18 wouldn't need text if they would work. The icons here are way too detailed for the size.
12) Icon #22. I know it's mainly a compatibility command but a tag icon coud work better than a couple of dashes.
13) And yes it doesn't without proper outlines especially in this size. They are there in some icons though.
Well I'll stop here for now. Reading the other comments the general direction isn't yet clear enough to start the detailed discussion.