Auto-merge icon's On/Off states are swapped.
Wed, May 22
Mon, May 20
The backdrop should stay imho - it suplements text colouring, since it indicates an ObData is in Edit Mode even when the tree is collapsedand the text not shown. Only thing it lacked was the fact that backdrop's outline wasn't use fill's colour and the border's opacitywas not controlable.
Fri, May 17
One thing - Rigid Body and Rigid Body Constraints were designed by Alessio Monti a.k.a. a.monti.
Three things, that makes it look not as good, as it could:
(1) right edge of roundbox around active icons is not pixel perfect aligned, so - in lower scale of GUI elements it becomes blurry / round.
Tue, May 14
Probably, my reserve against the current solution comes from incorrectly chosen icon / background contrasts. The quality of the automatically generated backdrop is certainly partly to blame. As I have already noted, making a backdrop in a vector form and converting it into a bitmap leads to much better results. To get the vector base, all is needed is to simply assign the contour line with a thickness of 2 pix to all of icons. It may be made in no time by hand (a backdrop on separate layer) and it shouldn't be hard to make it by a script. This way all transparencies will be taken into account, leading to more subtle and detailed output.
Regarding white icons on almost white background - I exaggerated the effect of similar brightness of icon and background colour. Anyway, current way of handling the issue is not qualitatively comparable with the rest of the GUI. Actually, it increases the local contrast in the case of a dark background, however, when the difference in background and outline brightness exceeds 50%, things start to look unacceptable. Dirty, blocky and clunky shapes it becomes.
I still think that, visually, the current solution does not look good. Besides, originally the icons are made as polygons. Instead envolving bitmap operations, all you need to do is assign a contour line to each vector polygon and you get an outline effect with much higher quality and precision. It can be made by hand or automagically.
So, anyway, ordinary contour makes the details blurred and the icons begin to look blocky. Curved lines and diagonal lines are overwhelmed by the outline and lose their readability.
A much, much better visually and more legible solution will be simply displaying black coloured icons (or other colour, controlled via preferences) as a backdrop and moving them 1 pix down and possibly to the right (the shift should be controlled by the user and associated with the shadow under the text). Offseting edhes of the backdrop can help, gut ain't that much necesarry.
@William Reynish (billreynish)
the latter is the least ambiguous
Mon, May 13
I'll update the *.svg at https://devtalk.blender.org.
Sun, May 12
What is the reason that the Undo / Redo operator in the menu does not use the pictograms that were designed for them (cells C14 and C15 in the icon set)?
Sat, May 11
Thu, May 9
Tue, May 7
Opacity control is a must. Now it looks... well... not good.
Mon, May 6
Thu, May 2
Looks promising. Is there a possibility to control the outlines thickness and opacity? 1 pix should be enough. Providing possibility to offset the shadow (similar way as the text drop shadow works) woud add some nice depth.
Apr 24 2019
@Harley Acheson (harley) - not using the yellowish backdrop's colour for its outline, makes the backdrop look a kind of messy.
Apr 23 2019
I think, that a 1 pix blurred black backdrop with 1 pix offset down (with controlable opacity of course) would be more than enough. I mean it to be similar to the way the text shadow is done right now.
Apr 19 2019
Apr 14 2019
The outline in the patch doesn't work as it should, since it's simple scaling the icon up. It is easy to notice imperfections on icons containing arcs and diagonal lines - some parts of pictograms do not get outlines at all. In a perfect world the outline would be continuous. Now we have icons with local microcontrast strenghtened by outline and other, that lack it. See: Camera, Mesh...
Apr 12 2019
As far as I get it, the orange backdrop is still there, but ain't present at Yours mockup? Still do not catch the need for differentiating Curve/Mesh that's being actively edited from the Light, for instance. Does orange backdrop mean "this item is in Edit Mode"? If so, why is it so important to show such info in Outliner? Is it possible to enter the Edit Mode from Outliner? It's not, as far as I know.
Anyway, if the "Edit Mode" state of an ObData in Outliner is a must, I'd look for the way to show it without using a colour change of the backdrop. At least would avoid using a colour that's different from the icon's hue. My proposal od using ObData colour may still be valid, but shoud be limited to the "Edit Mode" state. Have to sleep on it.
Ha! You've changed it. I referred to screenies with yellow backdrops under ObData under edition. Now all backdrops are 25% white, and that's ok, but mind that using icon's colour will not affect the icon's appereance, while 25% white makes it somehow washed out. I may stare at them too long though :P
@Harley Acheson (harley) - take a second look at my proposal:
@Harley Acheson (harley) - please, try to use icon's colour for the backdrop and its border, like I proposed above. I can't see a reason for: (a) using orange colour for underlining the fact, that the ObData is actually edited; (b) using different colour for active Camera ObData, which is actually editable at a time. Reducing number of used colours will make the Outliner look cleaner and organised yet let it be communicative enough. Right now we get a kind of christmass tree.
@Julien Kaspar (JulienKaspar) - I imagine, that - for consistency sake - the text label of Collection containting selected-active object, should be bright orange coloured. Collection containing just selected objects = dark orange coloured text label. Backdrop under the icon in this very case will be a bit confusing. I prey for bold fonts here though - is it really so hard to be made?
@Harley Acheson (harley)
A promised mockup with big circle backdrops (a version without outline in dashed box):
I got into this topic by accident. Is this task about 16x16 icons? Could I get a screenie of the very part of GUI or a raw mock-up at least?
@Harley Acheson (harley) - will make a sketch but have to ask You to provide me a screenie depicting situation, You're interested to see. This will help me to prepare proper mock-up. Thx in advance.
Apr 11 2019
@Harley Acheson (harley) - limits and tradeoffs then...
My vote goes to tad bigger backdrops. 1pix longer radius, than in Your patch. A 25~50% lighter outline would improove the backdrop's appereance.
Yours on the left, mine on the right:
@Harley Acheson (harley) - some sketches for You (with improoved Camera ObData icon):
The grey circle backdrop makes icon look muddy and dull. I use orange for ObData icons (instead of green) and the 25% white backdrop makes all those icons unreadable. It should/must make the item pop out, so - everything that pumps up local contrast is welcome. I'd try to make the circle backdrop black or make a proper entry in Preferences and let a user to choose colour that fits his theme.
Anyway, I'm not fan of the circle highlight - it makes things busy and is not elegant design-wise in its curent incarnation.
@Harley Acheson (harley) - is there a possibility to change the backdrop circle's colour via Preferences panel? I can't find it. Would like to check out other colours. Deep black first.
Ok, I understand this very well. I'd emphasize the "selected/active" and "selected" coloured text labels with bold fonts, if it's possible. And black round backdrops would be noticeable as well as coloured, but with way better local contrast.
It should be done in first place - right now the Outliner is crowded with various indicators, making it visually messy and hard to use. And so it will remain, regardless of the efforts made, due to the enormous number of visual representations of information. So if there is a possibility of simplification, it should be considered first.
I still don't get, why Outliner's and 3D View's selections can't be in sync. This will reduce the number of ways to emphasize that the object is active and selected. This way "bright blue bar" would mean "selected and active" and "dimmed blue bar" - "selected". No need for coloured text labels.
I'd also examine the possibility of using bold text to indicate which materials or cameras are active / in use. The round labels behind the icons make the readability worse, and with complex silhouettes are simply poorly noticeable.
Feb 28 2019
@Campbell Barton (campbellbarton)
yep - it's not diagonal by default but it uses the available space and features of the general symbol in a clever way.
Moreover, I plan to work more on some of these icons, because users report that pictograms are too similar to each other. Sea of arrows in short words. I predict more reductions, simplifications and generalizations, not necessarily embedded in realism.
Feb 27 2019
Feb 26 2019
@William Reynish (billreynish) - looks like not an easy task, but You know: no pain, no gain.
Feb 19 2019
@Julien Kaspar (JulienKaspar)
Ha! Linked Objects have a link icon next to them indeed. Can't help feeling that all the stuff gets more and more crowded.
@Julien Kaspar (JulienKaspar)
Sorry - I didn't reload the browser and missed some responses.
I don't like the backdrop solution, since it's not elegant and will introduce unnecessary muddle in the space that already is overloaded with information.
In my opinion, dimming icons that are inactive or ineditable will be sufficient, because the effect for the end user will be identical - no possibility to change the state of the icon. The burden of information about whether the ID is linked should be transferred to the object's pictogram - I would try to change the color of the linked object's icon from warm yellow to light gray, as indication of the lack of editing.
At first glance, Harley's solution seems reasonable - turning off the opportunity to toggle, by hiding toggle icons.
@Harley Acheson (harley)
I appreciate and enjoy Your contribution! It makes me move instead of resting on my laurels. I bet, that better icons (check out my latest proposal) will make it easier to distinguish ID states and spot the proper information.
@Harley Acheson (harley)
Well, it's just a question what do You want to underline. A matter of preference I'd say - You may say the glass is half full or half empty, but both of the statements re true. Here we have similar situation. Current design makes enabled states strong, that's true, but most of software I work with does it this way. Lack of information is an information as well, so both states are noticeable and easy to identify. Moreover devs could colour code the states (green = ON / red = OFF, or so).
BTW - restriction icons have three states actually ON / OFF / INACTIVE (greyed out), but Your mockup doesn't take this into account. Moreover it uses badly designed Linked Visibility icons that make it kinda messy (weak difference between ON and OFF states).
I think, that visibility restriction icons need some improvement in the style department.
@Harley Acheson (harley)
Your proposal looks tidier, but it loses the Collection's enabled/disabled state at-a-glance 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.
Feb 16 2019
@Brecht Van Lommel (brecht) - You ask, You get.
Feb 8 2019
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..
Jan 30 2019
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...
Jan 24 2019
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).
Dec 2 2018
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
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.