This an easy misunderstanding to have because the “Transfer Mode” operator was first added in 2.93 exclusively for Sculpt Mode with the D hotkey: Sculpt - Blender Developer Documentation
Then one release later it was upgraded in 3.0 to support all interaction modes and the hotkey was changed to Alt Q to avoid hotkey clashes in the other interaction modes: Sculpt - Blender Developer Documentation
While I like the name interaction mode, I think the whole “mode” naming is kinda weird and unintuitive (for beginners especially).
Basically each “Mode” gives you a set of tools for a different application.
I suggest naming it “Tools” instead.
Also, the name “object mode” (or tools) doesn’t make any sense (in my opinion).
Imagen, you know nothing about blender, and someone told you there are things called modes, which basically give you sets of tools for the task, and there is a mode that is called object mode. What does that mean? What tools does this mode include? Also, there are “Object Modes” and “Object Mode,” where one means all the given modes on the object and the other means “Object Mode”.
.
I suggest changing the name to “Transform Mode” (“Transform Tools” is more intuitive, in my opinion).
What can you do in Transform mode (or with the Transform tools)? Well, you can Transform the object… (like what you can do in object mode now…).
.
I added the two options:
.
or
.
I don’t really mind the idea of changing “Object Mode” to “Transform Mode”, but transforming objects is not the only thing you do in Object Mode. You also transform components in Edit mode, so I don’t think “Transform Mode” ends up being a more appropriate name when you consider those aspects.
It’s also not appropriate to rename these from “Modes” to “Tools”. While it may be true that the first thing the user notices is that a different set of tools becomes available when switching modes. This is far from the only thing that changes. The entire representation of the data in memory changes, for instance, the mesh data gets converted into the bmesh representation in Edit mode. This means the types of things you can do from a Python scripting perspective, or a rendering perspective, are entirely different in each mode. It’s not just a different set of tools.
Mode is a perfectly fine, and appropriate word for the menus. For beginners that face issue with this, they need to learn some general DCC nomenclature.
Well I guess that the confusion in understanding my topic definitely highlights how not having precise terminology really hurts any discussion. At least one person got what I was aiming at:
The “Object Mode” (singular). With this icon:
In which you interact with objects on the object-level. I think its name is correct and there’s no much debate to happen there. “Transformation” isn’t specific to objects.
All these “things” that we pick in “that popover of things just after the viewport’s popover to pick an editor” and dictate on what data you interact and which tools you get to do so. How do we name them?
Right now, depending on where you look in the UI or documentation, it can be called a “mode” or “object modeS” (sometimes plural sometimes singular as the above picture, just to add to the confusion 
) or “interaction mode”.
I think we need to pick one distinctive name and stick to it as much as possible in the UI.
Modes is too generic alone. It kinda works in the sense that it’s vague enough to fit everything, but it prevents us from being specific, and forces us to use circumlocutions like we do in this whole discussion to specify about which kind of modes we are talking about. We don’t have this issue about the “modes” in the outliner, because they do have a specific name: “Display Modes”:
Replacing every mention of “mode” by “tool” doesn’t really make sense to me, as these things are not just a toolset, but also what level of data block you are working on, with all the UI and under-the-hood implications.
“Interaction mode” sounds clear to me. These are modes that dictate what we interact with, and how.
I notice two additional things:
I don’t think there are many other places that do this. The Editors popover does have a few ones named editor. But the outliner’s display modes doesn’t have “mode” writen at every mode entry:
Hence, perhaps we could do the same with “Interaction Modes”:
Although that does mean we only see the name of the interaction mode when the menu is closed. Perhaps that would make some people not sure of the meaning? But again, perhaps showing the name here isn’t as needed, much like other menus like the Editor one only shows an icon.
Examples: Transform Orientation popover doesn’t repeat “orientation” at every orientation name available. And the Transform Pivot Point menu next to it have a mix of with and without “point” in the pivot point names, but it shows only an icon with no name in the header.
If any of these situations are clearly giving better results than the others, then maybe a bit of unification could be done.
Several popovers (outliner’s display mode, editors, Transform orientation, etc) have a header with a title that tells the popover’s content. Why not in the Interaction Modes popover too?
I will stop the inconsistency hunt there because it’s a rabbit hole i’m already spending more time than i should. x)
I meant to mention this! This menu is weirdly inconsistent, I agree, let’s do this simple change (It’s my OCD speaking if you were wondering).
This entire thread is the definition of looking for a problem. “Mode,” is a standardized, easy to understand word. Everything else makes sense in context as it is viewed/operated upon per datablock. I don’t get the point of this discussion.
But I am not advocating against using the word “mode”, i’m advocating for using it in a consistent way.
I’m glad you’re back from the multi-month expedition you were on. “Mode,” still makes sense in context for each example presented. Inconsistencies in the menus are a different consideration.
“Mode,” is a generalized term, which is why it makes sense in different general concepts. I don’t think this is something that has to be changed.
Inconsistencies in the menus, documentation, and Python API are the main point of this thread.
Challenging the term “mode” is secondary, and not really the point.
I have exclusively addressed the thread title. If there is a specific point to be made a lot UI inconsistencies that should be addressed with a mockup and discussion about it. Naming conventions, however, are consistent enough that I don’t think it’s necessary. But I’m certainly not the arbiter of this forum.
Exclusively addressing the thread title without reading the body of the thread would of course lead to a misunderstanding of the point. If you want a better understanding of the topic, I suggest reading the posts contained within.
I hope you understand that this phrase:
Could have been replaced by this one:
And the discussion would have been very different!
But yes, as @Xury46 explained: My main goal in this thread was indeed to first point out that the terminology for “modes” is largely inconsistent in Blender’s UI and documentation (the fact that we all have difficulty understanding what we are talking about here is symptomatic). And then, given that there are multiple terms actively used when there should ideally only have one: I tried to see how each of them works best according to my criterias: descriptive and sufficiently precise so as not to be confused with other similar notions in the interface.
I have edited my original post to better reflect it. Though this discussion is admittedly not easy to have by nature, and ultimately not a crucial matter. But the devil’s in the detail.
Patronizing messages don’t assist anyone. The point is to make sure Blender’s UI content is clear. The fact that nobody else has had any issues with the concept of Modes or the term Mode in 20 years tells me that the term doesn’t need to change. Maybe I’m incorrect. I won’t respond anymore. Have a good day.
Regarding this I do want to say that, while I find the current Object Mode Mode redundancy, well, redundant and inconsistent, removing the word ‘mode’ here does make it less apparent what this Menu even is.
I think the redundancy solves a problem. So we should solve that problem in another way.
A quick fix would be to display it as:
Mode: (Current)
To clarify what you’re even clicking.
But honestly, considering how important switching modes is, I’d like to see more emphasis on it in general. It looks the same as all the other dropdowns.
Perhaps this issue could be mitigated entirely by representing it like how the different Viewport Shadings are represented as icons in a row? You don’t have a dropdown for this:
Wireframe
Solid
Material Preview
Rendered
So why do the ‘Interaction Modes’ have a dropdown? I change modes far more than I change the Viewport Shading. (I could be cheeky and say, let’s call those ‘Shading Modes’ ;p)
This would also have the benefit of reducing a click- Currently you click the menu, then click what interaction mode you want to change it to.
Edit: A mockup of what I mean.
I chose orange instead of blue because, Blender is actually pretty consistent in representing objects thematically as orange! I realised the object properties tab already uses an orange object icon, and I think that’s a great ‘oh, these are the same thing’ brain connection. Consistency! :]
