- User Since
- Jul 28 2008, 5:28 PM (577 w, 2 d)
Mon, Aug 12
@Peter Fog (tintwotin) do You mean sth like this?
Sat, Aug 10
O the other hand, @William Reynish (billreynish)'s way allows for indication of other modes as well - Vertex Paint, Sculpt... It's just a matter of the icon used. What bothers me the most is the fact, that the state isn't underlined enough. It should be emphasized a bit more. Like that, for ex.:
Well @tom k (tomjk) got the point. We already indicate the kind of ObData linked to an Object with the Object's icon. No need for an extra datablock representation, since it serves no real purpose other than showing real data structure. We already have it two-in-one. I can't agree that this is irrevelant to this topic. As far as I understand, we're looking for an elegant way to manage modes within Outliner. @William Reynish (billreynish)'s proposal is easy to implement, but introduces extra information into already crowded space.
It's very important to know which obData data blocks are linked to which objects. We aren't going to remove the ability to see other data in the Outliner
@William Reynish (billreynish) tell me - how many mesh ObData You can bind to an Object? One. I'd agree, if it was possible to attach several different ObData blocks of let's say - Mesh, Curve, Lattice to one Object. But it's not like that. The shape of an Object's icon already indicates type of ObData attached to it, isn't it? We duplicate information with no purpose.
Thinking of modes selection within the Outliner I ask myself a question - do we really need the ObData representation in the Outliner? Is it crucial to visually represent real data structure there? Why do we have to have the Camera Object bold icon with the thin Camera ObData pictogram next to it, even it it serves no purpose? Everything seems to be duplicated - similar shapes of Data and ObData pictograms can be quite confusing at first.
The way Outliner manages data right now makes it really cluttered with information and not easy to read, understand and use. Way too many possibilities and references.
Having in mind the upcoming Otuliner, 3D View Editor and Properties editor synchronization, we may consider further simplification of the Otliner's look and structure. What if we got rid of ObData icons, leaving just the Objects along with other relevant related data blocks (Modifiers, Materials, and so on...)?
The synced Properties Editor will still provide detailed info about ObData of selected Object, but we'd tidy up and simplify the Outliner's window.
The most important thing is, that visualizing and handling changes of the mode via Outliner would become way easier and elegant - the bold orange Object icon would be replaced with the thin green ObData icon.
Well, I find Edit Mode as a kind of "local view" of the specific data.
It'd be more clear and elegant to have it this way by my mind:
I don't find clear and communicative enough to have an additional column of icons just next to restriction indicators (that can be really crowded already).I'd dim all data, which is not in Edit Mode, or change colour of its text and icons to... let's say gray. The point is to make an easy to spot contrast between all the data in and outside the Edit Mode.
P.S. do I see a shadow under bottom-left corner overlay icons?! If so - love it.
Fri, Aug 9
Looks perfect. Almost... The superimosed small pictograms seem to be too high against the file icon. It must be in the very middle of the big icon
Sat, Aug 3
@D. N. (CandleComet)
What You mean by "it is usually impossible to create a hole by extruding 'all the way"? Rare, exceptional cases, or rather most of the situations?
Making holes by extruding part of a geometry all the way its volume is one of the main potential strength of this tool! Lack of it makes it less useful than it could be. Sketchup's Push'n'Pull works this way and makes modeling super fast, elegant and enjoyable.
I stop focusing on this forum for a few weeks and you're starting to romp!
I put on my sleeves and try to propose something that will be close to the above suggestions and the style of the rest of icons.
Wed, Jul 31
Jul 2 2019
Jun 14 2019
One remark - GP Layer must use hollow pencil icon - T13. Linear pictograms are for ObData. Filled are used for Objects or to highlight any type of importance or selection.
May 22 2019
Auto-merge icon's On/Off states are swapped.
May 20 2019
The backdrop should stay imho - it suplements text colouring, since it indicates an ObData is in Edit Mode even when the tree is collapsed and 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 opacity was not controlable.
May 17 2019
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.
May 14 2019
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 edges of the backdrop can help, but ain't that much necesarry.
@William Reynish (billreynish)
the latter is the least ambiguous (Rev. to Last / Factory Reset)
May 13 2019
May 12 2019
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)?
May 11 2019
Top row is most uniform in terms of size and visual strenght. The Holdout icon is kinda similar to Rendered icon, but the Holdout pictogram has hollow circle in the middle, which makes it different enough IMHO.
May 9 2019
May 7 2019
Opacity control is a must. Now it looks... well... not good.
May 6 2019
May 2 2019
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.
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.