Well, this is a risky topic, user habits & personal convictions are the reasons, objectivity is one key.
This could be a dedicated thread.
Fact is that classifying things is necessary, how the user can get an efficient feedback, that’s another thing.
What can be observed over time is an increase of the number of commands, menus, icons, options …
The classification by object type is one reason.
As a consequence, the user must rely more and more on his memory to remember what can be done with what and when.
There is perhaps where a form of growing problem lies because if the memory fails, without a clear classification and/or a relevant feedback, the user experience can quickly become frustrating.
In my opinion, the nature of the feedback does not matter ( graphic element, text message, custom display, automatic tab filtering …) as long as the user stays informed the right way and as long as it is not too intrusive.
My concern regarding the classification is to link name with intent.
Back to SplitFace which is just an example of classification I find interesting.
If one want to split a face whether on a extrusion, a surface, a polysurface, a mesh or a subD, and whether or not it is possible on this or that object, the intent is the same : Split a face.
The term face refers to a flat surface, there is a flat surface on various types of objects in Rhino.
So it seems obvious for a user to look for a command containing the word Face in the menus or write face in the Cmd Line or google it to find the right command for the intended purpose.
In case no any command containing that name pops up, the user may conclude that splitting a face is not or not yet possible depending on the object type that is selected.
To stay clear, the classification by menus which leads to duplication should then respect some naming rules : same intent, same name.
Classifying a set of commands by intents in a custom tab for operations that are compatible with various types of objects may help to clarify what can be done with what. A sort of smart commands family.
In case one intent is not compatible with this or that objet then the dynamic feedback is the user best friend.
When I look at the Boolean commands I sense it would be interesting to have a smart version of it.
To my opinion, InsertPoint is a command name that is not that clear when the intent is to split something.
I understand the reasoning but I am not sure that’s the right path regarding classification.
Let’s see things from the user perspective.
Does the name InsertPoint refer to the action of splitting ?
If not, why should that user look for that command to split something ?
If we agree that the user intent is clear, the classification is not that clear.
Let’s see things from the software perspective.
A line is defined by two points
Insert two points on the edges of a face define a virtual crossing line
Aline can be traced used to split the face
The thing is that it is the same procedure that is applied while running the SplitFace command.
Let’s see things from the user perspective again.
Want to split a face, Use SplitFace
Select a face
Want to split Mesh/SudD face - Use InsertPoint
Select a face
It’s like a a reverse reasoning…
Same intent, same procedure, two different names.
Is that clear, not sure…
Just an idea.
So yes, I think it would be interesting to clarify few things for the ease of use, Kyle.
And no, I don’t have a clean solution.
This is where the collective intelligence comes into play.