N/A shown for non-required boolean field

I agree, the N/A for a boolean field is technically correct, but awkward for usability. Would it be a solution to use javascript to replace the N/A radio with a "Select none" link that clears the selected radio button? See the attached mockup-screenshot.

tagging

Best solution IMO would be to make this text a 'widget setting', available for customization on the 'edit field settings' form.

@#3: OK, but if it would be a configurable string, can we still translate it for different locales?

Does this technically correct aspect of a non-required Boolean field need a UI at all? Sounds like something that needs to be handled behind the scene.

Or even: should we even provide a Boolean field that is *not* required? As in: always make a Boolean required?

The proposed 'select none' option is simply a 3-option multiple choice question, no? I mean, if 'none of the above' has to be an option, you simply don't use a boolean.

Technically booleans can be either TRUE or FALSE. By which value would N/A be represented? My point is that code may very well expect either TRUE or FALSE. Using a third value may cause errors or evaluate to TRUE or FALSE, causing unwanted behaviour.

Any field can have 'no value' (NULL). Here, N/A is 'neither true nor false', 'not specified'.
Besides, this N/A doesn't impact boolean fields only, but more generally any field using the 'radios' widget (lists with more than 2 possible values, nodereference, taxonomy field...)

re #4: er, no, making this a widget setting would make it non translatable...

Ok then this issue probably needs a better title to reflect the bigger scope.

I still think the 'neither true or false' is a no-go for the specific case of Booleans. You use booleans to *require* a yes or a no, else it's not a boolean, right?

I think there is no misunderstanding here about the technical aspect; TRUE, FALSE and NULL are all possible values for a boolean field. Yched, you're absolutely right that this discussion also applies to radio's with more options.

Still, Yoroy has a good point (paraphrasing our discussion on IRC this afternoon): What is the use case for unsetting a selected radio button? And if there is one, is it important enough to let it clutter the UI with this not-so-user-friendly N/A option? After all, one of the principles of the D7UX initiative is to "Design for the 80%".

On the other hand, the site builder can simply set a field with radio buttons to 'required' to get rid of the N/A. Maybe, all we need to to is to "Make the default settings smart" and set boolean fields to required by default.

In terms of DX allowing a third value for booleans is a no go, because a boolean in itself can only have two values as it expresses a truth with either TRUE or FALSE. The bigger problem here is that PHP says NULL == FALSE == 0, so we will likely run into trouble here. Not all code may expect a third value. This code expects either TRUE or FALSE or it will evaluate NULL to FALSE. Both cases are unwanted behaviour.

I was a bit inaccurate : 'no value' is not actually NULL, it results in $entity->field_foo[$lang] = array(), as opposed to $entity->field_foo[$lang] = array(0 => 0/1).

*All* fields of *all* types can happen to have no value on a given $entity - and that's true even of required fields; imagine the cases where:
- the field was added to a node type *after* some nodes were created
- the field was changed from 'not required' to 'required' after some nodes were created
In those cases, we're not 'reprocessing' all existing nodes to account for the new settings.

So, yes, boolean fields can and will have a 3rd "value' of 'no value'. No workaround for that.

Technically correct or not, this is still something that should not be exposed in the user interface like this.

Shouldn't this happen at the FormAPI level? Make it so any set of radios without #required gets a 'select none' link as in the screenshot.

Fixed typo in tag Usabilty to Usability

What should we review?

> What should we review?

> From a UI perspective this is a major WTF. You choose 2 allowed values for your field (see #456640: Clarify text descriptions in Field UI for booleans for more infos) but then you get three. And it won't go away. And it's called "N/A" so you can't really figure out what it means.

What is the usability team's opinion on this? Is this really a UI WTF? How could it be done better?

I wonder, most systems handle this by allowing the user to choose to select a radio instead of providing a N/A - its less than ideal but something that seems to work quite well. Can we do this?

I mean, even though this is technically required we hide the whole concept from users.

I don't think that the comparison between radios and checkboxes is relevant here.

With a set of radios, the 'N/A' option is there so you can say 'none of these options'. You can do that with a set of checkboxes by having none of them checked. There is no need for an 'N/A' option with checkboxes.

And this definitely is something core FAPI has to provide -- otherwise radios become impossible to use.

As an alternative to the 'N/A', would be clearer to have a link beneath the set of radios that says 'Select none'?

> Hence, there is no N/A. There is only On or Off.

Then it's not a boolean. The N/A with radios has the same meaning as 'off' for a single checkbox, just that you can't unclick a single radio.

I think a link that deselects is the best option, enabled if field is not required. Field configuration should allow for link to be hidden.

However the best UI scenario, IMO, is clicking a selected option a second time will deselects it.

My situation is: I do not want to enable 'required' value because I have a massively long form and I am more interested in users completing what they can and getting a 'report' of things they need to fix, (that they can do at a later time) rather than preventing them from saving.

However "N/A" value creates the assumption that a non-answer is acceptable. Either the field is unanswered, NULL, or it has an entry, 1 or 0.

I agree with 2¢ that the best choice is 1st click select 2nd click deselect, a link of deselect would ruin UI experience, and there is always the choice of manually setting up an N/A option.

If no option is selected, null could be a problem on statistics could probably set no-option = empty.

Ran into this problem today. My field was setup as follows:

1. type: list(text)
2. required? no
3. no default
4. allowed values: 1

The N/A option appeared. Neither the N/A option nor the clear field link will work for our users. I've decided to restrict the use of radio buttons to required fields. Once a selection is made, the field is in a way required. There's no way to clear it. I'm going to allow 2 values and use checkboxes instead. I have a gender field so this may be ok. If not, I'll add some custom validation and make sure the user only makes one selection.

Drupal's current setup works for me. Best practice documentation would be helpful. If issue resolved and we turn this into a documentation issue, I'm willing to help.