Avoiding double negations for checkboxes in Settings

lindhe

Hi!

When I'm browsing the Settings menu in pfSense, I frequently get confused by the double negations in checkbox labels. For example like this (from System/Advanced/Admin Access):

mixed positive and negative meanings in checkboxes

The first one is perfectly good – checking WebGUI Login Autocomplete will enable the autocomplete functionality.

The second one is bad – checking WebGUI login messages will disable logging of webConfigurator successful logins.

The third setting is probably the worst in my opinion. On top of having the same reverse logic as the one above, this one also has anti in its name which makes it even harder for my brain to parse it correctly. Just take a moment and read the help text.

Anti-lockout: When this is unchecked, access to the webConfigurator on the LAN interface is always permitted, regardless of the user-defined firewall rule set. Check this box to disable this automatically added rule, so access to the webConfigurator is controlled by the user-defined firewall rules (ensure a firewall rule is in place that allows access, to avoid being locked out!) Hint: the "Set interface(s) IP address" option in the console menu resets this setting as well.

Similar inconsistencies are seen throughout the GUI: some checkboxes enable the setting mentioned in the label, some disable it. Some checkboxes have inconsistent wording in their help texts compared to the setting label, and so on.

I think that having a ticked checkbox should denote the positive meaning of whatever setting is expressed, and that it would greatly improve the user experience if we could fix this. And while at it, we should try and make sure that the label and help text are well aligned for all checkboxes.

But I'm not only here to complain. Unless someone else can contribute this rephrasing quicker than I can, I would be willing to submit a PR and to collaborate to make this happen. I just want to make sure this would be welcomed by the maintainers before I put any significant effort into it.

What do you think? :)

darcey

I agree on your point about UI consistentcy and that checking a box is seen by most as a metphor for enabling something.
I also think there is a case in the UI for having a ticked checkbox disable something: When the default is enabled and you're turning off the default behaviour.
I'm not 100% sure it's used consistently in that way throughout the UI either.
Some of the info blocks seem to have a double negative about them but I that's the nature of technical documentation. It's challenging to be concise and at same time avoid some clumsy wording. Documentation takes time and I think netgate's done a good job.

Bob.Dig

My favorite, although it might not be 100% on-topic:

lindhe

@darcey said in Avoiding double negations for checkboxes in Settings:

I also think there is a case in the UI for having a ticked checkbox disable something: When the default is enabled and you're turning off the default behaviour.

I disagree. If the default behaviour is enabled, just make the checkbox be ticked by default so unticking it turns off the default behaviour. Or did I misunderstand what you meant?

@Bob-Dig Haha, no that one is 100% on topic. Good one, thanks for the data point! :)

darcey

@lindhe said in Avoiding double negations for checkboxes in Settings:

I disagree. If the default behaviour is enabled, just make the checkbox be ticked by default so unticking it turns off the default behaviour. Or did I misunderstand what you meant?

I think we agree the wording in some of the labels and info blocks, where checkboxes are used to disable behaviour, could be improved. I just do not see anything inconsistent in having a checked checkbox turn off, cancel or disable a feature or process. I am not aware of a strong UI convention that discourages this. IMO a checkbox or checklist is analagous to confirming a task should be done. A holiday list for example: Book a taxi, cancel milk, turn off electricity. Maybe the lack of a toggle button in standard web widgets means checkboxes are used in such ways that my view is just wrong.

lindhe

@darcey said in Avoiding double negations for checkboxes in Settings:

I just do not see anything inconsistent in having a checked checkbox turn off, cancel or disable a feature or process. I am not aware of a strong UI convention that discourages this.

I hadn't thought much about this until a friend suggested that things are much more intuitive when it works like I've described. At first I thought it was an oddly specific opinion, but I've adopted his view 100% on this issue. But I fully agree with you that this is a completely subjective opinion and I don't know of any widely agreed upon UI convention regarding this.

Maybe the lack of a toggle button in standard web widgets means checkboxes are used in such ways that my view is just wrong.

Your view is not wrong, and I think it's good if we can discuss this to explore if one view is more generally agreed upon than the other. I'm almost positive that there are exceptions to my rule, but I think it is the better rule of thumb.

Firstly, I think having checkboxes always be checked by default is not very helpful:

If pfSense change what the default values are, it would require changing label and description for the option, instead of just changing the checkbox to be unchecked by default.
If it is important to know what the system default setting is, that's pretty straight forward to include in the option's description.
Is it a good user experience that all boxes are checked by default? I think having some boxes ticked and others not can help draw the eye to things that stand out, which I think is desirable.

Secondly, I believe that it is a better user experience to avoid "enabling the disable functionality":

If we are consistent with having "checked means enabled" and that we prefer "enable feature X" instead of "Enable disabling feature X", then I think it makes the system easier to use. If the user takes a quick look at the options, it will be immediately apparent which options are enabled or not. If we mix enable/disable in the labels, the user has to read each label and description to know what it means that the checkbox is ticked.

Thirdly (and by far least importantly) I think it is better with a clear rule:

If we agree on my rule, I think it constraints how we describe features. This sounds bad, but I think it is good to not have too many options when designing.
I think it reduces the risk of new options being mislabeled.
If we are consistent in this way, the user would soon learn this pattern and would be able to know the state of the settings at a glance.

A reason why my rule may not be well established may be that in traditional paper forms, there were no easy way to "untick" a checkbox. If you write with an ink pen, you can only tick a box, not untick it, so the default option could never be that the box is ticked (if the author of the form wanted to give the user a choice). This may be the reason why people are not used to this rule that I think is very good. But I believe that it is a great advantage that we are able to untick boxes in the digital era, so we should take advantage of that.

Unrelated to my argument, but relevant to any coming style changes to pfSense:
The Google Developer Documentation Style Guide recommends to "Be wary of using the verbs check and uncheck, which can be ambiguous; it's often best to use select and clear instead."

darcey

@lindhe
When I last studied this stuff I hadn't even heard of Google. I vaguely remember the teaching was based on Smalltalk, UML, Gestault & Xerox. So I am very out of date. Something I did take away from it was that the guidelines were ideals.

I agree. Avoiding checkboxes being checked by default favours a human scannable configuration.
You are fixed on the motif of checkbox as light switch. That's OK.
They all seem good points.

If I understand correctly, your goals are (using preferred terms):
Checkboxes 'clear' by default.
The 'selected' state should always represent the turned on or enabled aspect of the feature under consideration.

These are mutually exclusive when the default state is 'on'.

Very good point re the digital vs paper equivalent. I'm a legacy human so probably culpable of wrong think and if I think too hard about it my brain hurts ;-)

lindhe

Just a reminder to myself: the docs must also be updated if my proposed changes are implemented.

jimp

We do try to keep things phrased positively for new options so that checked=enabled=on and things might be set by default if they default to on.

For existing options it's tough to reword things and also change any logic that touches the option to ensure it works the other way with an appropriate default behavior. There is a lot of room for error there in some cases which makes it tough to make a case for changing code and introducing bugs to correct the wording, even if it ends up more logical. And aside from that, having to accommodate both forms in the docs during the transition is very confusing for existing users.

The docs would be full of things like "Prior to x.x.x this would not do foo when checked, after x.x.x the default is to do foo when checked".

Not saying it wouldn't ever happen for older options just that it takes a lot more work and care than one might think, and would likely need to be done slowly over time and not all at once.