- User Since
- Jul 28 2008, 5:28 PM (551 w, 11 h)
What's wrong with this?
@Harley Acheson (harley)
Your proposal looks tidier, but it loses the Collection's enabled/disabled state readability in my eyes. I'd put all the checkmark icons in the straight vertical collumn on the left - just like the rest of the visibility restriction icons are organized on the right side of he Outliner. This way the relations tree won't be messed with visually strong checkmarks.
Sat, Feb 16
@Brecht Van Lommel (brecht) - You ask, You get.
Fri, Feb 8
The "-" (remove from the list) and "X" (unlink) - let's imagine, that the F-user toggle is demoted to the Outliner and all ID's are kept. What's the difference between both of those functions then? Wouldn't the "unlink" be enough? This part of the UI seems to be counterintuitive from my point of view..
Wed, Jan 30
I second Williams opinion - icons have their specific meanings and were designed for particular functions/commands . One must not use random icon for a function that has not any pictogram designed for it. It makes GUI messy and confusing. This applies especially to python addons...
Thu, Jan 24
I redesigned the Light Probe icons. Link to the updated icon set: https://blenderartists.org/t/new-icons-for-blender-2-8/1112701.
Jan 7 2019
Dec 8 2018
Import/Down/In, Export/Up/Out - of course it is designed like that! I was so focused on making sketches and so fixed with the in/down - out/up concept, that I didn't notice the fact that icons are flipped. Sorry for confusion.
Dec 7 2018
Well - third one seems to be ok, but after a while I find it tad too busy. The first one still is the best one, with vertical symmetry, similar silhouette and clearly underlined in/out depiction. If You don't like it, the second best is fourth then (by my mind, of course).
Some more doodles:
Dec 2 2018
I still prefer simplicity of current design, though.
Nov 30 2018
@Lin Fo - nope. Now "in" comes from left to right, while "out" goes from right to left.
Anyway, will try to make different design.
Well - that was intentional. The design assumes that we are staying in a specific space - inside a given file / workspace. Importing then is bringing sth in (from out of blender-specific space), while exporting is dispatching it out (to a foreign environment).
Design is very synthetic and uses the assumption that the user reads from left to right, which is not obvious. A possible improvement would be to add an anchor point that specifies "from" and "to".
Nov 25 2018
Nov 20 2018
@Jacques Lucke (JacquesLucke)
I just updated the icon sheet with pictograms for Image ObData:
- Image as an Object - cell Q24
- Background Image - cell Q25
- Reference Image - cell Q26
You can get it here: LINK
Nov 19 2018
Shift mod. key adds to selection when used in companion with LMB Box Select and Ctrl + Box Select removes from so far made selection. But simple point and click with above mentioned mod. keys doesn’t work in consistent way. Shift adds to selection, while Ctrl makes last clicked object selected and active, cancelling the rest of so far made selection.
It should work the same way, no matter what kind of selection is performed - simple click, Box, Lasso, Paint (no-ides-why-it’s-called “Circle”) selection…
Simple click should wipe selection as well. In crowded scene it will start new selection, so as the Box Select does now.
Nov 16 2018
@William Reynish (billreynish) You were faster than me - I was about to write a similar proposal (combining the Collection and Object visibility popovers)...
Anyway it's nice to be able to hide all items with exception for the one which name was clicked. Brilliant, but there’s no easy and similar way to unhide all, except the key shortcut. User has to close the popover to use the key shortcut, which is a pain in... You know where. Maybe a double click or aclick + a key modifier could be used to bring back previous visibility pattern? Not simple unhide all, but restore previous set of hidden and visible Collections/Objects. Or simple Ctrl+Z would do the job?
Nov 15 2018
That's a really bad desing. The colors were assigned in a random and senseless manner. Red screams "delete/remove" - it's used this way in other Tools icons. All "Add" related things should be green, as in other parts of the GUI. All "modify/distort" things must get purple colur for the sake of consistency with other tools.
Nov 11 2018
Nov 9 2018
Hey, wasn't blue reserved for nondetructive alterations (Modifiers, COnstraints...)? And green for adding/creating. And red for deletions? I see it gettin' more and more erratic.
Nov 2 2018
My point is to use gray colour for backdrops, as it is done with transformation info in top left corner of 3D View editor. Outline is not needed in most cases.
Semitransparent grey backdrop works better in more cases than semitransparent black or white, just because the grey I used in the mockup is the same that the top header uses. Its’s better to have some degree of contrast between the 3D View’s background and the top header to differentiate those two regions. An outline is not necessary, but could help in those extreme cases, when 3D View content’s colour is close to the backdrops’ luminosity - the backdrop will simply “dissapear” as I depicted in my second mockup (the one in which backdrops with icons overap with tne top header).
Oct 28 2018
@William Reynish (billreynish)
My point was to make the header the same colour as tabs background - just like in Worksapces tabs case. Don't mind the Breadcrumbs.
I would treat the header of the Properties Editor window and the space of its bookmarks the same as the space with the Workspaces tabs. An image worth more than a thousand words:
Oct 1 2018
Neither do I!
That's the only way to go with this kind of design - otherwise the white icons will disappear on a light background.
BTW - are the backdrop circles white by default?
Should be black against white icons or vice versa. The aim is to increase the contrast between the background and the icon.
@William Reynish (billreynish) has the latest icons - no outline now.
Sep 29 2018
@Brecht Van Lommel (brecht) That'd be fantastic!
Actually icons are 16x16, but at first I added a black outline to make them work against light and dark backgrounds. In last *.svg issue I removed the outline, so pictograms are plain white 16x16 matrices. Would be awsome if app drawn black, semitransparent circles under those icons to make them readable against various backgrounds and to clearly mark borders of "buttons" / active areas.
Diameter of each circle in this mockup is 28 pix, making the icons look bigger and easier to tap/click.
Sep 27 2018
Shrinking those icons is really bad thing. It will ruin their crispness. Do You plan to provide support for icon matrix bigger than 16x16 pixels?
Jul 4 2018
Now - to shrink icons, or not to shrink? That is a question!
Jul 3 2018
@William Reynish (billreynish)
I changed axonometry type because of supposed future change in Toolbar icons, You've showed me some time ago. It's not a big problem to bring old axonometry icons back - they're backed up. I can try to redesign the set from scratch, but it will take some significant amount of time, and it would be really helpful to get some kind of temporal solution that would allow changing raster icon set without building app anytime I tweak sth in an icon.
@Filip Mond (vklidu)
Pixel precision is very important, since icons are raster files rather than vectors. Scalling will cause blurrines, which - in case of such small pictograms - isn't what GUI designers want to get.
@Alessio Monti di Sopra (a.monti)
This is not the way to go. 80% size of originals means shrinking icons from 16x16 to 12x12 pixels. It's not so easy, even though effective size of current icons is similar (14x14 with 1pix black outline), because 2.5 pictograms make intensive use of shadows, higlights, while flat design must use just one colour for fills and lines; to achieve cleariness, some white space between different parts ofi icon has to be preserved. In 2.5 symbols 3x3pix detail is easy, but in monoicons it has to be filled poligon to maintain clarity and filled items are preserved for strong accents (Objects) - common pictograms must stay hollow and it consumes space. Every icon has to be razor sharp, and thus every bit needs to be designed pixelwise from scratch. I don't know if I had enough time and power to do that again :( Several dozens of hours of work to do...
Jul 2 2018
SVG with updated icons ready to grab: HERE
Building software is a black magic for me, and - to be honest - I don't have extra time to dig into it.
Leaning over deign of a widget outline is great idea!
Vklidu form blenderartists.org is making great mockups with GUI with no prominent buttons. He has got couple of grat ideas in his thread "monoicons" (status and title bars in black, for example).
I made smaller version of playback icons already - pictograms are tested. Update is coming.
Decreasing size of symbols is possible, but have no sense in most cases. Example provided by William is an extreme - other pictograms are really detailed and I believe they'll will lose from shrinking - mice icons for instance utilize whole 16x16 pix matrix. 2pix penalty in height per header isn't that much, but gives best icon quality.
@Brecht Van Lommel (brecht) - it's a problem that I reported back in time of 2.5 icons redesign. Current icons are tad smaller than 16x16 pixels - usually 1 or 2 pixels less, while some of pictograms utilize full 16x16 matrix. This causes size diversity across icon sheet. Some of pictograms are smaller, others are fullsize and buttons and other GUI elements are so. Removing black outlines and designing icons bigger leads to better use of available space and clearer symbol rendering. My icons design assumes the need of making headers and buttons at least two pixels bigger - pending massive GUI redesig seems to be perfect time for such tweaks, although I have no idea how big such change can be...
- mice icons are not perfectly aligned in pixel grid, so some kind of blurriness will occur;
- right and left click icons are not valid - buttons should be isolated from mouse body;
- no-click drag mouse is inconsistent with other symbols, unless it's a conscious decision...
Here's corrected file:
As I stated before, I work on new design (flat / monochrome) of icons for 2.8 release. It's independent effort, with no official support, but I stay in touch with William Reinish and Pablo Vazquez, who are interested in my work. Actually a couple of my new icons are in use already - the mice pictograms on the Status Bar. The longer I focus on my projects goals, the more I find: inconsistencies, temporal-once-a-time hacks, design flaws; simple patching up current icon set isn't a solution and - to be honest - is not in pair with all the great work on redesing and cleaning up the GUI. Next week I plan to release the latest mono-icons sheet, that gets more and more complete, but doesn't really fit real needs that 2.8 GUI renders. The release will be folowed by sort of list of changes that should be considered if we want clean an logically organized UI in Blender 2.8.
BTW, my new icons design proposal already contains:
- Tool Settings,
- Complete Match (string search),
- Case Sensitive (string search),
- Hair Object,
- View Transform Orientation,
and many other new icons, that already use inapropriate symbols...
Stay tuned on Blenderartists Thread
Jun 9 2018
Working on new UI icons for Blender 2.8, I'd love to contact with Tools icons designer. Standard practice is to design the smallest icons first and interpolate the style to bigger pictograms to maintain consistency. Those tiny bits have hell of limitations, thus it's important to pin down basic design principles and guides to follow in various scales.
Tools icons are fine IMHO, but I’d use lines instead white filled polygons. This way, main part of a pictogram (the most informative part) would become more clean cut. Regarding small size of UI icons, it's not efficient to use fills all around, cause those itsy-bitsy would become 16x16 pix blotches. Going linear is a must in such tight space.
Check out my gimpy efforts: New icons for Blender 2.8
May 25 2018
I just started blender's icon redesign. LINK
Old icons design has a few afflictions:
- they were designed to be visible on any background - dark or light and thus some crucial space has to be dedicated to double outlines. It consumes a lot of precious space;
- old icons actually were not true 16x16 pix, but tad smaller - one pixel, two pixels… That’s further space loss;
- in real use, icons are apposed in UI in small bunches that are contextual. Colour ain’t that much needed here. Honestly, some of current icons pop out too much because of their colour, attracting user’s attention to particular parts of interface. It would be good to incorporate some colour codes though - in File Browser, Asset Manager or Outliner. In every place, where one has to manage big lists of items.
Developers input and feedback is highly appreciated, since some of UI concepts are going to change. New design should address listed problems and - by the way, parts of the UI must be retouched (width and height of space dedicated for icons + some border around).
Feb 6 2018
I was passing through, when I noticed a bunch of icons discussions here. Couldn't resist and made small break at work. I'm not really involved in Blender developement since... well, loong time, but I think most of You make it a bit wrong - there's no real reason to create a specific icon for each action such as "New Collection", "Delete Collection",
"Link Collection", "Unlink Collection", "Add Objects to Collection", "Remove Objects from Collection". It should be quite enough to have a "Collection" context in mind and make/reuse universal icons for general actions reading "Create new", "Delete", "Add", "Remove", "Link", "Unlink". Couple of thoughts to consider - icons in menu should act as landmarks. They're like church steeples and castle towers in landscape - You navigate with reference to them. Now, imagine, that whole town consists only church steeples and towers... You simply wouldn't be able to create easy readable mind map of such space and should have to look for other reference points. Which won't be as picky, for sure. That's happening in Blender now. For instance - the "File" menu in "Info" editor is horribly cluttered with icons, whitch are in most: ugly, overdetailed, unrecognizable at a glance and blurry in details. A visual landmarks has to be bound to a few most important/mostly used actions and user should find other menu records, by relating their positons to those landmarks. Sorry if I sound rude, but such small icons (16x16) should incorporate just one symbol at a time and must have distinguishable shilouette. Otherwise we get, well... an amorphous blotch. I'd love to come back here time to time and design icons, but making a really good one is a terribly time and heart consuming process. Out of my ablilites and scope right now, unfortunately. But who knows...
Going back to main topic - I really like general idea of "Collecion" icon, that Albert (wevon) show us.