- User Since
- Jul 28 2008, 5:28 PM (560 w, 3 d)
Wed, Apr 24
@Harley Acheson (harley) - not using the yellowish backdrop's colour for its outline, makes the backdrop look a kind of messy.
Tue, Apr 23
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.
Fri, Apr 19
Sun, Apr 14
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...
Fri, Apr 12
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. 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) - check out my "promised mockups". The third proposal in particular. Using colour of an icon for its backdrop will cerainly reduce using of colours, just because now we have green pictogram against orangey/ellowish backdrop (two colours within small chunk of space). Lets add a material to the stack and we get reddish icon against orange/yellowish backdrop... Three colours. With my proposal we'll get less colours - green ObData against dimmed / transparent green backdrop plus reddish Material ObData against dreddish backdrop. Two colours in clean and readable configuration. The backdrop will work as the icons colour and shape amplifier.
No need for differentiating ObData under edition from active Camera or a Material, just because all of those items do not have other states. Active Camera is actually an ObData, that is under edition. Isn't it? The same applies to the Material ObData. The backdrop itself is enough, no need for colour differentiation IMHO.
@Harley Acheson (harley) - please, try to use icon's colour for the backdrop and its border. 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. 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. Backdrops 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:
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 raw mock-up at least?
@Harley Acheson (harley) - will make a mock-up, but have to ask You to provide me a screenie depicting situation, You're interested to see. This will help me to prepare mock-up. Thx in advance.
Thu, Apr 11
@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 visibility.
Yours on the left, mine on the right.
@Harley Acheson (harley) - some sketches for You:
The grey circle backdrop makes icon look muddy and dull. 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.
@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.
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 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.
What's wrong with this?
@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).
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.