Poor usability: setting materials in the inspector among different node types does not use consistent UI

[Johnrobmiller]

In the Inspector, in some node types "Material" has it's own tab, and in other node types, to set the material you have to go into some other random tab, such as "Geometry". This is bad usability and ought to be changed.

This is a egregious violation of heuristic number 4 of the N/N usability guidelines (link: https://www.nngroup.com/articles/ten-usability-heuristics/)

The damage being done here by not changing it is that users will wrongly presume that the materials of certain nodes cannot be set if the inspector does not contain a "materials" tab.

The Inspector needs to be changed such that, to set the material, you either go into a "Materials" tab, or you go into a "Geometry" tab, but either way it needs to be consistent everywhere.

[Calinou]

There are several ways to set on a material on a mesh because there are several use cases:

• Setting a material on a specific slot within a Mesh resource.
• Setting a material on a specific slot on a MeshInstance3D.
• Overlaying a material on all slots on a MeshInstance3D. This goes in the Geometry section because this applies to any node that inherits from GeometryInstance3D.
• Overriding the material on all slots on a MeshInstance3D. This also goes in the Geometry section because this applies to any node that inherits from GeometryInstance3D.

[Johnrobmiller]

This response misses the point of the original post. Pointing out all of these various use cases is a very poor argument as to why the usability is not actually bad -- it completely ignores the problem at hand.

We should get back on topic. How can we solve this usability problem?

If you do not care about usability then you an close this issue.

[Johnrobmiller]

The problem is clearly stated in the orignal post.

The fact that there is a reason why these options exist does not somehow discount the usability problem. The usability is subpar due to perceived inconsistencies in the UI, so, therefore, how can we modify the system to improve it? This is the only thing we should be talking about, the only thing that is not off topic to the topic of the post.

[Johnrobmiller]

Are we going to discuss the usability of the system, or are we going to continue to become derailed? Do people not want Godot to have better UX? Is there a reluctancy to talk about UX and usability?

[bmourit]

IMHO Every time I have come here to see if it will one day get a better UI or more professional look - like how Blender has become more pro looking and user friendly - there are a million devs (likely not artists) who will post things like this as to why things should continue to look archaic. It feels very much as though no one is willing to listen, which doesn't strike me as a good thing for the project.
The first impression of a product is its UI. Godot fails so hard on this point and it is a huge turn off to me and many others.
Just because "YOU" understand it, doesn't mean it is intuitive nor friendly to new users - which should be the goal here.

[theraot]

The OP pointed out an UI inconsistency issue, Calinou pointed out all the things that we would need to make consistent to fix it... While that is not a solution, at no point it was suggested that that discounted the problem. Ideally Calinou's post would have been followed with suggestions or ideas to fix, taking into account all the different cases. But instead we got this.

But enough talking about talking. Now that the discussion has been resurrected, some idea have come to mind, which I'll post separately so it is not buried in the replies here.

[bmourit]

Correct, but it indeed has happened and does happen all the time. So I'm just reminding everyone to be open to listening. Thats all. And to be fair, even if done more elegantly, the responses to the OP have still been dismissive. The first post is always a list of explanations as to how Godot works, which is very condescending and it happens ALL THE TIME. I think you may be turning a blind eye to this, but nevertheless let's move on.

[theraot]

I want to mention that before OP, Godot had support for dragging and dropping materials. Which is something that people coming from other engines would find familiar, see: godotengine/godot#56597 - However, you might not have been aware of that feature, because it is not advertised. Godot has many such features, see godotengine/godot-docs#4377 - I'll save my opinion on the matter.

---

A common request is to have Transform always on top of the inspector. Which breaks the order it has (properties are ordered according to the class hierarchy).

A related issue is that Godot's inspector remembers what is expanded or collapsed per Node instead of per class. So you can't collapse everything except Transform expecting it will be that way on every other Node you select, because Godot remembers per Node, and so you need to expand or collapse on each Node individually.

I believe materials are in a similar situation. We want to find them in a consistent way, the same way we want to find Transform in a consistent way.

So, both Transform (or Layout for Control) and Materials (or Texture on Nodes that have that instead) could be kept at the top of the inspector... In practice, I do not want to mess with the order of properties per-se. Instead, I suggest built-in inspector plugins for these properties to be always on top in the inspector, similar to the audio player that audio stream resources get which is always on the top. Then the inspector plugin for materials can collect all the places where you can set materials on the current Node or Resource and display them together. And if these are collapsable and we get blessed with Godot keeping them collapsed or expanded regardless of which Node is selected, even better.

[bmourit]

Is it possible to do under the hood changes that effect different nodes, while having all the options for say, Transform, all in one place? Perhaps with check box options to modify their properties in other nodes automatically? I like your thoughts though.
I do understand the node structure of Godot, but it seems to be currently at the expense of usability. Perhaps some of this should be abstracted away for the user? I know this is probably a huge restructuring of code though, which may be part of the reason for being somewhat dismissive of these types of proposals in the past.
I think your suggestion is a good starting place for the current proposal! Great idea.