changing a setting in the MRTK configuration is too difficult for new users

[ForrestTrepte]

Describe the bug

The first time I used the MRTK configuration settings I was confused about how they work. Now that I understand it's not too bad, but they can still be quite cumbersome to change. This will be one of the first things that users experience with the MRTK and we should make this easier.

In my opinion, usability problems include:

1. Very deeply nested settings.
2. Read-only settings that must be cloned before they can be edited. (Combined with the nesting, this requires you to clone multiple times, with different subsections and subsubsections.)
3. Clone button brings up dialog with options that seem unnecessary.
4. Cloned settings take you out of context from viewing the whole tree to viewing a subsection by itself. You have to reorient yourself and reexpand things to find the setting you wanted to change.
5. This works differently than the standard behavior of settings in the inspector that Unity developers would be used to. I wouldn't claim that everything is absolutely ideal about Unity's settings approach, but the other Unity software I have used has settings that are easy to change and work in a familiar well-understood way.

To reproduce

See this video which demonstrates the steps which must be performed to change a setting, from the perspective of a new user: ChangingMrtkSetting.zip

4 minutes. Dozens of clicks. Lots of opportunities for confusion. Just to change a setting from Gesture to Articulated.

Expected behavior

Changing an MRTK configuration setting is obvious and easy. Preferably works in a way that will feel familiar to experienced Unity developers.

Your Setup (please complete the following information)

• Unity Version 2018.3.9f1
• MRTK Version 2.0 RC1 Refresh

Target Platform (please complete the following information)

• Any

[ForrestTrepte]

This may be related to #3545, but I think that's a larger issue. It looks like a fancy design patterns thing that I can't really fathom, so I wanted to open this issue just to focus on the usability aspect of changing configuration settings. But they may be interrelated.

[wiwei]

This is something that many folks have raised already, and something that we're aware of. We're thinking about ways that we can address this going forward.

The issue linked above is designed to make things less painful, though obviously because there's still the single massive object and it's profile there's still that problem.

[ForrestTrepte]

Here are some potential alternative ideas for addressing this:

1. Put settings on regular old Unity game objects in the scene. Everything would understand how this works and it would be easy to extend/browse/add/remove different components. MRTK could include a default settings prefab. Unity makes it easy to override a prefab in your scene, accepting its defaults and overriding particular settings without duplicating the settings that are inherited. (Unity also now has new prefabs features with nesting and inheritance that I haven't tried yet, but seem like they would be helpful.) The extensibility of MRTK (ability to pull settings from multiple independent components) would complicate this somewhat, but I bet we could find an approach for automatically pulling together a scene object with children containing the settings for just the systems you are using. Embracing an approach like this could allow also allow us to remove special case code for MRTK's unique way of making settings and this would be easier to maintain and easier for developers to extend by adding new functionality and new MRTK components.
2. Just clone everything right off the bat. As soon as you make an MRTK object make a settings file and also clone all the subsettings right next to it. Now everything is editable. (Not sure what would happen when new subsections are added in the future--hopefully they could automatically clone the new sections when a previous project is opened?)
3. Pack all settings into a single file that can be cloned all at once. Not sure how you'll back the extensible set of subsections within this file. Would require custom serialization work?
4. Auto-clone on edit. Make everything editable. Whenever you edit a field that is still using a default settings it will, behind the scenes, automatically clone that section creating a new file in the generated CustomProfiles folder. If desired, at a later time you can always move/rename this file.

Note: There may be a better solution. I'm just throwing out some options. Ideally, there's a way to simplify this so that the settings system itself can be easy to understand/maintain.

[wiwei]

I think that going forward something that spawns out of #1 is probably where we want to go, as #2-4 are kinda just bandaids on top of the system. We could do a lot of work making inspectors nicer, or making cloning more understandable, but at the end of the day it's still such a foreign concept that new users will still need to pay that tax.

I just want to be transparent here that doing something like #1 would need to be thought through with perhaps a larger change in the way we make MRTK objects used (i.e. monolithic vs individual components), and is something we'd need to take significant time and due diligence in doing.

[StephenHodgson]

Thanks for the feedback @ForrestTrepte

I'm def not a fan of 1 as it's the breaking from the Monobehavior that's the goal here, and one of the key principles behind the original design. (Even newer Unity stuff is moving towards more ECS and DOTS which all try to break from this same thing) We tested and measured that it was a 60-70% increase in speed. Doing 1 goes back to the way things used to be.

2 is already doable, and is one of the two options on the MixedRealityToolkit GameObject when you first configure the system. Part of why we didn't just clone right away was we wanted to tell the story that everything should just work out of the box. Like magic. With a single click. I think that's a powerful story.

3 is kinda a stretch, as there's a lot of data being stored, even for a single profile. (Take a look at the mapping profiles, big arrays). Each profile is a ScriptableObject and gets serialized as such.

Now 4? Yes, love this idea. I think this is the most interesting and the best solution. I'm already thinking about how to accomplish this.

[ForrestTrepte]

Thanks for explaining the thinking behind the original design, Stephen. I'll admit that #1 is my preference because it is more familiar and easy to use/understand. But I think the others could also be viable. You do raise a point, though, about game object overhead. When I developed a Unity game with tens of thousands of units I had to break with game objects for performance reasons. I am surprised that for settings and small numbers of monobehaviours, such as the widgets in a typical mixed reality scene, the overhead of game objects would be significant. Would it be viable to use monobehaviours for most parts of MRTK, while processing updates on large collections of objects via ECS/DOTS? I haven't tended to work on HoloLens applications that were CPU-bound, so I haven't profiled at this level.

[ForrestTrepte]

Can you explain how to do #2? That sounds really great. I have been doing Add To Scene and Configure and then the options I found were Copy & Customize (only clones top level) or Create new profiles (creates empty profile--you'd have to fill everything in).

[Railboy]

Read-only settings that must be cloned before they can be edited. (Combined with the nesting, this requires you to clone multiple times, with different subsections and subsubsections.)

This absolutely needs to go. I'm 100% comfortable with profiles at this point and I still find myself frustrated by this limitation daily.

[Railboy]

@ForrestTrepte You're correct that #3545 is related to some of the issues you're raising.

Put settings on regular old Unity game objects in the scene. Everything would understand how this works

In the mrtk_development branch, if you open your config profile's Editor Settings - after cloning your read-only profile, natch 👍 - and check Enable Service Inspectors, MRTK will generate a set of game objects that mimic the kind of standalone objects we're all used to dealing with.

This doesn't change the way services actually work, nor does it change where config data is actually stored. So we should continue to explore some of the other options you mention. But it does provide a more familiar (and non-nested way) to view and interact with services / settings.

[StephenHodgson]

I wasn't a big fan of the Russian nesting dolls either.

Put settings on regular old Unity game objects in the scene. Everything would understand how this works

imho the way it's setup in the Project tab is essentially the same way. It's something you select in a folder hierarchy vs a scene hierarchy. Not much of a difference in workflow, just a different window you're selecting items in. That's why I don't agree with the Facades in any way. All of the services and systems don't exist in the scene, and don't require any sort of representation there.

Would it be viable to use monobehaviours for most parts of MRTK, while processing updates on large collections of objects via ECS/DOTS?

Yes, but then we'd loose out on that huge performance gain I mentioned earlier. Also Unity is moving most development to ECS/DOTS very soon, so it makes sense to go ahead and start nudging people that way. We thought of the toolkit as a stepping stone to ECS/DOTS workflows, and should be easily compatible as we've removed a lot of the Monobehaviour dependencies already.

Can you explain how to do 2? That sounds really great. I have been doing Add To Scene and Configure and then the options I found were Copy & Customize (only clones top level) or Create new profiles (creates empty profile--you'd have to fill everything in).

@railboy, didn't you update the clone tool to facilitate this already?

I think the idea was that the default profiles were enough, and that the toolkit is already configured to meet 80% of most developers needs.

You should only have to clone a profile to meet a specific edge case. We envisioned that people wouldn't actually be editing the defaults too much unless they really wanted to get into customizing all the things.

Although there were other profiles (like the input actions) we thought people would customize a lot per application, based on all the different actions a user can take it it. That's mainly why we choose to only clone what you need, and leave the rest alone.

I've noticed people tend to want to just jump in and customize all the things without really understanding what it does 😅 which I'm the same way. Best way to learn, imho, but can quickly lead to confusion. Part of why most of the inspectors are heavily documented with notes and tooltips.

I think idea 4 is the most viable, having auto cloned the default makes it easier to also reset if you make a mistake, but I think the only hurdle there is preventing the clone method from selecting the newly cloned profile. I think the only downside is that it'd create a ton of new files immediately and it'll trigger an asset import. So it'd be something that needed to be done when the user Configure...s the toolkit, so there's no noticeable delay.

[Railboy]

@StephenHodgson Yes I did some work on the profile clone tool but it could still use some work.

I've noticed people tend to want to just jump in and customize all the things without really understanding what it does 😅 which I'm the same way. Best way to learn, imho, but can quickly lead to confusion. Part of why most of the inspectors are heavily documented with notes and tooltips.

Agreed, that's how I learn too, poking around and breaking things. I get the need for a safety net but kneecapping that natural instinct and all the potential learning along with it really seems like the nuclear option. A better safety net might be a big fat RESET TO DEFAULTS button on default profiles. Then you can tweak whatever you want and roll back if it breaks.

All I know is the non-editable default profile just isn't working. For first-time users it's alienating and for regular users it's super obnoxious.

[StephenHodgson]

It wasn't supposed to be a safety net, per say. It was intended that the profiles would be the defaults for most people's use cases.

Every decision was intentional with a lot of thought behind it, and having the default profiles be locked down was a good idea as we wanted to ensure that the toolkit worked out of the box, like magic, and we didn't want people to edit them only to grab an update and get their edits stomped.

Although now that I've updated my fork to use the Unity Package Manager (upm), it's no longer needed to lock them down as the packages grey out/lock them down by default and upm also offers an easy way to make a copy of assets and prefabs into people's projects.

It's really not much of a difference in the workflow from what Unity is also doing with their packages.

All I know is the non-editable default profile just isn't working. For first-time users it's alienating and for regular users it's super obnoxious.

I think this statement is a bit dramatic, but automating this initial clone will go a long way to help ease the process.

[Railboy]

@ForrestTrepte Just looping back to make it clear that we're hearing your feedback on this issue and on the setting discoverability issue in #4243. Keep posting this stuff, it's really valuable.

[SimonDarksideJ]

Completely agree with the identification of the source issues being identified here and have to say we do know.
But to explain slightly, you need to understand its history. The first major challenge was to break the old chains and make it work, deliver a solution that could be defined by a core set of configuration and break the old prefab / Go style of maintaining the Core solution. This doesn't relate to SDK / scene stuff, just the whole backend. Additionally, we had the challenge to make it super easy to radically change the project at run-time, swapping abilities/capabilities to enable projects to work in a true Mixed Reality fashion.

However, this was all (and we're still there) in the "Making it work" phase. Now what we need to work towards "Making it easier to use", a few ideas have been mentioned above and a few haven't so here's my current thinking based off talking to devs, feedback and notes:

1. one pattern is to replicate the new Unity preferences screen, having a standalone editor window for managing all configuration. This is probably the ideal case but tricky to implement and make it dynamic. In the new editor UI, this would effectively be a complete rewrite of configuration screens.

2. Another is a custom editor window, similar to the above but more editor focused. has the benefit of being able to reuse a lot of the current inspectors.

3. Configuration asset navigator. Some devs dislike the idea of a single all master powerful config screen but do want a navigatable / breadcrumb approach when working with the individual configuration assets. Taking what is there but aligning it to modern standards used in web apps.

One underlying thing surrounds the "defaults" and I feel this we should be able to change easily now. Currently, we start with read-only defaults forcing you to clone to start configuring. So maybe we should flip this so that we START with a copy of the defaults and then give an option to reset (copy) the defaults should we want to go back. That gives an editable version straight away, keeping the comfort for being able to get back. The clone / new options should still stay for flexibility with working with multiple configurations.

Thoughts.

[StephenHodgson]

One underlying thing surrounds the "defaults" and I feel this we should be able to change easily now. Currently, we start with read-only defaults forcing you to clone to start configuring. So maybe we should flip this so that we START with a copy of the defaults and then give an option to reset (copy) the defaults should we want to go back. That gives an editable version straight away, keeping the comfort for being able to get back. The clone / new options should still stay for flexibility with working with multiple configurations.

Yes, 💯 definitely this

[StephenHodgson]

@SimonDarksideJ I remember us having a conversation about making our own preferences window as well.

Imho that's really the key I think and being able to enable the breadcrumb navigation is going to be key here.

[ForrestTrepte]

I agree. Starting with already-cloned setting would go a long way.

[ForrestTrepte]

By the way, if we kept settings in prefabs we'd get the revert functionality for free. Unity's new prefab features would even allow you so see each setting you have changed from the default and to revert changes individually. This works really great in MRTKv1.