Proposal to clean up Tool Properties

idea
(FreeMind) #1

I’ve made a proposal for what issues the current tool properties design is causing and how to solve it, but people don’t seem to like it and I have no idea why…

2 Likes
The good and the stupid of 2.8, UI wise
(Piotr Adamowicz) #2

No idea. Looks good to me. I up-voted, for what it’s worth. :slight_smile:

(apoclypse) #3

Because you are proposing to remove tool properties from where they belong, in the properties panel, to yet another panel. We don’t need more panels. Blender needs to figure how to use what it has already and optimize for that, not add more clutter. That’s what they did with the tools properties.

I don’t want/need another panel or more cruft added to the N panel. You haven’t made a good use case as to why the tool properties should be moved, nor made a good use case as to why the N panel needs to have more stuff added to it

Every use case I’ve seen pretty much boils down to because I can collapse these panels in fullscreen mode. Okay, what if you can easily collapse all panels in Blender? What then? The tools properties in the properties panel is imo a sound design decision. Properties should be in the properties panel, period.

3 Likes
(FreeMind) #4

“Because you are proposing to remove tool properties from where they belong, in the properties panel”

I’d argue that the “Properties editor” is only for properties of the scene and selected objects within that scene, not editor specific properties (Tools for example). This is quite specific. I’d also rename the properties editor to something like “Scene properties”.
Perhaps, the Properties editor should be just a part of the 3D view, because these properties are just for stuff in the 3D view, but that’s problematic…

The argument that tool properties belong there, merely because they are properties, indicates that ALL properties belong there. That includes system properties, viewport shading and overlay properties, node properties, and so on.

Let’s contemplate, that the properties editor could be for all properties, but this way you’d open a can of worms. It would be very hard to organize it without making a mess. Or maybe not all properties would go there, but then you’d have to be very consistent on what goes and what doesn’t. Consistency is very important in designing a GUI.

Currently, all editor specific properties, of all editors, are in the editors themselves, and it can’t be any other way. … Except for tool properties. That is inconsistent. No editor specific properties should ever be outside of the editors, because, for example:
You may have two or more independent 3D views with different overlay and shading settings, and having these settings outside of the editors would not allow you to do that. The exact same reasoning goes for active tools, as different editors can have their own active tools, so the info in the properties editor clashes.

"I don’t want/need another panel or more cruft added to the N panel. "
“I don’t wanna” is not an argument.

“You haven’t made a good use case as to why the tool properties should be moved…”
Not sure about the words “use case”, but such a change would reduce clutter (believe it or not) and improve intuitiveness by solving issues of the current design:

  1. The tool properties would be close to the tool, in an expected location, therefore easy to find, even for the first time user.
  2. The tool properties would be In the same editor where the tool applies to.
  3. The tool properties wouldn’t clash with tools of other editors.
  4. Would avoid duplicated info (Top bar, properties editor). Which leads to overall reduced info on screen.
  5. Would avoid info in the properties editor that is inconsistent with the rest.
  6. Would make the blender design overall more consistent.
1 Like
(apoclypse) #5

I don’t agree at all. I think tools properties are where they belong. We can make the argument about whether all properties should be in the properties panels but I don’t agree that more panels reduce clutter.

  1. But wouldn’t consistency do the same thing. If a user expects properties to be in the properties panel, that would be the first place they look. Consistency imo is more important. Once the user learns the rules of the UI then it’s pretty straight forward too deduce where things are. The Tools properties panel is easy to deduce what it does because almost everything else that interacts with the viewport is there as well and is persistent. The properties panel in default layout is a constant. It doesn’t change.

  2. Why is this important? What are the benefits other than mouse travel. Does it make things clearer for the user?

  3. The tools properties doesn’t seem to clash with any of the other properties now.

  4. The top bar is a bad design decision imo and it could be turned off. Doesn’t really explain why Tools shouldn’t be in properties. That’s just a badly thought out design element.

  5. How so? More elaboration on this would be nice.

  6. Again how so? Adding more panels that constantly keep changing, appearing an disappearing or taking up more screen Realestate just convey information that is already in a place where you would go to edit properties doesn’t seem like consistency to me. It seems like added complication for no really benefit other than mouse travel. If that’s the only issue, move the Properties panel to the other side.

(Thinking Polygons) #6

That’s correct. Thank you.

(FreeMind) #7

“I don’t agree that more panels reduce clutter.”
There would literally be less panels. We’d lose two areas where tool properties are displayed, add one. Literally one less, therefore less clutter.

  1. I already explained why tool properties being in the Scene/object properties editor is NOT consistent with the rest of blender.
    Furthermore, Do you know the reason the Top tool property row exists?
    At first, they wanted all tool properties to be there. But they couldn’t fit them all, so they also added the tool properties tab.
    Still, the top row remained to “patch” up the problem that the tool properties are in the properties editor and too far away and too detached from the editor the tool applies to. While the top row obviously helps with discover-ability that i am advocating for, it’s still not a full solution, as it only helps if the editor is right under it.

As evidence, that tool properties close to the tool are more discoverable, I present you this:
People have wrote complaints about it, for example:


Why isn’t this person thinking about hiding the top row and just looking at the properties editor? Why does this person care about the tool properties being close to the area he’s using the tool in? Exactly because he/she discovered the tool properties on the top row first.

If your (wrong) premise is, that people expect tool properties to be in the scene/object properties editor, then you also argue against the existence of the top header tool properties. And you are against it, but do think carefully: Is it easier to find and adjust, for example, the size of your sculpt brush on the top row, or not? I think the answer is obvious, which is why the top row still exists.

  1. I already explained why things dependent on a specific instance of an editor, must be in that editor.

  2. Well, they are the “odd sheep” in the tool properties, as they have nothing to do with the scene or objects in the scene. But that’s not what I meant. What I meant is, that if you have two editors, let’s say the 3D view and am Image editor, the active tools “fight for space” in the tool properties tab and the top row.

  3. I already explained why things dependent on a specific instance of an editor, must be in that editor. At least we can agree that the top row is a silly idea.

  4. Already gave a lengthy explanation on why it’s the “odd sheep”.
    Pretty much my whole previous comment was about that.
    Try this: “Premise 1: Tool properties are editor instance specific. Premise 2: No other editor instance specific properties are in the properties editor. Premise 3: If you are making exceptions to rules, you are, by definition, making it inconsistent. Conclusion: Therefore, it’s inconsistent. Either all or none, dude”.

  5. Already explained. Also, “taking up more screen Realestate” is simply not true: As explained in the proposal, most tools don’t really have any properties, only a few checkboxes or a single menu. Therefore, in most cases, moving the tool properties there would save A LOT of space. We’d lose a whole tab of emptiness in the properties editor, and the whole top row. We’d substitute all that for a few checkboxes on the top left of the 3D view. That’s quite an achievement.
    And yeah, some tools have a lot of properties. This can be nurtured by adding an “Advanced” submenu.
    As a bonus, this space saving solution gives you the ability to go full screen on the 3D view without losing any accessibility to properties of tools that you are working with.
    So, mostly advantages.

(apoclypse) #8

Well consider that proposal was put forward and people are downvoting it. I don’t think we are going to agree on this and we don’t have to. Right now the design is what it is. Blender is in Beta which means major changes aren’t happening anytime soon. So we can agree to disagree. I personally don’t want more panels. I don’t think its good design and I don’t think its worth the effort.

(FreeMind) #9

You mean less panels.
But ok, whatever.

(apoclypse) #10

No, more panels. I’m not seeing how you are saying less. Is the properties panel going away somehow? So the default layout has the properties panel always on the right and now another on this proposal adds another panel on the left. That’s another panel that didn’t exist before on top of the tools panel. So you have Tools, Tools properties, viewport, N panel, then properties/outliner. That is more panels that users have to deal with. Now they only have 3 (if we completely ignore the top panel). Tools, viewport, N-panel, Properties/Outliner. Except the current default setup takes up less horizontal space.

(FreeMind) #11

Red is panels that would no longer be there.
Green is new.

(apoclypse) #12

Right but the properties tile/view/panel would still be there. I’m not sure if you understand that the properties panel, at least in default Blender will always be there and most people will keep it open at all times. You keep using panel to mean a tab in the properties view/panel. I’m talking about the whole properties/outliner tile itself, then the tools panel on the left, then the suggestion that another panel be added next to or in addition to the tools panel. Removing the top bar makes no difference the proposal is adding another panel to the right of the tools panel taking up horizontal space for no real reason other than mouse travel.

What happens when add-on developers need to add complex properties for their tools? You said add and advanced option? Now you have a not insignificant part of the viewport taking up space when the properties panel/view is literally sitting there doing nothing.

What the proposal is suggesting is not all that different than what 2.7 has now with the T panel.

(FreeMind) #13

“Right but the properties tile/view/panel would still be there.”
The properties editor.
Sure, but the inconsistent panels within that editor would be gone, therefore reducing clutter.
I guess we don’t have an agreement on what a panel is. A panel is, for example, in the render tab - “Sampling”, “Ambient Occlusion”, “Bloom”, “Depth of field” and so on…
Yeah, the properties editor would still be visible by default, though it would not display panels that don’t belong there…

Ok, here’s what we have to agree on:

  1. A single drop down menu, or a few checkboxes next to a tool, on the top left of the 3D view, which are hideable, is not a big deal, when you consider that you remove a whole tab of empty space from the properties editor, and the whole top row, and you also make the blender UI more consistant.
  2. Whether or not my proposal saves space, depends on perspective and use case. No object mode or edit mode active tools have complex properties. So it saves space for all of those.
    You may only argue that my proposal takes too much space when using a complex tool, for example, a sculpting tool and expand every panel. Yes, in this scenario, it will bite of a significant portion of the 3D view.
    However, if you really need to see all the properties of a sculpt mode this way, my proposal allows you to go full screen of the 3D editor, in which case, you’d lose the outliner and the timeline, therefore you’d save more space. It’s really a toss.

Oh, and if we wen’t with solution 2: Adding the tool properties to the “N” toolbar, your whole argument for space falls apart.

“What the proposal is suggesting is not all that different than what 2.7 has now with the T panel.”
The “T” panel, while it was an inconsistent mess for object mode and edit mode, It worked great for modes that have active tools, like sculpting and such. Being similar to what worked isn’t an issue.
Hey, you could draw in one editor, and sculpt in another without a conflict of which tools properties are displayed. Great.

(apoclypse) #14
  1. How so? You are now hiding data from users where it wasn’t an issue before. The information the user needs should be displayed and available at all times in a consistent manner. Users know that to edit an objects properties they need go to the properties panel. They need to edit their render settings, they need to go to the properties panel, they want to change the world settings they need to go to the properties panel. Why would tools properties all of sudden be somewhere completely different?

  2. Okay but the current design doesn’t have that issue. It doesn’t need a special mode to display all the information for a complex tool. The properties panel is built to display lots of information to users in a streamlined and concise manner. The devs have come a long way in that regard.

Adding Tool properties to N panel is not the solution and I’ve written paragraphs upon paragraphs about that on this forum. Personally I think the N panel is about as badly designed as the top bar. The only reason people want to use it is because it’s easily collapsible, if you could easily collapse and uncollapse tiles in Blender it would be redundant because everything it would need to do, the properties tile/panel already does. Why add redundancy to something that doesn’t need to be redundant?

As to the whole conflict of tools properties that’s a bug not a feature. Its something that the devs will have to address at some point. Adding more interface panels isn’t the answer imo. It should be things like pinning properties etc.

Look the devs have made their choice about the Tools panel. Maybe they’l change it in the future (doubtful but who knows) and right now 2.8 is in beta. It’s not going to change anytime soon.

(FreeMind) #15
  1. “How so?”
    I’ve explained this multiple times. Again: Tool properties are editor instance specific. No editor instance specific properties belong in the properties editor. To explain what “Editor instance specific” means:
    An editor is a division of the blender window, it can either be the 3D view, the UV editor, the image editor, node editor and so on. An editor instance means, that you can have multiple of the same editor in your layout. The 3D view for example. You can have more than one 3D view. Even two or more. Each one of them is an instance of the 3D view editor. Editor instance specific properties are properties within those editor instances, that only apply to those instances. For example: The shading, overlay or tool properties. You can have two or more instances of the 3D view with their overlay properties set differently. This could not be done if these properties were outside of the editors they apply to.
    Putting tool properties, but not shading or overlay properties, into the properties editor is a creation of an exception of the rule. The rule being: All editor instance specific properties must be in the the editors these properties apply to. If there are exceptions to rules, the result is, by definition, inconsistent.

As a bonus, the rules on what goes to the properties editor: Properties of 3D view data.
Actually, the properties editor may very well be a part of the 3D view, as the “N” shelf, as it only deals with stuff in the 3D view. Therefore, if it had properties of tools other than 3D view, that is already not right.
The only reason the properties editor is detached, is because it lets the user set up his/her screen layout better. All other editors have their “property editors” in the “N” toolbar.

“You are now hiding data from users”
No idea what you are refering to.
The “advanced” checkbox that would spit out all the settings of a complex tool instead of showing you the ones you need 90 percent of the time? Yeah. okey.

  1. " It doesn’t need a special mode to display all the information for a complex tool."
    By default, the 3D view is taller than the properties editor. Therefore, by default, it would be easier to see all the properties of a complex tool in exchange for a bite off the 3D view.

“As to the whole conflict of tools properties that’s a bug not a feature.”
Still, even if you are completely right about space saving, saving space isn’t nearly as important as keeping editor instance specific settings in the editors they apply to. I don’t believe this can be solved any other way, and any other hacked up solution would just be a hacked up solution.

“Personally I think the N panel is about as badly designed as the top bar.”
I agree.
There is a bit of inconsistency there…
I mean, look at this:


Transform (blue) already is in the properties editor, no need for duplicates.
Yeah, i know it’s not the same thing, but it could be.

Viewport camera properties (green) should be reached in a similar way that viewport shading is.
There is no reason for them to be different.

3D cursor and annotations (orange) are, in fact, overlays.

(FreeMind) #16

I’ve examined the properties of the sculpt brushes closer.
I’ve concluded that many of these properties are misplaced. For example, some of them belong submenus of “Overlays” and “Shading”, as they are, literally, properties for overlays and shading.
Also, in sculpt or drawing modes, the snapping properties from the middle of the header are gone, so that can be used for some global sculpt properties (Non brush dependent), such as symmetry or dyntopo.

So yeah, in terms of space, the situation isn’t that bad at all.

Anyway, what is the purpose of this huge image thing?

I’ve sculpted quite a lot in previous blender versions and this was used to select a tool.
But now that we select the tool from the toolshelf, what is this exactly?

2 Likes
(apoclypse) #17

Yeah. That’s an issue as well. I guess it allows you to easily create your own palette of brushes with settings etc but it’s really clunky. They definitely need to revisit or re-design that.

(William) #18

It’s the brush. A tool can have multiple brushes. This was the case in 2.7x too, but it was just not as clear.

Right now those icons are mostly pointless. because they are static, but the idea is that the brush icons can be made to be dynamic, so they reflect the brush settings done by the user.

This gives an idea of the direction: https://developer.blender.org/T56744.

These further changes may not make it into 2.80, but could wait for 2.81.

(FreeMind) #19

I’ve updated the proposal based on what was discussed here

(FreeMind) #20

I am glad to see that my proposed design changes are actually happening.

Though, here’s some more critique:
Having the snap tools on the “Top bar” is a bit weird.
In case the “N” shelf tool properties are actually implemented:
If you are viewing the advanced tool settings in the “N” shelf, there is no reason to have the “Top bar” visible, but if you hide it, you lose the snap settings… And if you don’t hide it, you see the same settings displayed twice within a single editor. So… It’s just weird.

I’d say, there is no reason to duplicate the the settings in both places - The top bar and the “N” shelf.
So, a better way to do it is to get rid of the top bar, place the snap tool back where they were, move the “N” shelf with tool properties to the left, next to the tool palette. Make a switch or expansion button for two versions of it: Basic/Advanced. All problems solved.

1 Like