Non-modal User Interface dialogs

Serengeti (Rhino WIP)
#1

Hello!
For the sake of a better and more modern User Interface experience I suggest that, if possible, all Rhino dialogs/windows are made non-modal over time.

The “Options” window, for example. What good does it do to keep it modal? It’s non-modal in Cinema4D, Softimage, Maya… the way it should be. Just set any option in the dialog, and see the result in the main application window immediately, with full interaction.

(Not in 3ds Max or AutoCAD, though, but I wouldn’t praise those for having a “modern UI”…)

From this Wiki-article:


"A modal window blocks all other workflow in the top-level program until the modal window is closed, as opposed to modeless dialogs that allow users to operate with other windows.[7] Modal windows are intended to grab the user’s full attention.[8] Users may not recognize that a modal window requires their attention, leading to confusion about the main window being non-responsive, or causing loss of the user’s data input intended for the main window (see Mode error). In some more pathological cases, the modal window will appear behind another window controlled by the same program, potentially rendering the entire program unresponsive until the modal window can be located manually."

That’s happening with the VRay for Rhino integration, which happens to be the most horrible of all… modal dialogs wherever you look, and I often had this exact “UI lockup” by modal windows getting behind the main window.

Thanks a lot!
Best regards
Eugen

#2

For many types of dialogs being modal indeed isn’t helpful from the user perspective. Render related Editor windows are a perfect example – here I could not find a single reason for them to be modal.

On the other hand Rhino needs to be modal in areas where non-modality would interfere with its non-parametric nature. It simply made no sense to make the Sweep dialog non modal when the program forgets that it has just created this kind of surface. Also stuff like Analysis Meshes in their current implementation just need to be modal, so that Rhino returns to the display meshes after the editor popup closes.

I think there’s only a few justifications for being modal: The operation…

  • allows for no more later editing (e.g. sweep)
  • sets the model or objects into a temporary alternative state (e.g. block edit)
  • shows a preview but requires a time consuming computation after hitting ok (e.g. changing mesh density)

An excellent example of modality being a fatal limitation is the current implementation of one of Rhino’s newest features. UV-Unwrapping – in its modal App-Drawer of sorts – does not meet any of the reason mentioned above, instead there’s excellent reasons why one should have access to the flattened mesh at any point in time. Making this workspace non modal would be the first step in making it useful.

#3

Thanks for the clarification!
True, Rhino is quite a mixed bag of modality and non-modality. Perhaps also for “historical” reasons as well.
(back in the days the user experience was not quite developer’s top-priority, and sometimes still isn’t, but these times are, or at least should be, over…)

I often like to advertise Cinema4D for it’s good and modern UI. It’s consistently non-modal, except when there’s no other chance, like with “destructive” modeling commands, like you just said.

Softimage (which I worked with a few years) goes even one step further. There are practically no modal dialogs, because every modeling command creates an operator on a history stack, for fully non-linear modeling.
Anyway, that might be undesirable in Rhino, since non-linear modeling brings it’s own quirks and complications that have to be taken care of (memory consumption, stack evaluation speed, dependency loops, …), but from a user’s standpoint, it’s really cool!

Not that Rhino is an uncomfortable application, quite the opposite in many ways, but nonetheless a bit more attention to things like this would help.
So, if in doubt - make in non-modal, except there is a technical / logical reason for the dialog being modal.

Btw… why is it that the Vray Rhino connection is so poorly implemented, UI-wise? Material assignments, especially. Are there SDK limitations that force them to do it the way they do it? Or is Chaosgroup just being “sloppy” here?

That’s another topic, but anyway: resizability…
It can be a major annoyer than having to scroll through lists in non-resizable dialogs! The Options dialog became resizable with V6, yay! Now make it non-modal, too, if possible!

Thanks for reading!
Best,
Eugen

#4

Yup, the program needs to have a far better memory of modelling operations to justify non-modal dialogs.
Have you tried Grasshopper? Rhino’s ICE equivalent, and pretty non-modal too…

Well, all I can say is that the developer of Maxwell for Rhino has managed to come along completely without modal editors…

#5

I did try Grasshopper recently to some degree. Time to fully implement it in Rhino, not just as a plugin, but an integral part!
Not to hijack my own posting… but if that happens, maybe there’s a way to make Grasshopper “listen” to the normal way of Rhino editing, and protocol/create a network automatically in the back, and voilá - an operator stack / command history! (might not be that simple…)

Ok! I guess I will go and bugger Chaosgroup in their own forum… ; ]
I already beta-tested their VRay for Softimage connection, which was, well, not born under a lucky star, too…