Allow content to open a color picker in userspace

[Gawdl3y]

Is your feature request related to a problem? Please describe.

The mentor team is working on a default context menu template to apply to many avatars, creating prefabs for them and sending to avatar authors as ResonitePackages to distribute. Many avatars have the option to adjust various colors on them, thus necessitating context menu entries to control. While this is currently easily achievable with the ButtonEditColorX component on a context menu entry, there are a few problems with this approach:

• World permissions (such as the default Spectator role) can prevent the user from interacting with their color picker
• Other users can mess with the color picker that is spawned, changing the color of the user's avatar or running away with it
• The color picker is easy to lose (or not see in the first place, such as when spawning inside of existing geometry) in various circumstances since it doesn't follow the player by default

Describe the solution you'd like

My proposition is to add a boolean property to the ButtonEditColorX component that enables it to open the color picker in userspace instead of worldspace, similar to the keyboard's behavior. This would mostly solve all of the above problems.

Describe alternatives you've considered

The current workaround is to manually build HSV-style sliders/settings inside of the context menu, which results in an incredibly clunky, frustrating, and unintuitive user experience when compared to interacting with a native color picker, while ultimately also being less flexible.

The mentor team may also just choose to use the color picker as-is with the above problems for the time being, given the color picker UX is simply much better than a purely context menu-based HSV solution.

Additional Context

Beginning of the relevant discussion in the mentor server: https://discord.com/channels/1088855599627911279/1264729249705889813/1265206171556384844

Requesters

Gawdl3y, Jack / jackthefoxotter, Sharkmare / eldritchkaiju

[Frooxius]

This is a bit tricky, because we don't really have any sort of framework for things like this - all the editing mechanisms and interfaces assume they exist within the same space.

Userspace is a completely separate and isolated "session", so it technically has no knowledge about what's inside of the world - and therefore cannot really edit it. Userspace itself is also not particularly designed for handling editing interfaces like this.

With that, this particular solution is not very viable - it would either require some hacky approach (which we're very unlikely to do) or significant re-design and re-write of things - which would make this a really big task with potential pitfalls (e.g. we need to consider security of userspace - it contains privileged data and components, so anything in worldspace that would spawn stuff into userspace needs to be put under significant scrutiny).

As such, I don't think we'd be really likely to implement your proposed solution.

What I'd like to understand more is the problem and what could be done to solve these. Some of these are a bit confusing to me:

• World Permissions - if user cannot build, they cannot setup their avatar in the first place and will run into lots of other problems. Why not just go to a world with permissions to set it up?
• Other users messing with it - they can also grab the avatar and run away with that. There's a lot of stuff users can do to mess with them like this, so I don't understand why would this be solved specifically only for the color picker?
• Color picker easy to lose - it should just reopen when you click it? If it doesn't we can handle this

[JackTheFoxOtter]

The underlying problem that we've discussed was that if the user has certain customizations on their avatar, they should be able to use them. When a user is a spectator, they can still use their own context menu (by default), but they can't interact with other UIs, for example the color picker. The initial solution to this was implementing the hue, saturation and value sliders as parts of the context menu, but that just leads to terrible UX. We've changed this to use the color picker now, because the tradeof in usability absolutely wasn't worth the benefit of being able to adjust those even when you're a spectator, which shouldn't happen often in the first place, as you said, when someone is a spectator, they'll be limited one way or another (for example not even being able to resize by default).

I'm not sure if there's an elegant solution for this. How permissions work is something new users should learn early on anyway. I'm thinking if there's a way to detect wether or not the user has the required permissions to adjust the color, so we could at least add a visual hint to the menu so they know why nothing happens when they press the button.

[Frooxius]

I think best solution here would be to extend the context menu system to allow for more expressiveness with things you can do - e.g. providing more "primitives" and allowing to naturally inject custom UI into it.

[JackTheFoxOtter]

Potentially. Although another thing I've brought up is that I believe not everything should be handled through the context menu. In some cases, it can be easier to open a separate UI panel from the context menu, like a color picker, or a custom blend shape adjustment panel. How does the context menu differ from other UIs interaction wise? Like, what allows spectators to use it? Another alternative could be opening other UI panels in that "mode".

The context menu is the only option for avatar creators on other platforms to add UI, so many creators are used to just stuffing everything into there due to lack of alternative options, but in my experience, that often leads to a terrible and confusing user experience. For an avatar I'm currently working on, I plan to put blendshapes, material and texture settings onto a personal "customoztion" panel that can be toggled from the context menu, which allows for much better UX design. Would it be possible to mark such panels as "personal" to behave similarly to the context menu? I'd think the same could be useful for buttons some people have on their avatars.

[Azavit]

Wouldn't an other solution with a similar effect be:

Have a toggle on the color picker that allows one to open a "non-developer" version that doesn't have the security. (or any other way to spawn a non-developer version)

Have the ability to choose what slot a color picker spawns under. (This would allow spawning a color picker under a slot that is only viable to the user in the avatar)

If so maybe 2 new issues for those two features could be created.

[JackTheFoxOtter]

Have a toggle on the color picker that allows one to open a "non-developer" version that doesn't have the security. (or any other way to spawn a non-developer version)

Well, the issue in this case wasn't even allowing people to use it that aren't developers, it was allowing people to use it that are spectators if it's controlling something on their avatar.

When you're a spectator, you still have access to your context menu. That means that any sort of avatar customizations that you put onto the context menu can also be used in worlds where the user doesn't have permission to interact with anything. The problem here is that some customizations just aren't a good fit for the context menu, color picking is one of them. If your goal is to get the customization working even in worlds where the user only has spectator default permissions, this is currently encouraging you to jam everything into the context menu, which can lead to pretty bad UX design.

If buttons that are part of an avatar would be treated the same way as the context menu by default, I think that would mitigate this issue. Then it would be possible to create entirely custom local avatar control panels, which would allow for much more user friendly avatar systems going forward.

[JackTheFoxOtter]

To follow up - I am however unsure if this is something that would be a good idea to implement with the current permission system. It's already trivially easy to put disruptive avatar features into the context menu and use them even in worlds where you'd be locked to spectator by default.

A proper solution I could imagine might tie into hard permissions, the possibility to create "scoped" hierarchy access for avatar systems. That could allow users to create systems that affect their avatar, but prevent abuse by not allowing those systems to access or influence anything outside of the avatar's hierarchy on the world data model.

I think this would both allow avatar creators to create highly custom systems that aren't possible to create on other platforms, like flight systems of custom HUDs / interfaces to control parts of their avatar, and have those systems function in all worlds, while also improving security by allowing world hosts to prevent those systems from accessing anything outside of a restricted user's avatar hierarchies, without outright disabling the systems in the first place.

[Banane9]

Having a userspace color picker would at least provide an option for localized color picking #903