Open FrankFischer opened 1 year ago
Yes, I think a boolean "checked" (true|false) would make sense here. I'm not sure any more whether there was a reason for doing it that way. Maybe we were preserving the possibility of other values, e.g. "?", or different types of checks??
@matklad any thoughts?
Checkboxes can have three different states. For example, with a list of nested checkboxes, there's often "some, but not all, child itmes are checked". As another case study, org mode seems to allow these three: [ ] [-] [X]
.
I'd say: If we only allow two states syntactically, checked: boolean
makes most sense. If we have more than three states, than we need an enum of states.
Status quo, with two states and an enum, doesn't make much sense to me.
No informed opinion on whether we should have two-state or three-state checkboxes, deferring to jgm's taste here, but I maybe lean towards allowing three cases, org-style. Seems easy to support for us, and, if we don't do this, it would be hard to work-around for the user.
org mode doccs: https://orgmode.org/manual/Checkboxes.html
This has a lot to do with how we want to think about decisions in everyday life and then technology might be fine-tuned to model the preferred way of thinking...
... and after thinking more about it i am proposing a fourth value: "not clear":
Fuzzy logic
Atul Gawande has done a lot to promote the use of checklists and i use them every day (like most of all anesthesiologists worldwide) and he is one of my heroes..
His 'Checklist for Checklists'
and his WHO Surgery Safety Checklist
does not support my suggestion above!
For him a check is an action that has to be done... ... and not a query whose result gets documented.
Both interpretations sound good to me - i would like to be able to use both of them.
But the underlying concept is different and it is dangerous if one is taken for the other.
What should we do?
The boolean solution? (although i like my 4-value solution and it includes the boolean one)
A checkbox on an old-fashioned piece of paper has two states, usually: checked or not checked. There isn't any difference between "I didn't think about it" and "I thought about it and decided not to check it." That's the mental model I have. (Same is true of checkboxes in HTML.)
Sounds logical.
A 'task' gets done or not (boolean).
And the 'answer to a binary question' (yes/no/undecided/missing value/...) is something different, very depending on the use case and very easy to model with the current syntax - like :+: | :-: | :?: | :_:
Right now the checkbox value of TaskListItem can be "checked" or "unchecked".
Wouldn't it be nice to have a value for the case when this checking still has to be done? ("undefined")
(otherwise why not switch to a boolean value: "checked": true|false ? )