Clicking an unset 3 state checkbox should default to enable, not disable

[BretJohnson]

This issue applies to both bool properties and combinable properties that support unset and thus show 3 state checkboxes.

In both cases, when a checkbox is in the unset state and the user first clicks on it, it moves to the false / unchecked state. It probably should go the true / checked state instead, on first click, as that's what the user would likely expect. It's what Android Studio does as well.

[BretJohnson]

@cobey or @JonDouglas can you confirm this is the UX we want.

[ermau]

This starts at -1000 for me, it's not the default behavior for Windows or by extension VS for tri-state bools in an indeterminate state.

It probably should go the true / checked state instead, on first click, as that's what the user would likely expect.

This isn't based on anything other than "that's what Android Studio does". Given it is not the normal behavior for this element elsewhere in the host platform, I'd argue that it's more likely to be the opposite of what the user would expect.

It's what Android Studio does as well.

Matching Android Studio has never been and is not a goal. We live in VS. This argument is irrelevant to any other target platforms we support.

[BretJohnson]

Tree control tristates behave this way in VS. Can you give an example of others? I looked but didn't see any.

[ermau]

What is "tree control tristates" ?

Can you give an example of others? I looked but didn't see any.

The checkbox for the actual value we're discussing in the first place:

Also just checkboxes in WPF by default.

[BretJohnson]

By "tree control tristates" I meant the Exceptions Settings dialog, for instance.
And by examples in VS I meant, of course, outside of Proppy itself.

[ermau]

And by examples in VS I meant, of course, outside of Proppy itself.

That's from the WPF designer for the Checkbox control.

[BretJohnson]

Ah, interesting. When does the WPF designer show 3 states like that? I tried but didn't see that.

[JonDouglas]

To add perspective, the experience of the three-state-checkbox having to click twice to enable a property seems like an extra click compared to other three-state-checkbox designers like Android Studio. What I expected was the following:

1st click - Enable
2nd click - Disable
3rd click - Unset
Repeat

If we do not give the unset option again, users will have attributes they may not want in their layout set to either an on or off state. It would then require the work of going into the layout file to manually remove these when the designer could do that.

[ermau]

@JonDouglas The value can be reset by hitting "reset value" in the property menu, it does not require going to the layout file.

You're basing your first-step expectation on a single case: The option is off by default and you'd like to turn it on with the least clicks. What if the option is on by default and you'd like to turn it off? This is just as likely of a scenario and therefore I see no actual advantage to biasing towards the option that runs counter to consistency inside the host IDE and OS.

[JonDouglas]

@ermau I would not have ever known about this context menu as I thought it was just a visual indicator for the property value state. Thanks for letting me know about it! It's been years since I've done WPF development and this seems very familiar now.

My expectation is based on a single use-case as I'm just jotting down my perspective, and by no means do I understand the full situation and concerns. I was just directed here based on my observations on general 15.8 Android Designer feedback.

[BretJohnson]

@JonDouglas why don't you try the other checkbox scenarios in Android proppy and see what you think. Check out combinables (multi checkbox properties), where some of them behave as you suggest (click defaults to on) and others don't (with the arguably surprising behavior that clicking on a checkbox toggles a different, unrelated, checkbox).

So we basically have three sets of behavior currently in the Android property editor & aren't consistent internally. Arguably, making 3 state checkboxes default to on by default solves all of those issues, making things simple & consistent in those three cases (and consistent with Android Studio, which some of our customers also use).

As for other Windows UI, 3 state checkboxes are relatively uncommon and when they appear I've seen them behave in different ways. My sense is that the behavior (default on or off) generally depends on what makes the most sense given the context, even if the Windows 3 state checkbox control comes out of the box defaulting to off.

Though user feedback here would be ideal, to see what users think of the current behavior, especially for the combinables. Maybe you can get some.

[ermau]

why don't you try the other checkbox scenarios in Android proppy and see what you think. Check out combinables (multi checkbox properties), where some of them behave as you suggest (click defaults to on) and others don't (with the arguably surprising behavior that clicking on a checkbox toggles a different, unrelated, checkbox).

This is a different type of editor and acts differently, as I've explained: #220 (comment)

The difference in behavior is derived from the platform's implementation of IValidator: https://github.com/xamarin/Xamarin.PropertyEditing/blob/master/Xamarin.PropertyEditing/IValidator.cs
There's an extensive discussion between myself and Jérémie in the channel regarding this, but the TL;DR is that some flags properties have a no-flags value as valid and some have that as invalid. The former follows the expected behavior, the later is for when it's invalid we set a value. The "unrelated" checkbox I believe is a bug, IIRC it's supposed to check the one you selected in the cases where it can't have none selected, I'll double check on this.

---

At this point I'm going to go ahead and close this issue. We've moved into bike shedding and a no sufficiently compelling argument has been made to demonstrate this would be a definitive benefit, let alone make it worth the issues that changing this behavior presents. Fundamentally the issue being worried about here is practically non-existent. In the cases where a user might expect the opposite behavior, the included behavior here will be learned clearly and instantly. The "extra" click takes only a fraction of a second.

• For other checkboxes in other designers in our host platform, this is not the expected behavior. Acting like Android Studio has never been a goal. In cases where there is a precedent that differs between VS and AS, we will choose VS.
• Assumptions are being made that the user will always want to ensure that a property is on moving from an indeterminate step.

As for other Windows UI, 3 state checkboxes are relatively uncommon and when they appear I've seen them behave in different ways. My sense is that the behavior (default on or off) generally depends on what makes the most sense given the context, even if the Windows 3 state checkbox control comes out of the box defaulting to off.

You can not make assumptions about what makes the most sense given the context in this case. To do so would be to know the most commonly desirable state of every Boolean property in Android and base the decision on that. Even if you could know that, you'd just go back to being inconsistent with other platforms.

• False equivalency between "indeterminate" and "off." Even if you could make this argument for Android in-particular, you now have either changed every other platform for the benefit of Android, or created extra plumbing to create and maintain for the sake of a questionable feature.

The time spent looking into and discussing this issue would have been better spent on creating a solution for default values for the Android platform. Once there are default this issue becomes moot, as the properties will not be in an indeterminate state to begin with. It is Jon's prerogative if he wishes to investigate this issue with customers, but I can't say I'd recommend it.