PostProcessStack has been gaslighting me all these years!

Question: Of these two images A & B which one of these toggles shows the is 'Enabled' state?



If you answered B then congratulations you are correct and a great big smelly cheater! Cos you and every normal person would really answer A. That is unless that is you were the UI designer for PostProcessStack packages, in which case as someone whose parents didn't love them, decided that the UI toggle in B is when its enabled/on!

For nearly a decade I've always been puzzled by the 'Enable this effect' toggle in the PostProcessProfile as I always felt it was the opposite of what it should be, which became very confusing when I want to disable or enable effect and getting the opposite results.

I've spent countless hours reading documentation and forums trying to work out why it worked like this, assuming I was just misunderstanding its purposes. Turns out I was right all along, it works exactly how it should, but its the UI presentation that confused me. A confusion that returned every time I had to use the PP stack in depth, which was only occasionally, hence why I never rewired my brain to the dumb UI.

I finally worked this out by copying the code from the PPS into my own editor inspector and explicitly logged the details as shown below, even to the point of removing the MiniButtonLeft/right styles to show the normal toggle operation!


Maybe you'd like to answer that the current UI is correct, for which I counter with 'console' image above and that when a button, toggle, tab is selected it is highlighted, the same highlight that is used when selecting from say the PlayerSettings list and other places. It seems clear to me that selected items are highlight in the lighter color and the non-selected is darker - which we get the exact opposite of in the PPS UI!

So its way too late to get this fixed in the package by Unity, especially as I'm sure many devs are used to it by now, so swapping the UI behaviour would be too confusing. It could be fixed by say introducing the blue highlight to the active toggle background graphic, which wouldn't be confusing, but I don't see Unity doing that.

Now I'm left pondering how could I fix this? Sure I could embed the package and inverse the boolean value on the toggle code, but that loses the ability to easily update the package and would be very confusing to anyone else that uses it. I tried looking to see if there was a simple way to inject/override the behaviour, but came up empty. So if anyone has any bright ideas I'd love to hear them.

In the meantime I see Amazon Prime on Twitch has given away StarWars Rouge Squadron 3D for free today, so i'm going to go and relive my past playing that instead.

 

Have you tried the "Light" theme?
https://support.unity.com/hc/en-us/...ty Hub and,Light depending on your preference.

 

Good call and I should have said that while writing the post I saw a picture of the light theme and did wonder if it would help, but I tired it and its pretty much the same.

 

I'm used to using the physical buttons which that UI widget is emulating. Press one and the others pop out. The pressed one is in shadow because it's recessed from the others.

Of course, we're talking about ages ago, on mostly analog tech, such as tape players.

I agree the UI there is silly. If there are only two options then the selection visuals need to be more than just "different". I'd change contrast levels significantly, add an element to the selected item, something like that. In this case, showing more of the 3D context of physical buttons being pressed in/out would help.

Also agree it's separately silly just due to inconsistency.

It's not just a Unity issue, I see it a bit, including in at least one game I've played recently.

 

Yeah I remember those, Walkman comes to mind

Alas as you point out the UI here lacks the 3D context appearance to make that work, worse that it ends up being inconsistent from the rest of the UI ( as I also mentioned ). I also think times have changed, Google Materials has a similar toggle, but there its a slider that moves left/right and normally has very clear coding ( color/saturation/single word ) to express the actual state.

That made me chuckle as I've been just as guilty, though I think only within the confines of personal projects. In client projects I think its always been factored out during assessments and critiques.

Oh well for now I've embeded the package and fixed the code. It wouldn't even be hard to add a preference as PPS has its own tab in the preferences window as to which way to show it. I will say the moment I changed it made an instant improvement, even now I can glance over and correctly 'read' the state of the effects in the Profile.

For completeness here is the change to the 'TopRowFields' method in PostProcessEffectBaseEditor.cs

Code (CSharp):

1. bool enabled = m_Enabled.boolValue;
2. enabled = !GUILayout.Toggle(!enabled, EditorUtilities.GetContent("On|Enable this effect."), EditorStyles.miniButtonLeft, GUILayout.Width(35f), GUILayout.ExpandWidth(false));
3. enabled = GUILayout.Toggle(enabled, EditorUtilities.GetContent("Off|Disable this effect."), EditorStyles.miniButtonRight, GUILayout.Width(35f), GUILayout.ExpandWidth(false));
4. m_Enabled.boolValue = enabled;

All I did is swap the negating of the result and enabled value in both Toggle lines.
Wish there was a way to do this without embedding the package, but still not found a good solution.

Edit:
Screw it - I changed the above code, restored the negation, but deleted the parameter EditorStyles so now it looks like the typical toggle buttons ( see image C above ) to make it clear the code has been changed.

Code (CSharp):

1. enabled = GUILayout.Toggle(enabled, EditorUtilities.GetContent("On|Enable this effect."), GUILayout.Width(35f), GUILayout.ExpandWidth(false));
2. enabled = !GUILayout.Toggle(!enabled, EditorUtilities.GetContent("Off|Disable this effect."), GUILayout.Width(35f), GUILayout.ExpandWidth(false));

 

Yeah, honestly, the whole thing there is dressing up a check box in a way which just interferes with clarity. I understand why they wanted to make that toggle more visually significant, but it also became ambiguous to... anyone for whom vintage tape decks don't immediately spring to mind..?

Anyway, Option C is the clearest of the options.

This was in some big budget, semi-recent game. They use the same styling in their confirmation prompts as they do in their other menu screens. It works fine in other menu screens as there are always a few options, so the current selection is always clear. But in a dialog "Yes" and "No" or whatever just look different, so I find that I'm always waggling the thumbstick to check the selection based not on how it looks, but on which directional input was used.

There's at least one game out there which thwarts this strategy by having the input "wrap around" the selection. Again, in a menu with multiple options this is helpful - if the user wants to go to the top, let them wrap around the bottom to jump back up there, it's great. In a confirmation dialog with two options, where the only visual difference is that one is white and the other is black (or whatever), where any input just swaps them around... fingers crossed the previous menu is still visible on-screen for our users to compare button styling, assuming it's consistent.

Otherwise, welcome to Dialog Box Roulette!

 

Yeah I'm totally stealing that

 

I've gotta admit, I like it too.