Defining Checkbox TVs needs Simplification

[modxbot]

everettg_99 created Redmine issue ID 7296

When you create a new Checkbox TV, the interface is confusing.

The specific problem is that the current Checkbox TV implementation is geared for creating multiple checkbox options, not a single checkbox. In my mind, multiple checkboxes is not an input type, it's a way of displaying a multi-select. In any event, the use case of having a single checkbox option suffers. See the attached image:

https://img.skitch.com/20120302-m4w8hyb1i2p66tuf98qpmq84nf.jpg

The label has to be repeated -- in the image, the main label reads "Interest Only", and then the specific option must also have a value which reads "Interest Only" -- it looks awkward and it's inefficient and it confuses users.

When a user defines a single checkbox, the display should be different so the "Name" label applies directly to the single checkbox.

Furthermore, the options here need to be clearer. Ideally, when you select the Checkbox input type, you could update the "Input Option Values" display so that it showed relevant information and examples for creating checkboxes. There should be inputs for:

• Value when checked
• Value when unchecked (I know this isn't how the HTML checkbox input works, but it's how users think)
• Is Checked by Default?

I think there should be some discussion as to whether a multi-checkbox field really is a checkbox field or if it's just an alternate view of a multi-select field. This implies that the "Listbox (Multi-Select)" field really is mislabeled: "Listbox" is a view, not a data type. I think it makes more sense to have the input type be "Multi-select" and then have various display options for that input (namely Listbox multi-select, multiple checkboxes, or even the standard multi-select field).

Regardless of the questions relating to Multi-Selects, the checkbox interface here is a major point of confusion when it comes to TVs.

[MokoJumbie]

MokoJumbie submitted:

I agree 100% and was surprised when I realized just yesterday this was the current behaviour.

If checkboxes are intended for multi-select options, then what is the correct TV to use for boolean values? I would imagine radio buttons would be another option, but again I find that the value is not being saved to the database if the value defined as the default value is selected. I know you have defined this as a 'Refactor' issue, but I am considering filing a related bug concerning the failure to save the boolean value to the database after doing more testing to verify the issue. Are you finding that this is also happening to you?

[modxbot]

everettg_99 submitted:

I remember there is some sleight of hand that takes place if your checkbox falls back to the default value -- it doesn't save to the database in the "normal" way (at least from what I remember), and I think that is the expected behavior, but someone else will have to weigh in.

There are 2 discussions here: one is the UI/UX for single checkboxes, the other deeper issue is how we should think about TVs in general. I tend to think of the input options as data types, with options for how they should be displayed (e.g. a single select could be represented by either a dropdown list or by radio buttons and it would be functionally equivalent). That's not currently how TVs are implemented, and maybe that's the wrong way for be to think about them.... the name "input options" does infer HOW things get inputted, not necessarily WHAT gets inputted. I think the more MVC way to approach custom fields is to define the data types (i.e. the model) separately from the view, however.