You have been reading for several years now and know that there is too much button density in the Rhino user interface.
Without even redesigning the user interface, why create one, two, three, or even four different buttons for the same command?
The only difference is usually an option, a simple ON / OFF switch that changes.
Setting a command is part of the command, why double or triple the buttons.
Really, I don’t understand the usefulness of purposely overloading the user interface.
I know I’m a bad guy, and you’ve read too many posts about it, because I’ve seen a lot myself.
I love Rhino, it’s great software, affordable, and the flexibility of use in a wide variety of activities make Rhino a reference. But I have the right to hope for more.
Improve the existing one.
Think UX.
Most good 3D programs offer a multitude of control workflows to the user, which adds complexity in terms of UI bloat, but also makes the programs flexible in terms of use, which is great and necessary because of its feature richness.
Also, not everybody wants to or should need to work in the same way (shout out to Adobe). I for instance don’t use the UI much at all. I mostly punch in commands and use my mouse for the rest.
Don’t flatter yourself. One isn’t a “bad guy” for reasonably questioning the status quo, especially not in a corporate forum.
Well, the wonderful thing about Rhino is that all of this is easily customizable. As has often been discussed here, there are users that use only buttons, others who work from menus or typing and don’t use buttons at all, and and everything in between.
You as a user can remove all the “superfluous” buttons you don’t need/want with a few clicks and a few minutes spent. The good thing about supplying all the buttons as default is that it’s a lot easier to delete or move them elsewhere than having to recreate them from scratch them if you would like to have them.
Personally, I like/use certain preset command option buttons in highly loaded commands like line, circle, rectangle, etc.
“There is an overload of buttons in the user interface.” I really feel like I’m opening an open door.
You justify this by the fact that each user has a different use.
Yet each software is confronted with this multitude. The overloaded interface is rarely the option chosen.
Having 10 buttons to execute the _Circle command is a primary and brutal solution. again, I feel like I’m opening an open door.
“each user has a different use”, Yes. No, that does not justify this density in the interface.
Flexibility should not be confused with accessibility. The first helps the second, but they are two different aspects.
I don’t know all 3D software. Move a submenu in a tab, a tab in a floating toolbar, add, delete, move buttons / tabs / menu quickly, define keyboard shortcuts, … Rhino is the most flexible I know of.
Accessibility is the ability for everyone, regardless of their level, habits or disability, to understand and navigate software that they do not know. (yes, this is the ideal formula in a PollyPocket world)
I’m not familiar with all 3D software, but Rhino is the least accessible I know. I don’t remember that since version 5 there has been an improvement in this regard.
Take a look at what other editors are doing to see it’s not impossible. Watch the work of McNeel developers to know their skills don’t need to be proven.
One day, perhaps and at best, this message would pass from “useless” to “basis of reflection”.
Perhaps one day some time will be take to this subject. I hope.
The reason is that adding all those options inside commands was (to use a bit of hyperbole,) a mistake, that has to be undone at higher levels of the interface. In an ideal world each command would do one thing only so that you have some chance of learning what the tools are, instead of half the functionality being buried in optons–thats not discoverable, nor helpful for learning to use the program quickly, i.e. without thinking about it or even looking at the interface. The way to make the interface simpler is to make smarter tools that don’t need so many parameters to be set, or have the guts to actually remove functions few actually use.
I think for certain commands you’re absolutely right and this is where Rhino could begin to streamline.
One command that is really frustrating is points on. It doesn’t work for polysufaces there you have to use solid points on. Ok I know they are different but this could be really misleading for new users because in the command it should at least let one know to use solid points on it actually says at the command line can’t turn on control points for polysurfaces but you can argh that irks me every time I see that.
Some command options are remembered and others not like move or copy vertical is not remembered necessitating us making icons for that. There should be continuity to this, Rhino should not remember options for some commands and not others.
Currently there are a lot of caveats to the ui and perhaps that is the one place to start streamlining.
RM
I learned 3D with SolidWorks. If we take this software or its cheaper copy Fusion360, we can see an example of an accessible but not really flexible interface. A compromise surely exists.
Of course those products just copy whatever Office is doing for their widgets, but the important UI difference is in fact the whole solid modeling paradigm. Sketches, features, parts, assemblies, none of those things exist in Rhino, it’s almost irrelevant trying to compare them.