I think the UI is fine although it could probably be made slightly better.
As such, and given the finite resources of every company, IMHO the focus of V6 should be on truly new “core” modeling improvements like a native SubD tool.
Regards to all
Joao
Let me begin by exposing my own bias; I sure as heck don’t want to use an autodesk product. Rhino may be an uphill battle to learn, but I think the same can be said about any CAD package. Even if its UI makes it marginally more difficult, when you consider its power, stability, versatility, speed, extensibility, and the fact that it is easy to get one’s hands on to learn with, there simply isnt another product out there that beats it. Maya is really the only other package that I’ve heard people speak about with an air of reverence, and if McNeel could bring in some of the polygon modeling crowd with the Sub-D features many are requesting, it will be a serious longterm threat to AD. That said…
I think I understand where pretty much every person responding to this thread is coming from, so I’ll risk making some broad generalizations.
It seems that the majority of the people who are advocating a major UI redesign are doing so because of a feeling that Rhino might be “falling behind” in the realm of pure aesthetics. This relates closely to issues of “adoptability” for new users; i.e. people are more likely to stick-it-out with something that is more “pretty” and seemingly simple, they can dig into the complexity at their own pace without it being shoved in their face. This is a valid concern. cf. with every other UI framework that is moving towards looking like IOS 7 (mostly flat, bright colors, uncluttered etc. The oft-maligned hamburger menu is a prime example)
The people opposed are so mostly because of the perception that one or more of the following are true.
Both sides would be ignoring each others’ concerns at their own peril, but I think a few concessions on both sides would yield a ton of good progress.
My suggestion to McNeel as far as product development and evangelism goes is this (in no particular order):
–Emphasize the fact that the command line is king in the pursuit of having command over a vast toolbox. This IS the killer feature of Rhino and one that users are well-served by getting used to. Show them that this is true even for small subsets of the Rhino feature list. Typing “Sphere” and getting a sphere on the screen is intuitive in a way that looking for a button with a sphere on it and hoping this makes a sphere is not. The adage that “a [button icon] is worth a thousand words” simply does not apply in this context. I only need the one (or two) (or three) words to convey the proper meaning. It is definitely possible to do this in a way that is not patronizing; I’m not saying that you’re stupid because you like clicking buttons, I’m simply appealing to your senses of intelligence and curiosity by suggesting that there’s a better way and demonstrating it.
–Build in commands for activating a small number of modeling “modes” that customize the interface. For instance, “LearningMode” simplifies the interface by removing most buttons and tabs that don’t have to do with drawing or making surfaces, and maybe loads a model with small tutorials for drawing and surfacing. “PolyMode” culls a set of features for polygon modeling only. Perhaps there are certain modes where going “fullscreen” by leaving only model space in the window with a toolbar makes sense and appeals to peoples’ aesthetic sense. Yes, maybe this is something that is better done by third party developers, but it is not THAT much work, and having it as an OEM feature would certainly encourage its use and could even imbue Rhino’s reputation with a sense of beauty and simplicity that it might not have right now. These are just back-of-the-envelope examples, but having a selection of modes for a user to choose from means you can test out new use paradigms without alienating the “core” users by making everything “look all metro-y” or something. I can definitely see forum posts where people ask things like: “What CAD software should I be using?” and people answer with things like “Get Rhino, it will serve your needs best but MAKE SURE YOU TURN ON PRETTYMODE”
Hi Bert,
Thanks for taking the time to write this down.
I think you made some very valid points and pointed in a way to look at the issue without compromising anything.
However I think trying to adopt a paradigm that allows for GUI modes that leave out (or hide) certain tools and functionality is no simple matter and as such should not be considered trivial. It’s always harder to choose what to leave out than to just add stuff. But I fully agree that if possible making Rhino easier to approach by it’s looks and feel would benefit all.
-Willem
hmm… i took a look and honestly, i don’t see what you’re talking about when saying it’s the future of modeling whereas rhinoUI is outdated etc…
360:
Spaceclaim:
Rhino: (mac. full screen shot)
to me, those other two have too much in common with what i personally think of as one of the uglier UIs out there for modeling applications… that being c4d:
i guess i really don’t understand by your post what you mean by “The current Rhino UI is already outdated and future generations won’t feel attracted to it.”… because when i open rhino, i see it as a pretty application… it is attractive and i don’t see those examples you stated as being more attractive… in fact, i think they’re less so (with spaceclaim looking a bit nicer than 360)… but this is all entirely subjective, right?
also (on mac at least), rhino ties in with the other 6-7 applications i may use on any given project… it follows many/most other computing conventions i use (when applicable) and, to me at least, this is nearly as important as the individual application itself (from a UI/ecosystem standpoint).
anyway, all of the UIs these days are just polishing a turd… we’re trying to draw in 3D on 2D screens with 2D input devices… focusing on trying to further polish the turd is maybe the wrong place to be setting your sights.
what we really need is better UI as in better user interaction with the computer itself… kill the mouse & keyboard as our main means of talking to the computer… the mouse is so incredibly slow when realizing how awesome our hands are except with a mouse, we might as well have a single finger attached to our elbow because all we can do with it is point at different things and poke them.
“the future of modeling” is not the same old menu system with the same old icons on the same old flat panel… all of these apps are the exact same thing when you step back a bit and look at the big picture… if you want true increases in fluidity & productivity, you need better i/o devices… that’s all there is to it.
I would like to get into this discussion :
We don’t need a new interface but, for sure, we need a big work on smoothing out the drawing process.
The small improvement in actual V6 are in the right direction. Of course you have to keep cleaning up things.
More preview for all the tools, take the array: in V5 only 2 of them have preview. (why?)
I think it’s correct to talk on this, but more examples would help the developer to improve faster the ui.
Keep talking!
This if fine, and in general I agree that it is a good way to communicate with Rhino in many, even most, cases, but we have been perhaps too much tied to the command line - Rhino 5 takes some baby steps in relaxing that ‘bond’ is with sub object selection, and gumball ; the MoveEdge command is basically obsolete, among others. Or click and drag in the Revolve command. There are other ways we can evolve without leaving the command line behind- - there are commands that, in my view, cry out for a dialog box once started. (Revolve is one). We could take more advantage of the built-in Rhino dash-command design so that you could have more commands that use both, depending on the dash or no dash. Dialog boxes can be much clearer and save a lot of clicking compared to command line options. One thing I am hearing from users is the need to cut down on number of mouse clicks and commands needed to perform an operation - we’ve barely got started there, it seems to me.
e.g. http://mcneel.myjetbrains.com/youtrack/issue/RH-29198
-Pascal
Interesting topic. Perhaps it would be interesting to post a like-for like set of screen shots for various CAD software (very much like Jeff’s already done) and take a poll from those here present, giving marks out of 10 for each purely for visual appeal. I suspect the results would be so disparate that they prove nothing, other than that people have widely varying tastes. If you describe each of Jeff’s screenshots to yourself in words, the fundamentals of all are remarkably similar.
I think a major overhaul of the UI would be risky as it could end up alienating many seasoned users because it makes them short-term unproductive, whilst at the same time requiring a time investment from new users to get to grips with it.
I don’t think an across the board injection of colour to try to ‘jazz things up’ would be a good idea. Simple, clear icons are what’s needed, especially for those with high-dpi displays which can squeeze buttons etc to a small percentage of screen area. That said, a structured colour coding of sets of commands would be very useful.
Early versions of Rhino were beautiful things; the creators used a stunning logic and simplicity in their approach that often left me thinking ‘well that’s obvious’ when in many cases it wasn’t, until someone at McNeel took the time to get to the heart of the matter. Successive Rhinos have added layers of complexity (thickened its hide? 
) that now hide that simplicity. Colour keying of related command sets may be a way of bringing back some of its youthful elegance.
ESI - Elegance, Simplicity, Integration.
Oh, and please keep the command line and never, ever do away with the popup toolbar! Pascal - a dialogue box is surely just (in essence) the command line temporarily detached from its usual place of residence?
Absolutely, I wholeheartedly agree with you that command line OPTIONS aren’t necessarily the end-all be-all. I can scarcely remember bash option flags half the time. What I resonate with is the idea that you never have to divert focus from the modeling task itself when using the command line. Never taking your eyes and mouse off the area of interest to go click on a widget on the side of the screen saves a great deal of time in the long run. Dialogs accomplish this task to a very similar degree (if they don’t pop up three monitors away from the main window). It’s the same reason I use emacs. It doesn’t mean that I’m a computer geek who loves doing things the “hard way” (I sorta am), it means I’m a person who values my own time immensely and wants to apply all of it to the task at hand and not to the tools with which I’m accomplishing the task. There should be nothing superfluous. Some applications are meant to be fun to use in-and-of themselves (games mostly). IMHO this is NOT the province of CAD applications.
edit: @pascal To your point, the new selection/control point interface in V6 is a perfect example of streamlining the interface without adding buttons. Way to go McNeel.
here are a few i can think of right now-
• get rid of the Vertical option in commands (Move, Copy, Line, etc) then make elevator mode easier to use.. for instance, just push the ctrl key to toggle on/off vertical.. not ctrl + click on point in order to go vertical.. or, eliminate a modifier key entirely and have rhino be a bit smarter/more predictive that a user want to go vertical (while in perspective) based off where there cursor is in the viewport.. (moi and sketchup do this well)
• let preview geometry determine which directions things will extrude and rotate (in commands which don’t have other options such as normal direction).. i’ve used rhino for a few years now and still can’t get used to the idea of rotating or extruding in negative directions.. maybe if i was only drawing in 2D, it wouldn’t be so bad but once you get out in space, it’s often counter-intuitive when trying to think about which way is positive or negative.. so if the preview is going to the right and i type 45, the object spins 45º to the right.. just like the preview has led me to believe.. if the preview shows left, it spins left with the same keyboard input.. similar thing for extruding.. (and negative numbers can still be used.. it’s just that they’ll go in the opposite direction of your preview.. this comes in handy in certain situations with inferencing)
i have a few more of these type of hiccups.. i’ll type them up later.
Sure, it can be that - the cases that seem the most clicky to me (and Revolve is actually not so bad, now that I look at it) are the ones where you need to invoke a command line option to see what the options actually are. (e.g. Delete in CurveBoolean, or RailType in FilletEdge) These are unclear, especially to new users, and require a extra click to set them compared to say a radio button where you can see all the available options and click once to set the one you want.
Don’t get me wrong, I love the command line, but I think we can better take advantage of dialog boxes and still leave the dash versions in place.
-Pascal
I do revolves all day, every day. The last thing I need in there is a dialog box!
(I’m going to have nightmares all night now. …
)
-just my 2¥
Hi Wim - but, my point really is, regardless of whether that was a great example, that we have dash-Revolve, so we can add dialogs without slowing things down for users who get the most from the command line.
-Pascal
Yes, but then I would like to be able to turn the behavior around and have to type the dash to get the dialog box instead of having to have to increase my keystrokes by 20-30% for each and every command. I would expect a ‘button-pusher’ to not mind having to push options in a box and then the commands behind the buttons could have the dash included without that interfering with their workflow.
My example of how this can go wrong is still the named views dialog where one now is forced to move the mouse to whereas in a Rhino long gone, I was able to type my way to my named view. [Though I have learned to call the views v1, v2 and so on so that I can mostly bypass the box].
Can you show a couple of mash-up walk throughs to illustrate what you’ve got in mind and contrast them with the existing arrangement(s)?
Rather than the me-too radio button arrangement, could the dialogue box be an echo of the command line, just brought into the users line of sight? That way, Superusers like Wim can still do their thing with the same number of keystrokes as the current setup and the dialogue box would just ‘go away’. I guess this is what I’m getting at in the first sentence - what are the objectives of a UI revision in this context?
Well, I am not proposing to add a dialogs all over the place, only that we can and should consider them where the command line is unhelpful in its current state.
-Pascal
I very much like the direction Mac Rhino is headed. The command line has become more visual, more prominent, and clickable - while at the same time retaining the ability to run the whole thing from the keyboard. I think there are a lot of ways it could be improved. But it also does a nice job of making a dialog when commands that don’t have them get complex.
If all commands (dialog or otherwise) displayed their UI in the same place, in the same semi-modal way, I think we could improve the workflow of both mousers and keyboarders.
Hi Matt - Compare V4 BlendCrv or even worse, BlendSrf, with V5’s. V5 may not be at the pinnacle of UI design but it is a lot less painful, in my opinion, than in V4 (Dash version in V5 = V4 version). Am I just wrong about that, or is V5 a better thing to use? I’d look for painful cases like that and fix them, is what I am saying.
-Pascal
Right, that is much cleaner in general. The mac is not really ‘done’ yet in this respect - it still follows Windows Rhino in requiring clicks to move into the settings where the dialogish aspect of the Rhino for Mac presentation suggests it should not be necessary, but it is a good direction.
-Pascal
ViewCaptureToFile seems like a prime candidate for a dialog… using a different mac app for example, it should (could) be like this:
currently, it’s a bit iffy on mac but i think the current mac implementation is better than a straight command line method… i hope i’m not going too off topic by bringing mac stuff into the serengeti forum but this is how it could be on mac then v6 windows can copy it 
the non-dashed version of the command as of now brings this:
that’s a good start… however, the ‘options’ button is greyed out and we should be able to push it in order to bring up something similar to the first screenshot… with aspect ratio locks and buttons/sliders for the options… ability to use physical size/resolution as opposed to pixels only etc…
this would eliminate the need for us to run the dashed version (which needs run separately to get to image size options… but the ‘browse’ button in the dashed version is very out of place)… save the dashed version for scripting
EDIT– more of a [REQ] for ViewCapture… an option which will scale line thickness according to your output size… for instance, if my viewport is currently 1000px wide and my display mode has edges set to 2px–> choose the requested option so when i export it at 5000px wide, the edges are 10px wide… that way, the export looks like your viewport only bigger instead of a bigger image with relatively thin lines.
to say it a different way–
here’s a ViewCapture at actual size: (ignore the no AA… well, sort of ignore it 
)
curves set to 5px
here’s the same view only exported at 5x the size… i then downsized it to the same as above.
if the requested option were available, the line thickness of the second image would match that of the first.
does that make sense to anybody else?
I’m a little late to the party here, just haven’t had time to participate up to now, sorry.
I have been asking for dialogs and some command consolidation for a long time. For me the important points are as follows (I may be stating the obvious here):
There is always a dash version that allows anyone to macro, script,
or type in the command in any way without getting the dialog
Dialogs can present a diversity of options in a compact visual space
that is much easier to understand than a long command line -
especially if there are several levels of sub commands.
Dialogs MUST be combined with real-time previews. You need to see
the results of what you set immediately.
For me, there are two different ways of working that need to be
covered by dash and dialog.
you know exactly what you want, all you need is to enter the appropriate numbers/options. In that case, the dash/macro approach is generally easier.
you don’t know exactly what you want, you are working “visually” to try and see what the options do. In that case the dialog with real time preview is very helpful, you can set all sorts of options/numbers and see what’s happening before confirming.
Examples of commands that IMO could benefit from dialogs:
All the Array commands: (IIRC Dale made a dialog version to test, but I can’t find it anymore) - especially ArrayCrv and ArryCrvOnSrf
Extrude: throw ALL the options into one dialog (Straight, Tapered, AlongCurve, ToPoint, Solid, etc). Maybe need to separate ExtrudeCrv and ExtrudeSrf, maybe not…
@jeff_hammond I agree things like -ViewCapture… are also good candidates - I was demoing this the other day and the command line version IS painful.
There are probably others…
My 2 centimes… --Mitch