General New Radial Menu Feedback and Suggestions:

[TehTurk]

-Things to Consider, Froox does want to keep menu inputs to 2 buttons to free up the joystick and allow for more functionality and customization for Users. -Bug Spectators cant use menus

[TehTurk]

So one issue is that essentially quick usage of the menus is somewhat hacky and tricky with muscle movement, One suggest would be holding down a input like trigger and selecting the menus arc area, this can allow for faster interaction and function. Holding Menu was more original idea, but it conflicted with the future idea of holding menu to return to default hand menus. There should be a more complex input like double tap and hold or triple click and hold. Because theres a genuine issue for quick usage on the menus.

[GearBell]

we need undo/redo/locomotion/resize available on the menus no matter what, because often we do not have both hands available, especially when we are working on custom tools when equipped. Lag causes you to miss the menu.

[GearBell]

minor hand tracking would be nice, in regards of situations where we have to move our arms, which renders the current version of the menu unusable cause moving your arm away disables it. in example, bad tracking flicks your arms around, making the Away Menu feature make it set off all the time.

[Anomalous]

The text really needs to be outline text, it's impossible to see if you're looking at a white object (noticed when trying to unpack logix, where a large portion of the right-hand side of the inspector is white input fields).

I'll second that the undo really needs to be available even when you're holding tools in both hands. I won't say that it necessarily has to be in this menu, just quickly and easily accessible somehow without dropping tools. Preferably with a single button press, since when I'm trying to draw something using brushes or the convex hull I'll often have to undo 10 strokes for every 1 good one.

Edit to add: When first using this new radial menu, I also keep expecting the menu to stay open only as long as I hold the menu button, and to disappear when the button is released, selecting the item that I was pointing at. I'm not saying the current behavior is wrong, just that something about the design of the menu tells me to expect it to work that way. I understand that would actually be quite bad behavior for some things that you want to activate repeatedly (like undo).

[ProbablePrime]

• The Locomotion Setting menu could do with a cancel operation.
• Some font scaling seems odd, Look at the above text "Undo Grab Objects" seems to be sized very weirdly.

[Anomalous]

I wonder if it would make sense to have the open center of the menu be a "cancel/back" button. If main menu is open, center closes it. If sub-menu (like locomotion) is open, center goes back to main menu. If tool-specific menu is open, clicking center of menu brings you back to the main non-tool-specific menu with the undo and the locomotion options.

Might be too confusing, just tossing the idea out there since Prime's comment made me think of it and it also potentially addresses the lack of access to primary functions while a tool is equipped.

[shiftyscales]

As pointed out by Max the Hybrid- the context menus can't interact with private UI. There is no option to use the delete button, etc.

[Abysmal2134]

A downside of the new menu is the lack of quick usage, especially if you need to move your hand across the diameter of the whole circle.

Something that would be nice is a settings option to adjust the radial's menu scale, or the inner radius, so that you need less hand movement to hover over the options. Maybe an option to make the buttons look like pizza slices, so that you always have a option selected.

Another solution to that is to have a vector pointer always active from the center of the menu to where your current laser pointer is, so that we always have an option selected depending on the angle, no matter how far we move our laser.

Of course all of these could be optional settings for advanced users if they don't interfere with anything.

[TehTurk]

So I went around tonight and there were a few issues I was getting while talking to everyone.

• Locomotion needs to either be a group of buttons, or some sort of toggle like old behavior, making a new radial menu spawn feels in intuitive, and some suggest the use of an increasing arc menu, that or Update the Menu Button to contain all the options. Because originally you said you didn't want a Modal Interface/Interactions, but this goes against that somewhat.

• Please Fix the Empty Space in the Center, or at least have the menus arc towards the midpoint, or allow lasers through.

• Some sort of behavior to have the Menus still follow or lerp towards your hands, (There's no more Joystick input, so users won't get stuck moving (This was the biggest issue and concern vs the old ones)

• Some objects are impossible to see through the menus,

• Grabbing to Dupe or Destroy aren't as easy as it used to be.

• Menu signifies some sort of Dragging Behavior and doesn't consist of that

[Abysmal2134]

Something else I'd like to mention is that equipping a tooltip or any item still locks out the thumb-stick controls. I can't actually move with a logix and dev tooltip equipped in both hands, or move with one free hand and steer with the tooltip one.

[DeliriousJax]

Feedback:

• Can we have option for double clicking delete in the context menu return? Or at least an option in settings for the worry warts?
• Ability to press the button to close it if it's already open as re-opening it in the same spot becomes a little redundant while pressing again to close feels far more expected and natural. (Passed on by request from Cyro, I am in agreement)

Bugs(2):

• ULX "Button" Component sometimes resets it's colors or behaves strangely unless the colors are driven. (As far as experiments have shown thus far)
• Radial menu becomes nearly inaccessible in physical mode. (Laser interaction)

[DeliriousJax]

Oh! Just discovered this too, one menu per hand, please! This is important for the ambidextrous tool users alongside the need for undo/redo on the tools again. Yes, there are a few of us who can use two context menus at once. Please ;-; I need my powers back.

[Frooxius]

Thanks for the feedback and bug reports! Fixes are coming in the next build! A few things for things I need more information or discussion (stuff I skipped is getting fixed or changed next build).

EDIT: Some stuff will also come later, like styling, changing the sizes/radiuses, rendering through objects. They require other pieces of the new UI (e.g. new settings or laser) first.

A few questions: Why do you feel that they lack quick use? I feel like this might be just how they feel right now, since they're new a you have muscle memory for the old ones, but general pattern should be same: "Open Menu -> Rotate Wrist to item -> Click" vs "Open Menu -> Move hand to item -> Click".

Personally I've been a bit slow at first with them, but after using them a bit I'm getting quick with them as with the old ones.

I am considering adding the trigger drag from center for quick flicks though.

@GearBell I've originally tried keeping those options with tools, but with some tools (like the inspector) it makes the menu too crowded to reliably use. I am considering adding Undo/Redo at all times though, but not the locomotion/reset scale (those will be moved later on anyway).

How often does the hand tracking thing become a problem? Usually with these you should open quick, select and you're done, so they shouldn't stay open for too long. Is it that you move too far beyond the edge by accident when doing that and closing it? I can increase the range at which they close a bit, which might help resolve the issue instead.

I don't know about the hand tracking, because that can easily make them feel very hard to use, because they'll be "floaty". E.g. you move hand to an item and click, but miss because the menu is moving in the meanwhile too.

@ProbablePrime What do you mean cancel operation? As in closing the menu? If I make the menu close by pressing the button again will that be sufficient to resolve this?

The scaling I'll have to look, it's using auto-sized text right now that fits within an area.

@Anomalous I don't plan to have back operation on the menu, since these are not designed to cover anything that needs such complex navigation. This would conflict with the potential trigger from center quick operation too.

@TehTurk I do not plan on having the locomotion as toggle anymore, those end up really confusing for users and I often find it hard cycling through the options myself. I think this approach is more beneficial in the long term once you get used to it.

However locomotion is in this menu only temporarily, later on it will go into dash and be part of the Facet system, so you can customize it or build different Facets for it with different modes of operation.

The operation of menu should not be modal, are your inputs should be free and it should auto-dismiss itself.

I do plan on reworking the laser system so it goes through when it doesn't reach anything in the UI, but that needs the whole laser system reworked, don't plan to do it for the current one since it's going away. If we do the trigger from center though, there will be an element in the center that you can drag from.

What do you mean that some objects are impossible to see through menus?

Why do you feel that destroy and duplicate aren't as easy as they used to be?

@Abysmal2134 Tools locking your inputs doesn't have anything to do with this menu, that's up to the tools themselves. This won't be changed, because there's no choice. If the tool requires use of your touchpad, it will block it for locomotion, otherwise you'd be moving randomly while operating the tool.

@DeliriousJax Yeah I'm considering making the double click an optional thing. Originally this was before Undo so it was much more important, so I feel the default with single click is easier for users, but it shouldn't be too difficult to add optionally.

What exactly do you mean by the "Button" resetting its colors? Do you meant he list of colors it configures? Do you have any reproduction steps? I'd make a new issue for this, since it's a bug unrelated to the context menu.

Can you also tell me more about how you use menus on both hands? With this one usually you just select something quick and it goes away, so you shouldn't really need to have two open simultaneously. But I can allow summoning two at the same time if necessary.

[TehTurk]

Locomotion: Not Denying the Toggle, I personally had no issue, but this was input from the community, because not everyone is willing to voice their concerns/issues in a proper manner that can get conveyed properly. If it's facet related that's acceptable, but being able to quick cycle locomotion should be considered important since people are switching Constantly Maybe I'm misunderstanding the concept of Modal, but how you described and from how I looked up, you had to access one menu to access another, this shouldn't be the case. (As with the Locomotion, because a new Radial spawns on Click), Why I wrote some of the suggestions of, having the locomotion area be more of Boolean Select, but having more visible to choose, similar to how some of the other default tools behave (Referencing the Glue Tip)

Menu: Slight typo apologies, I originally want to say Object interaction in general with them is strained if it's giant or something else is going on, Logix etc. Because depending on where you grab the item itself, you can't as easy just pop your head in to see your menu, or even have the menu render over the object itself. Because sometimes you just only need to see a little bit of the menu to orient yourself and make the respectable action. If possible have the Menu follow your hand if it passes a certain boundary if your doing the TriggerDrag Quick Select?

Dupe Delete: Sorry if that came across as a feely statement, but it is objectively slower now compared to the old style of duping and deleting considering you could have your menus open and just grab a bunch of stuff and delete or dupe it (Muscle Memory or not). You must reopen the menu every time for each attempt to dupe or delete a separate item, (unless your spawning in one space specifically) There was some talk of selection locking as long as your holding down something and another to repeat said action (Say like Trigger Drag, pressing menu will repeat the action as the Menu is locked in place when on drag, and still gives us old and new functionality) But I understand that could be customizable, but the base function of the Wrist Menus should be enhanced from previously, not removed, or altered negatively. I understand the appeal for New Users, but we should still try to keep some of the Pros from the old menus as much as possible.

[DeliriousJax]

@Frooxius I'll test the button colors more and see if it is recreatable. But they basically went back to the default colors of the component upon reloading that world up. I was linked this when it was brought up, is all.

Two context menus at once is more of a favor thing, but I very often use both the material tooltip in my left hand and dev tool tip in the right hand and kinda... Just go to town. (I do the same with other combinations of tooltips as well, so it happens more often than just in certain cases). Often when importing and working on models with multiple materials, I'll be creating the material on the left and opening the model's inspector on the right at once. I was kinda hoping to go all kung fu mode with the flicking of the wrist with both hands and a bunch of context menus.

[Frooxius]

@TehTurk Hmm I'm still not quite understanding the issue with the locomotion. The toggle is something I wanted to get rid of for a while, because it's been a problem that's been making the switching really slow (I'd often have to carefully cycle to get the right option and sometimes miss and have to cycle over again).

This new system lets you pick locomotion directly, regardless of how many are there, with the goal to make the constant switching faster.

However this is all going to be moot anyway, because the locomotion there is temporary, while the rest of the new UI is being built.

For the rendering through things, yes, that'll come soon! Once the new laser is in, I'll make it show through stuff, so big things won't obscure it anymore.

For the duplication and deletion I see. I haven't realized you were talking about that mode, I was just comparing standard duplication/deletion where you grab and pick since that's what is used the most.

I'm not sure if it's possible to achieve that behavior with the new menus without making things over-complicated. I do try to preserve as much as possible, but not everything will be possible since the system is different.

However a lot of these and upcoming changes will be a lot about "rebalancing" the system, so it's easy to get started with and you access the more advanced functionality afterwards. E.g. the duplication/deletion problem can be solved by having a specialized tools (there's one for duplication already, but it can be updated) and quick access to them through Facets.

@DeliriousJax I see. I suppose I could make an option to allow two at the time for such use-cases, but it's going to come later if that's ok.

[ProbablePrime]

@Frooxius Let's say I open the locomotion menu by mistake. How do i close it without changing locomotion modes?

Two possible options here:

• Highlight the current Locomotion setting so i know which one i'm on
• Add a new button called "Cancel" or "Close" which closes the locomotion menu taking me back to the main menu.

I think the first is ok as thinking back to things this morning moving my hand out of the menu's range will close it as an effective cancel.

Thank you for replying to my feedback!

[Frooxius]

@ProbablePrime Yeah you just move your hand away and the menu goes away. There's a subtle highlight for the current locomotion, but I do want to make it more obvious on the button itself.

Do you think the moving of hand away is sufficient (+ better highlight of the current one)?

Thanks for replying to my reply to your feedback! :D

[ProbablePrime]

Making it more obvious should work. I'm slightly colorblind so echo some of the other color and highlighting feedback. I just didn't want to repeat feedback unnecessarily.

[Canadian-Git]

Froox, thank you much for the update, new design is nice and clean looking, very favourable impression.

Feedback:

Echoing the @TehTurk and @Abysmal2134 comments above, the ability to drag out a laser from the centre seems like it could have a good feel with this design, and little more forgiving for a user with the fine motor skills of a potato. Similarly, perhaps letting players hold down the menu button, drag out their laser to highlight an option, and then select that option on button release could be very quick and easy to use.

Likewise, I'd be happy to see the undo/redo return to main hand when using tools, as I can barely trust my off-hand to scratch my nose without punching myself in the face, and swapping between seems to slow things down a bit.

Bugs:

Everyone else already reported everything I saw. You people are fast.

[Frooxius]

Ok majority of the main problems and issues should be fixed now in 2020.4.7.1222! Some of the stuff will come later, like styling, configuration and such, as other new features will roll around.

Let me know if there's anything crucial I missed, it's always a bit tricky making sure I cover everything.

[shiftyscales]

I've noticed that when a user respawns, the new center quick-select circle will spawn at their user root/feet prior to the first time they open their context menu, @Frooxius.

I also feel it could be beneficial if sub-menus were achored at the initial menu position to ground where the menu will always be after it has been opened, which would promote muscle memory development by having a fixed point in space that is defined as the center-point for each time the menu is opened.

E.g. if I am using flicks to navigate to the locomotion menu, the locomotion menu (or any arbitrary submenu a user could make with facets) will spawn in a different position every time- wherever my tip happened to be during the selection.

If the menu remained anchored to the spot when the context menu was first opened- it would promote more consistent muscle memory development. It feels more intuitive as pressing the menu button sets the position at which that menu and all subsequent ones will spawn until it is closed, and reopened- a deliberate action.

[Frooxius]

Yeah I'll fix the ground thing. It's just an initialization thing, where it doesn't get initially hidden.

The submenu positioning should center again when you open it. Otherwise the newly opened one ends up being at the corner and you can easily dismiss it by accident. Also you have to travel across the whole menu if you want option on the other side. With current solution it recenters, allowing you to continue from the center again.

Keep in mind the locomotion menu is a temporary solution before it's moved to facets. Once the rest of the system is reworked most of the stuff will be just 1-level or spawn a different menu (e.g. temp color picker) so this might not be an issue long term.

[shiftyscales]

Yeah, I was mostly using the locomotion menu as an example since it's already there. I was thinking the same of any arbitrary submenus users could make on that part of the UI as well.

While I appreciate the thought that it could potentially dismiss accidentally, that sound more like another underlying issue that could be resolved.

By anchoring the center point, it allows the user to quickly flick back to the center between clicks into the sub-menu, so the needing to travel the length of the menu doesn't become an issue.

It's definitely not a crucial behavior to look at/modify at this time, and I couldn't say for sure until I tried it- but intuitively, I found my hand recentering itself everytime I pressed a button on the context menu, which ironically left me at the edge of the circle, and sometimes accidentally dismissing it- the exact behaviors you are wanting to avoid.

It's as though it were a pre-programmed muscle memory from someplace else. Intuitively my hand nearly always moves back to wherever the center position last was between clicks.

Perhaps it's because the inertia of my moving hand makes it difficult to stop in the exact center of the newly spawned context sub-menu instead of flowing back to the fixed reference point of the original circle.

[TehTurk]

Hiya Thanks for the Additions Froox <3 Seriously always appreciate the effort ^o^! Sorry if I or some of us are reacting really strong, we just want it to be good and proud of what we can add to the development process as a community. So here's some of the reflections from day 2 and from me going around asking around. The Flick Functionality is great, but there is a few concerns with it

• Accidental Activation is a thing, and can happen if your not careful, as originally I didn't think you'd implement in a way where it'd activate the menu on contact with the selection, so this was unforeseen
• Drag Flicks not Chaining (Good example is Locomotion but it's temporary, but the selection should carry over) A way to have the selection be activated on the generation of a new Radial because it requires to input another button press again
• Initiating the Flick is kinda tricky/hard to do fast in a comfortable way (I have settings on my Index so my button press is at .50 TriggerStrength or so, so even then it feels/plays kinda lacking, imagine how it is when people have to bottom out to do a quick gesture)
• Aimed Duping is somewhat too tricky, but is managable with two hands, or doing some weird tricks.

So here are some of the couple ideas/concepts to resolve that:

• Have a way, so that if your dragging, the action doesn't occur on selection collision, or that there's enough time for a Trigger Click to have occured for the flick to occur., Some ways are:
• Setting the collision point to be the out ring of the arc, vs the inner ring
• Having the Selection be tied to Trigger Hair > .05 or .1 Threshold, vs actually bottoming out your trigger, all controls have Triggers and Trigger Hairs, this would be optimal in a way
• Detecting Trigger before the Radial Spawns, So if your holding trigger, hitting menu will have the drag mode initiated right away allowing selection right away, so instead of Menu + Trigger, Your just holding Trigger and hitting menu a bunch of times to do a flick, but this can conflict with some tools, MatTip, GrabTip, etc (Thanks -Lucasro07)
• Duping had a few ideas but wanted to hear if you had any sort of possible ideas for this as well, because there was something of hitting grab will lock the menu to your hand, and let you repeat a function a bunch of times, or some sort of "Dupe" mode when you have a object grabbed, and essentially puts the dupe tool functionality into the context menu.

As always thanks for Listening, and I hope these add the design in some form.

[ProbablePrime]

Set Packing Root & Reveal Nodes's Text description overlaps horribly on the logixtip's radial menu.